MySQL 5.6スレーブがマスターの再起動時にBinlogの処理を停止する
MySQL 5.6.23を搭載した1組のDebian 7サーバーがあります。スレーブサーバーはマスターのクローンです（ただし、uuidはスレーブで再生成されています）。
何らかの理由で、MySQLがマスターで "service mysql restart、 "スレーブは引き続きMaster_Log_FileとRead_Master_Log_Posを読み取りますが、Relay_Master_Log_Fileは処理しません。
スレーブI/OとスレーブSQLはどちらも実行中ですが、Seconds_Behind_Masterは増加し続けます。
Slave_SQL_Running_Stateは「Waiting for Slave Worker to release partition。 "
明らかに、スレーブを停止して起動し、スレーブとマスターでMySQLサービスを再起動し、スレーブとマスターサーバーを再起動しようとしました。
この問題を修正するには、スレーブを空白にして再作成する必要があります。マスターファイルと位置をダンプするために作成したスクリプトを使用してこれを行い、mysqldumpを使用してデータベースをスレーブにプルし、記録されたマスターファイルと位置からスレーブを開始します。 mysqldumpフラグは--skip-lock-tables --flush-logs --hex-blob --master-data=2 --single-transaction --comments --routines
何か不足していますか？どんな助けでも大歓迎です。
何だと思う ？厄介な小さなバグがあります（ マルチスレッドレプリケーションでレプリケーションが停止します ）
このバグはMySQL 5.6.17の20 Jun 2014 15:45で最初に報告されました
提案＃1
解決されたかどうかを確認するには、MySQL 5.6.18からMySQL 5.6.22までのすべてのリリースノートを確認する必要があります。これらのリリースノートのいずれかで問題が修正されたと主張されている場合、誰かがパッチを見逃しています。 MySQL 5.6.21より前には何も後退しないことをお勧めします（ MySQL 5.1.73から5.6.21にアップグレードする既知の問題はありますか？ISSUE #3 : Security Issuesの下）
提案＃2
このバグが修正されるまで、マルチスレッドレプリケーションを使用しないでください。
提案＃3
前述の バグレポート では、これは途中のどこかにあると述べています
MySQLが再び復旧すると、ログがローテーションされ、IOスレッドは部分的に書き込まれたイベントグループから書き込みを開始します。
。 。 。
「end_log_pos」の値は、前に示した部分的なイベントと今回のイベントで同じであることがわかります。これは、部分的に書き込まれたのと同じUPDATEトランザクションです。
興味深い部分があります。コーディネーターはリレーログを読み取るときに、部分的なイベントをワーカーに送信します。これは、イベントが部分的であるため、ワーカーがトランザクションをコミットすることはなく、トランザクションは開いたままです。コーディネーターは次のイベント（部分的なイベントの完全バージョン）を読み取りますが、ワーカーの1つがトランザクションを開いているため、コーディネーターは次のイベントを別のワーカーに割り当てることができません。
そしてどうやら、MTSは、ログがローテーションされているのを見ると、ワーカーがトランザクションをコミットするのを待ちます。
Mysqldumpで--flush-logsを使用しないことをお勧めします。mysqldumpによって突然分割されたグループコミットにいくつかの問題があり、このバグが着信binlogイベントを正しく表示しない場合に備えます。
@RolandoMySQLDBAの提案を使用してコメントアウトしましたslave_parallel_workers、デフォルトは0で、マルチスレッド複製を事実上無効にします。これにより、MySQL 5.6.23リリースノートで解決された問題が修正されました。