1. 問題の背景
2 月 27 日の早朝、バックアップ プロセス中に、FLUSH TABLES WITH READ LOCK が解放されなかったため、本番環境の MySQL スタンバイ データベースでレプリケーション遅延が増加しました。約25分間解放されました。
バージョン：
- MySQL 5.7.21
- PXB2.4.18
遅いクエリのログ:
バックアップ スクリプト内のバックアップ コマンド:
mysql_kill.sh の主な論理内容:
バックアップパラメータ:
2. 問題の再発と分析
2.1 問題分析
- 144 は SQL スレッド、並列レプリケーションのコーディネーター スレッドです。
- 145/146 は並列レプリケーション用のワーカー スレッドであり、145/146 ワーカー スレッド キュー内のトランザクションは並列実行できます。
- スレッド 162 は、innobackup によって実行される読み取りロックでテーブルをフラッシュするために使用されます。
144 コーディネーター スレッドがリレー ログ内のトランザクションを分散したときに、トランザクションが実行できないことがわかり、前のトランザクションが送信を完了するまで待機する必要があったため、依存トランザクションのコミット待ち状態になりました。スレッド 145/146 とバックアップ スレッド 162 はデッドロックを形成します。スレッド 145 は、スレッド 162 のグローバル読み取りロックが解放されるのを待ちます。グローバル コミット ロックを適用すると、スレッド 162 はブロックされます。スレッド 146 を待ちます。スレッド 146 は MDL :: commit ロックを占有します。これは、スレーブ ライブラリがスレーブ ライブラリのビンログ送信順序を保証するために、slave_preserve_commit_order=1 を設定し、146 スレッド実行トランザクションに対応するビンログが後ろにあるためです。 145 のトランザクションは送信を待っています。最終的には、145→162→146→145の無限ループが形成され、デッドロックが形成されます。
3 つのスレッドが互いにデッドロックを形成することはまだまれです。
2.2 関連パラメータが有効にならない理由
--ftwrl-wait-timeout =60 は、FTWRL を実行する前に、長い SQL が検出された場合に、指定された時間 (秒) 待機することを意味します。タイムアウト後も長い SQL が存在する場合、バックアップはエラーで終了します。デフォルト値は 0 で、即時実行を意味します。
--ftwrl-wait-threshold =5 は、FTWRL を実行する前に長い SQL を検出する方法を指します。フラッシュを実行する前に指定した時間 (秒) を超えて実行されている SQL が存在する場合、その SQL は長い SQL として定義されます。 SQL。デフォルトは 60 秒。
--kill-long-queries_timeout=0 FTWRL の実行後、フラッシュ操作が N 秒間ブロックされた場合、それをブロックしているスレッドは強制終了されます。デフォルト設定の 0 は、SQL ブロック フラッシュが実行されるまで強制終了されないことを意味します。 SQLが完了しました。
上記の各パラメータの説明から、 --ftwrl-wait-* パラメータは FTWRL が実行される前の長い SQL 検出メカニズム用であり、FTWRL が実行されたときには役に立たないことがわかります。 -long-* パラメータはデフォルト値 0 を設定し、効果はありません。
3. 結論と提案
- PXB バックアップで FTWRL を実行してグローバル読み取りロックを追加し、SQL スレッドでデッドロックを引き起こしたことが、今回スレーブ データベースの遅延が長すぎる理由です。
--kill-long-queries\_typeパラメータを有効にして--kill-long-queries\_timeout、フラッシュがブロックされたことを検出した後、関連するスレッドを強制終了する操作を実行します。これはより暴力的であり、より大きなリスクを伴うものであり、バックアップ データベースへのビジネス アクセスがない場合に検討されます。--safe-slave-backupパラメータを有効にすると、バックアップの実行時に SQL スレッドが停止され、デッドロックが回避されます。これは、ビジネス アクセスを持たないスタンバイ データベースでのみ実行することをお勧めします。- MySQL パラメータを設定し
slave\_preserve\_commit\_order=0、スレーブ データベースからの binlog の順次送信をオフにします。このパラメータをオフにすると、スレーブ データベース内の並列レプリケート トランザクションの送信順序にのみ影響し、最終的なデータの一貫性には影響しません。特別な要件として、スレーブ データベースのバイナリログ順序は以下と一致している必要があります。メイン ライブラリは一貫性を維持しており、slave\_preserve\_commit\_order=0デッドロックを回避するための設定を考慮できます。
GreatSQL をお楽しみください :)
GreatSQL について
GreatSQL は、金融レベルのアプリケーションに適した国産の独立したオープンソース データベースであり、高パフォーマンス、高信頼性、高使いやすさ、高セキュリティなどの多くのコア機能を備えており、MySQL または Percona Server のオプションの代替として使用できます。オンラインの実稼働環境で使用され、完全に無料で、MySQL または Percona Server と互換性があります。
関連リンク: GreatSQL コミュニティ Gitee GitHub Bilibili
GreatSQL コミュニティ:
コミュニティの報酬に関する提案とフィードバック: https://greatsql.cn/thread-54-1-1.html
コミュニティ ブログ賞を受賞した投稿の詳細: https://greatsql.cn/thread-100-1-1.html
(記事について質問がある場合、または独自の洞察がある場合は、公式コミュニティ Web サイトにアクセスして質問したり共有したりできます~)
技術交流グループ：
WeChat & QQ グループ:
QQグループ: 533341697
WeChat グループ: GreatSQL コミュニティ アシスタント (WeChat ID: wanlidbc) を友達として追加し、コミュニティ アシスタントがあなたをグループに追加するまで待ちます。