【ファントムシャットダウン】slaveのレプリケーションが止まる原因【エラー1053】

これまでのあらすじ

slaveのレプリケーションが止まったらザ・ワールドであることを認識し、バイツァ・ダストが効かないことを覚悟し、キング・クリムゾンでエラー時間を消飛ばし、メイド・イン・ヘブンでmasterに追いつけば解決する。
↓
slaveのレプリケーションが止まったら時間操作系のスタンドで直すことができる
↑
とてもふざけているようですが、実は真面目な内容です。
MySQLの実践的かつ具体的な情報満載ですが、ところどころ、いやそこらじゅうに振りまかれたジョジョネタで読みにくいです。
読みにくいと思った人はジョジョ買いましょう。ほんの120巻程度ですからすぐ読み終わります。

という訳で

前回ではslave側のレプリケーションが止まったら、どのように直せば良いかは分かりました。
しかし「そもそもなぜレプリケーションは止まったのか？」が判明しないと、真の解決とは言えません。
再発するかもしれないからね

「slave側のレプリケーションが止まった」でググると、多くのサイトがヒットします。
内容は、私が前回書いたものとほぼ同じです。
いやジョジョを絡めた記事はありませんでしたけどね！（誇らしげ

要するに、エラーをスキップして再開すれば良い。

ただ気になるのは、「なぜ止まったのか？どんなことをしたら止まるのか？」について触れているサイトが見当たらないこと。

日本では「slaveに対して直接更新系の処理が走ったんじゃね？」というふわっとした感じの情報が多いのです。

この「slaveに対して直接更新系の処理が走る」が独り歩きしてる感が強く、「slaveのレプリケーションが止まる原因はたいていコレ」という空気が醸成されています。惑わされやすいです。惑わされました。

いやもちろんこれは原因の一つではあるのですが、その場合はログとかしっかり調査したいですね。
調査してみたのですが、ログからは確実な証拠が見つかりません。

そこで

思い込みを排して、原点に返ってみましょう。

slaveの状態を確認した時、答えは出ていたのです。

mysql> show slave status\G
Last_Error: Query partially completed on the master (error on master: 1053) and was aborted. There is a chance that your master is inconsistent at this point. If you are sure that your master is ok, run this query manually on the slave and then restart the slave with SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE; . Query: ‘Insert into resaku_param_new
(file_ymd, cookie_id, param_id, param, param_key, param_val, date, start_time, end_time, week_no_year, week_no_month, uu_count,
cnt_m, cnt_2, cnt_3, cnt_4, cnt_5, cnt_7, create_date)
select file_ymd, cookie_id, param_id, param, param_key, param_val, date, start_time, end_time, week_no_year, week_no_month, uu_count,
cnt_m, cnt_2, cnt_3, cnt_4, cnt_5, 0, create_date from resaku_param where file_ymd between ‘20150925’ and ‘20150930”

ついついクエリに問題があったんじゃないかと思ってしまいがちですが、クエリ自体に問題があったら、そもそもmasterで実行された時点で普通にSQLエラーになります。
これはあくまでも「エラーが起きた時のクエリ」であり「エラーを起こすクエリ」では無いことがポイントです。

で答えの方ですが。

Query partially completed on the master (error on master: 1053) and was aborted. There is a chance that your master is inconsistent at this point.
クエリはマスター側で完成する前に中断されました。この時点でマスターと矛盾している可能性があります。

はい。
つまりmaster側での「何か」が原因だと言っています。
slave側には問題は無かったのです。
「slaveに対して直接更新系の処理が走る」は、今回のケースでは全く関係ありません。

じゃあ「何か」って何か？
それも書かれています。
「完成する前に中断されました」って言ってます。
エラーコードも書かれてるじゃないですか。
error on master: 1053って。

その辺をヒントに検索します。
私が検索した時点で、日本のサイトで1053とレプリケーションを関連付けて紹介しているサイトはありませんでした。
つまり英語を頑張らないといけないってことです。

頑張りました。

When interrupting a query on a Master, does it replicate to the Slave?

素晴らしいですね。パーフェクトゥーですね。

master側で重すぎるクエリを実行して、待ちきれないからCtrl+Cで中断した場合、slaveには何が起きるか？というお話です。

で、回答者は「master側でクエリを中断すると、時々こんなメッセージが出るはずだよ」と言ってます。

Query partially completed on the master (error on master: 1053) and was aborted. There is a chance that your master is inconsistent at this point. If you are sure that your master is ok, run this query manually on the slave and then restart the slave with SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE; . Query: (INSERT vhc (v_id, vc_id) SELECT 7421594, vc_id FROM vc WHERE label=’st’ AND value=’re’)

ずばり今回のケースそのものです。
「エラー1053は、サーバーのシャットダウンです」
「エラー1053（Ctrl+Cによって引き起こされるファントムシャットダウン）」

ファントムシャットダウン！なんかかっこいい！日本でも流行らせましょう！

という訳で。
今回の件。関係各所に連絡してみたら、やはり「master上で重い処理をしていた。時間がかかったのでCtrl+Cで中断した」という回答を得ました。

ぼくはキメ顔でこう言った。

「あぁ～ファントムシャットダウンですね」