長い間稼働しているシステムに、データ障害の影響で大量データ更新が必要になりました。

 

■何をしたか
MySQL5.1のマスター1台、スレーブ3台構成で運用しているシステムに、
230万件のデータ投入を行いました。データ投入は、CSVファイルから　LOAD DATA LOCAL INFILE　にて空のワークテーブルへ行い、処理時間10秒程度でテーブルへロードされました。その後そのワークテーブルをトリガーとして不具合データ90万件の遡及更新を行いました。

 

■何が起きたか
発見は翌日です。
show slave status\Gで　スレーブサーバの状態を確認すると、、

Slave_IO_Running: Yes
Slave_SQL_Running: Yes
となっていて、エラー表示等もなく一見は問題ありません。

Read_Master_Log_Pos
Relay_Log_Space
はどんどん上昇しているので、マスターログファイルの読み込みは行われているようです。

ですが、
Seconds_Behind_Master: 55405
のようになっていて、さらにこの数字はどんどん上昇していきます。
Exec_Master_Log_Pos　は同じカウントを表示していて変動しません。
つまり、マスターサーバのログファイルは読んでいるが、処理はしていない状態に見えます。
数字は微妙に違いますが、スレーブサーバ3台とも、同じ状態です。

show processlist;　で確認しても
Waiting for master to send event
Reading event from the relay log
この２つのみしか表示されません。

Mysqlエラーログにも、何も書かれていません。

しかし、topコマンドで確認すると　mysqld　がCPU100%で稼働し続けていて、
/var/lib/mysql/MyDB配下の該当テーブルは、更新日時がアップデートされ続けています。
＜参考サイト＞
https://dba.stackexchange.com/questions/36909/slave-sql-thread-got-hanged

一体何が起きているのか　なにもわからない状態です・・

 

■そしてどう対応したのか
4日が過ぎてもまだ、状態は変わりません。
そこで、以下のサイトを参考に
https://dba.stackexchange.com/questions/36909/slave-sql-thread-got-hanged
SET GLOBAL innodb_flush_log_at_trx_commit = 2;
で設定値の変更を行いました。

これが効いたのか確認する方法が分かりませんが、3台のスレーブサーバのうち1台が先ほどレプリカ完了しました。
Seconds_Behind_Master: 0　となり追いついたようです。

 

そして5日たって、さらにスレーブサーバ1台がレプリカ完了しました。

あと1台も、もうすぐだと思います。

 

■分かったこと

スレーブサーバ側の処理状況を見ると、CSVファイルから　LOAD DATA LOCAL INFILE　にて空のワークテーブルへ流し込んだ処理の反映に時間がかかっているようでした。