zabbixがmysqlのせいでエラーを吐いて起動しなくなったのでその復旧メモ


zabbixがエラーを吐いて、起動しなくなった。
ZabbixにWebアクセスすると、以下のようなメッセージが出ている。
どうやら、mysqldが止まっている模様

Dtabase error connectiong to database [Can’t connect to local MySQL server though ‘var/lib/mysql/mysql.sock'(2)]

zabbix_障害発生
/etc/init.d/mysqld status で確認すると
mysqldは停止していますがサブシテムがロックされています
と表示されている・・・・

どうやらmysqldが正常な手順ではなく、異常終了してしまった状態のようだ。

サーバ自身を再起動してもだめなので、もう少しし並べて見ると、
Mysqlのログに、いやなメッセージが・・・・

tail -30 /var/log/mysqld.log

どうやらテーブルのインデックスが壊れているようなメッセージを発見。

でももう少しあがいてみる。
/etc/my.cnfを開いて以下の行を[mysqld]に追加(リカバリモードでの起動を指示)
innodb_force_recovery = 1

で、rebootコマンドで再起動してみた。
reboot

dbが起動したことを確認
/etc/init.d/mysqld status

とりあえず、Mysqlの起動はしている模様。

この状態でZabbixにWebアクセスすると、
とりあえず起動はするが、あちこちにUpdateに失敗した旨がされている・・・・

たぶんリカバリモードで起動しているので、DatabaseがReadOnlyモードになっているせいでしょう。

zabbix_暫定復旧

この状態でDB全体をチェックしてみる
mysqlcheck -c zabbix -u zabbix -p

やはりzabbix.history_uintが壊れていると出ている。

一応、修復しようとして見ましたが
mysqlcheck -r zabbix history_uint -u zabbix -p

InnoDBなのでできないみたい。

なので、mysqlコマンドからコマンドを実行して更なる調査を実施
まずは、mysqlコマンドを起動
mysql -u zabbix -D zabbix -p

テーブルの状態を再度確認してみると
check table history_uint;

状況はいっしょですね。

ついでに該当テーブルのインデックスの状況を確認して見ます。
show index from history_uint;

ここから復旧してみます。
まずは該当テーブルのバックアップを取得します。

単純に出力してもよいのだけども、ダンプファイルが巨大になりすぎるので圧縮して出力させます。
mysqldump zabbix history_uint | gzip > history_uint_bk.sql.gz

ダンプ出力が完了したら、壊れたテーブルを削除します。
drop table history_uint;

リカバリモードから通常モードで復帰させてmysqldを起動します。

vi /etc/my.cnf
で以下を変更(コメント化)
#innodb_force_recovery=1

正常に起動したことを確認したら、先ほど取ったダンプからリストアします。
zcat history_uint_bk.sql.gz | mysql -u zabbix -D zabbix -p

リストアが終わったら、壊れたテーブルが正常に戻っているかを確認します。
select count(*) from history_uint;
show index from history_uint;

ちゃんとインデックスも戻っていますね
サーバを再起動して、Zabbixが使用できるか確認します。

zabbix_復旧完了
ちゃんと起動しました。
これでなんとか修復できましたが、なぜ壊れたのかは謎。
取り合えず、もう少しmysqldのチューニングが必要なのかもしれない。

とりあえずZabbix仮想マシンの割り当てメモリを512MBから1GBに増やして、innodb_buffer_pool_sizeを128MB -> 256MBに変更して様子見中。

/etc/my.cnf

Zabbixサーバのメモリを2GBとか4GBぐらい割り当てるんだったら、こんな設定例みつけたので故実参考にします。
http://www.zabbix.jp/node/72
http://kometchtech.blog.fc2.com/blog-entry-1290.html

 

今回の参考URL

http://dev.mysql.com/doc/refman/5.1/en/forcing-innodb-recovery.html
http://cimacoppi.exblog.jp/13146947

http://qiita.com/pugiemonn/items/8a6b322654aa65e2966b

http://www.dbonline.jp/mysql/table/index10.html
http://d.hatena.ne.jp/jitsu102/20120106/1325799325
http://mysql.javarou.com/dat/000389.html

MySQLでInnoDBのDatabase pageが壊れる。


http://kb.odin.com/jp/6586
https://dev.mysql.com/doc/refman/5.6/ja/rebuilding-tables.html

MySQL の壊れたテーブルを修復


http://www.dbonline.jp/mysql/table/index4.html
http://qiita.com/sue738/items/5c8ca15d5d91088e32bf
http://blog.layer8.sh/ja/2011/12/23/mysql%E3%82%92%E9%AB%98%E9%80%9F%E5%8C%96%E3%81%97%E3%81%9F%E3%81%84%E3%81%A8%E3%81%8D%E3%81%AE%E3%83%81%E3%83%A5%E3%83%BC%E3%83%8B%E3%83%B3%E3%82%B0/
http://www.zabbix.jp/node/72
http://kometchtech.blog.fc2.com/blog-entry-1290.html

Zabbixの蓄積系データを初期化するhttp://qiita.com/rui5885/items/e9bd3eefa625a288bb48

全データを削除する
http://mysql.deikou.com/pages/000067.html

http://phpspot.net/php/pgmysqldump%E3%81%A7%E3%83%90%E3%83%83%E3%82%AF%E3%82%A2%E3%83%83%E3%83%97%EF%BC%86%E5%BE%A9%E5%85%83.html

http://www.risewill.co.jp/blog/archives/1111

 


コメントを残す

メールアドレスが公開されることはありません。