web-dev-qa-db-ja.com

MySQLスレーブが長時間実行される更新クエリを実行できない

MySQLのマスター/スレーブレプリケーションサーバーを実行しています。古いデータのクリーンアップの一環として、データベースから膨大な数のレコードを削除する削除クエリを実行しました。マスターサーバーでは問題なく実行されましたが、スレーブサーバーでは次のエラーが発生しました。

スレーブSQLスレッドがトランザクションを10回再試行しましたが、無駄です。 slave_transaction_retries変数の値を大きくすることを検討してください。

スレーブサーバーマシンは、マスターサーバーマシンほど強力ではありません。どうすればこれを乗り越えることができますか?

クエリは単一行削除クエリです。 MySQL 5.6を実行しています。

3
Ruchit Rami

レプリケーションを停止し、スレーブがマスターと同じ仕様になるようにしてから、レプリケーションを開始する必要があります。

スレーブに着信接続がないことを確認してください。そうしないと、スレーブのSQLスレッドが、SELECTを実行している同じテーブルに対してDELETEクエリを実行している着信接続と競合します。

着信接続を再ルーティングできない場合は、DELETEをチャンク単位(おそらく一度に5000行)でローカルにスレーブで再実行する必要があります。

最後の手段として、スレーブを再構築します(スレーブのハードウェアと構成をスケールアップした後)。

3
RolandoMySQLDBA

複数の質問があります。それらのほとんどをカバーするようにします。

最近まで、レプリケーションはシングルスレッドでした。 (今でも、マルチスレッド化には制限があります。)したがって、マスターが多くのことを並行して実行するのは簡単でしたが、スレーブに送信されてシリアルに実行されると、スレーブは遅れをとっていました。スレーブのハードウェアがマスターより遅い場合、これはさらに悪化します。

たとえば、100万行を削除する単一行の削除は、構成に応じてSBRまたはRBRで実行される場合があります。詳細は著しく異なります。

SBR(ステートメントベースレプリケーション):マスターが削除を完了すると、ステートメントがすばやく複製されます。レプリケーション(シングルスレッドの場合)は、スレーブが100万行すべてを削除できるまでハングします。これには時間がかかります。後続のすべてのレプリケーションコマンドは待機します。奴隷は「遅れる」。

RBR(行ベースのレプリケーション):マスターが削除を完了すると、100万の1行のレコードがネットワークを介してスレーブに送り出されます。これはオーバーヘッドを追加します。しかし、ストリームは単純であるため、スレーブは(おそらく)削除をより速く実行できます。それでも、レプリケーションは重要な時間の間拘束され、その間にスレーブは「遅れる」ことになります。

ハードウェアの量が「遅れる」のを防ぐことはできません。

その間、そのテーブルにヒットしているスレーブ上のSELECTsは多少影響を受け、逆も同様です。つまり、SELECTsは削除を遅くする可能性があります。

大きな削除はよくある問題です。 マイブログ はいくつかのソリューションを説明しています。これには、Rolandoが提案した「チャンキング」を実行する方法の詳細が含まれています。

「チャンク」およびで各チャンクを独自のトランザクションにすると、マスターとスレーブの両方への影響が少なくなります。欠点は、クラッシュにより、一部のチャンクが削除されたままのテーブルが残される可能性があることです。 (チャンク削除の再実行はおそらく簡単で安全です。)

削除のサイズ(つまり、時間の長さ)がエラーメッセージにつながると思います。

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

1
Rick James