MySQLスレーブが長時間実行される更新クエリを実行できない
MySQLのマスター/スレーブレプリケーションサーバーを実行しています。古いデータのクリーンアップの一環として、データベースから膨大な数のレコードを削除する削除クエリを実行しました。マスターサーバーでは問題なく実行されましたが、スレーブサーバーでは次のエラーが発生しました。
スレーブSQLスレッドがトランザクションを10回再試行しましたが、無駄です。 slave_transaction_retries変数の値を大きくすることを検討してください。
スレーブサーバーマシンは、マスターサーバーマシンほど強力ではありません。どうすればこれを乗り越えることができますか？
クエリは単一行削除クエリです。 MySQL 5.6を実行しています。
レプリケーションを停止し、スレーブがマスターと同じ仕様になるようにしてから、レプリケーションを開始する必要があります。
スレーブに着信接続がないことを確認してください。そうしないと、スレーブのSQLスレッドが、SELECTを実行している同じテーブルに対してDELETEクエリを実行している着信接続と競合します。
着信接続を再ルーティングできない場合は、DELETEをチャンク単位（おそらく一度に5000行）でローカルにスレーブで再実行する必要があります。
最後の手段として、スレーブを再構築します（スレーブのハードウェアと構成をスケールアップした後）。
複数の質問があります。それらのほとんどをカバーするようにします。
最近まで、レプリケーションはシングルスレッドでした。 （今でも、マルチスレッド化には制限があります。）したがって、マスターが多くのことを並行して実行するのは簡単でしたが、スレーブに送信されてシリアルに実行されると、スレーブは遅れをとっていました。スレーブのハードウェアがマスターより遅い場合、これはさらに悪化します。
たとえば、100万行を削除する単一行の削除は、構成に応じてSBRまたはRBRで実行される場合があります。詳細は著しく異なります。
SBR（ステートメントベースレプリケーション）：マスターが削除を完了すると、ステートメントがすばやく複製されます。レプリケーション（シングルスレッドの場合）は、スレーブが100万行すべてを削除できるまでハングします。これには時間がかかります。後続のすべてのレプリケーションコマンドは待機します。奴隷は「遅れる」。
RBR（行ベースのレプリケーション）：マスターが削除を完了すると、100万の1行のレコードがネットワークを介してスレーブに送り出されます。これはオーバーヘッドを追加します。しかし、ストリームは単純であるため、スレーブは（おそらく）削除をより速く実行できます。それでも、レプリケーションは重要な時間の間拘束され、その間にスレーブは「遅れる」ことになります。
ハードウェアの量が「遅れる」のを防ぐことはできません。
その間、そのテーブルにヒットしているスレーブ上のSELECTsは多少影響を受け、逆も同様です。つまり、SELECTsは削除を遅くする可能性があります。
大きな削除はよくある問題です。 マイブログ はいくつかのソリューションを説明しています。これには、Rolandoが提案した「チャンキング」を実行する方法の詳細が含まれています。
「チャンク」およびで各チャンクを独自のトランザクションにすると、マスターとスレーブの両方への影響が少なくなります。欠点は、クラッシュにより、一部のチャンクが削除されたままのテーブルが残される可能性があることです。 （チャンク削除の再実行はおそらく簡単で安全です。）
削除のサイズ（つまり、時間の長さ）がエラーメッセージにつながると思います。
ブログの提案の1つに注意してください...テーブルの「ほとんど」が削除されている場合は、代わりに行をコピーして保持し、名前を変更してテーブルを交換します。ずっと速い、など.