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つに注意してください...テーブルの「ほとんど」が削除されている場合は、代わりに行をコピーして保持し、名前を変更してテーブルを交換します。ずっと速い、など.