BaculaとMySQLのアップデートに伴う動作不具合と対応

検証機のBaculaクライアントとマスターサーバにyum updateをかけて発生した不具合とその対応方法についてまとめます。

 

Baculaクライアントでyum update後、バックアップジョブが失敗。

Fatal error: bsock.c:579 Packet size=1073741940 too big from “Client: test-client:192.168.1.11:9102. Terminating connection.
Fatal error: No Job status returned from FD.

 

原因はBaculaのバージョンがクライアント>マスターになったことが原因と思われる。

ここまでは想定の範囲内なのでスルーして、マスターサーバにもyum update実施。

 

これでジョブが正常稼動すると思いきや、マスターサーバのbacula-dirサービスが起動しなくなる。

これは完全に想定外。

 

まずは状況を正しく把握。

yum updateでのBacula関連コンポーネントの変更は以下。

変更前  変更後
bacula-libs-7.4.6-1.el6.x86_64
bacula-common-7.4.6-1.el6.x86_64
bacula-libs-sql-7.4.6-1.el6.x86_64
bacula-director-7.4.6-1.el6.x86_64
bacula-client-7.4.6-1.el6.x86_64
bacula-storage-7.4.6-1.el6.x86_64
bacula-console-7.4.6-1.el6.x86_64
bacula-libs-9.0.3-1.el6.x86_64
bacula-common-9.0.3-1.el6.x86_64
bacula-libs-sql-9.0.3-1.el6.x86_64
bacula-director-9.0.3-1.el6.x86_64
bacula-client-9.0.3-1.el6.x86_64
bacula-storage-9.0.3-1.el6.x86_64
bacula-console-9.0.3-1.el6.x86_64
mysql-community-common-5.6.35-2.el6.x86_64
mysql-community-libs-5.6.35-2.el6.x86_64
mysql-community-libs-compat-5.6.35-2.el6.x86_64
mysql-community-client-5.6.35-2.el6.x86_64
mysql-community-server-5.6.35-2.el6.x86_64
mysql-community-common-5.6.37-2.el6.x86_64
mysql-community-libs-5.6.37-2.el6.x86_64
mysql-community-libs-compat-5.6.37-2.el6.x86_64
mysql-community-client-5.6.37-2.el6.x86_64
mysql-community-server-5.6.37-2.el6.x86_64

 

Bacula-dirのテストコマンドを実行してエラー原因の糸口を探る。
# /usr/sbin/bacula-dir -t
bacula-dir: dird.c:1152-0 Could not open Catalog “MyCatalog”, database “bacula”.
bacula-dir: dird.c:1157-0 Version error for database “bacula”. Wanted 16, got 15
23-Aug 14:10 bacula-dir ERROR TERMINATION
Please correct configuration file: bacula-dir.conf

 

DBテーブルの更新が必要と公式HPに情報があるので、手順に従って実行します。

# /usr/libexec/bacula/update_bacula_tables mysql -u bacula -p
Altering mysql tables

This script will update a Bacula MySQL database from version 12-15 to 16

Depending on the current version of your catalog,
you may have to run this script multiple times.

Enter password:
Enter password:
Update of Bacula MySQL tables 15 to 16 succeeded.
Enter password:
#
なぜか3度もパスワード入力を要求されたものの、成功はしたようです。

 

ここで出てくる15や16の数字は、MySQL上でBaculaが使用するテーブルのバージョンIDです。
MySQLログイン後、該当DBでコマンドを実行することでも確認できます。
> select * from Version;
+———–+
| VersionId |
+———–+
| 16    |
+———–+

 

テーブル更新後、bacula-dirサービスの正常稼動に成功。
# /usr/sbin/bacula-dir -t
(何も出力されなければ正常)

 

しかし、ジョブを実行するとエラー発生。
> 23-Aug 13:43 bacula-dir JobId 0: Fatal error: sql_create.c:84 Create DB Job record INSERT INTO Job (Job,Name,Type,Level,JobStatus,SchedTime,JobTDate,ClientId,Comment) VALUES (‘TestWeeklyBackup.2017-08-23_13.43.18_03′,’TestWeeklyBackup’,’B’,’F’,’C’,’2017-08-23 13:43:11′,1503463391,6,”) failed. ERR=Field ‘StartTime’ doesn’t have a default value

 

エラー内容は、StartTimeが設定できないというもの。
MySQL5.6のマニュアルを確認すると以下が判明。

・NO_ZERO_DATE、NO_ZERO_IN_DATEという機能で構文エラーになっていると思われる
・上記2つの機能は、SQL modeに厳格モード(Strict Mode)が設定されている場合に有効になる

 

SQL modeの現設定を確認。

MySQLログイン後にモード確認コマンド実行。
> SELECT @@GLOBAL.sql_mode;
+——————————————–+
| @@GLOBAL.sql_mode |
+——————————————–+
| STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION |
+——————————————–+

デフォルトで上記設定になっている。

 

 

STRICT_TRANS_TABLESを外したモード変更コマンドを実行。

> SET GLOBAL sql_mode = ‘NO_ENGINE_SUBSTITUTION’;

 

 

変更後、再度モード確認コマンドを実行し、STRICT_TRANS_TABLESが解除されたことを確認。

> SELECT @@GLOBAL.sql_mode;
+————————+
| @@GLOBAL.sql_mode |
+————————+
| NO_ENGINE_SUBSTITUTION |
+————————+

 

 

これでBaculaのジョブが正常稼動できるようになりました。