マスター/スレーブ遅延チューニングのアイデア
1. マスタースレーブ遅延とは何ですか?
本質は、スレーブ ライブラリの再生がマスター ライブラリに追いつかず、再生段階が遅れることです。
2. マスター/スレーブ遅延の一般的な原因は何ですか?
1. 大規模なトランザクションの場合、スレーブ ライブラリの再生時間が長くなり、マスターとスレーブの遅延が発生します。
2. メイン ライブラリの書き込み頻度が高すぎるため、スレーブ ライブラリが再生に追いつけません。
3. 無理なパラメータ設定
4. マスター/スレーブのハードウェアの違い
5.ネットワーク遅延
6. テーブルに主キーがないか、インデックスが頻繁に更新されます。
7. 読み取りと書き込みを分離する一部のアーキテクチャでは、スレーブ ライブラリに大きな負荷がかかります。
3. マスタースレーブ遅延を解決する方法は何ですか?
1. 大規模なトランザクションの場合は、小さなトランザクションに分割します。
2. 並列レプリケーションを有効にする
3. スレーブハードウェアをアップグレードする
4. 主キーを取得してみます
4. 並列レプリケーションとは何ですか?またそのパラメータは何ですか?
MySQL 並列レプリケーションの歩みを振り返る
MySQL5.6 はデータベースレベルの並列レプリケーションに基づいています
SLAVE-Parallel-type=DATABASE (異なるライブラリ内のトランザクション、ロックの競合なし)
MySQL5.7 グループコミットに基づく並列レプリケーション
slave-parallel-type=LOGICAL_CLOCK : Commit-Parent-Based模式(同一组的事务[last-commit相同]同じグループ内にロックの競合があってはなりません。そうでない場合、同じグループになることはできません)。
上記は、マスター ライブラリのグループ送信に依存するスレーブ ライブラリの構成です (グループ レプリケーションの違いに注意してください)。
greatsql> show variables like '%group%delay%';
+-----------------------------------------+-------+
| Variable_name | Value |
+-----------------------------------------+-------+
| binlog_group_commit_sync_delay | 0 |
| binlog_group_commit_sync_no_delay_count | 0 |
+-----------------------------------------+-------+
2 rows in set (0.01 sec)
-
binlog_group_commit_sync_delay: グループを送信するまでの待機時間 -
binlog_group_commit_sync_no_delay_count: グループをコミットする前に待機するトランザクションの数
上記のパラメータはすべて、メイン データベースの混雑状況に依存します。業務が頻繁でない場合は、非常に恥ずかしいことになります。
binlog_group_commit_sync_no_delay_count: このパラメータは 2 に設定されます
たとえば、1 つのスレッドだけが 1 つのトランザクションを実行し、2 番目のトランザクションが 24 時間後に実行される場合、このトランザクションは送信されるまでに 24 時間待機する必要があり、これは非常にストレスになります。
binlog_group_commit_sync_delay
200 ミリ秒に設定され、1 つのスレッドのみがトランザクションを実行する場合、トランザクションは 10 ミリ秒で送信できますが、200 ミリ秒待つ必要があります。
通常、どちらもオンラインで設定されます。たとえば、川を渡って人々を運ぶ小さなボートのようなものです。
パラメータが次のように設定されているとします。
binlog_group_commit_sync_delay=200;
binlog_group_commit_sync_no_delay_count=2
200 ミリ秒が必要な場合は直接行くことも、2 人が必要な場合は直接行くこともできます。これははるかに使いやすいですが、ビジネスが忙しくないときはまだ恥ずかしいです。
書き込みセットに基づく MySQL8.0 並列レプリケーション
主キーに基づく競合検出 (binlog_transaction_depandency_tracking = COMMIT_ORDERE|WRITESET|WRITESET_SESSION、主キーまたは変更された行の空でない一意キーに競合がない場合、並列化できます)
トランザクション検出アルゴリズム:transaction_write_set_extraction = XXHASH64
MySQL には、送信されたトランザクションの HASH 値を格納する変数があり、ハッシュ化後、すべての送信されたトランザクションによって変更された主キー (または一意のキー) の値がその変数のセットと比較され、変更があったかどうかが判断されます。競合する行の数と依存関係を判断するには
ここで説明した変数のサイズは、次のように設定できます。binlog_transaction_dependency_history_size
このような粒度は行レベルに達しており、この時点で並列粒度はより細かくなり、場合によってはスレーブの並列処理を上回ると言っても過言ではありません。マスター (マスターはシングルスレッド書き込み、スレーブは並列再生も可能)
簡単に言えば、これは行に基づく並列再生であり、rc レベルの異なる行ではロックの競合が発生しません。
グループ提出パフォーマンス:
メイン ライブラリの binlog の last_committed 値が一貫しているかどうかを確認し、一貫している場合は並列再生できます。一貫していない場合は、シリアルでのみ再生できます。
5. 実践的な分析
5.1 オンラインマスター/スレーブ遅延を確認する
Seconds_Behind_Master: 48828
遅延が 14 時間近くと非常に長いことがわかります。この時点では、メイン ライブラリも常にデータを書き込んでいます。1 つのバイナリに約 6 分、500M のバイナリに 1 つかかります。
5.2 現在のレプリケーション構成の表示
スレーブ ライブラリの構成を表示します。
greatsql> show variables like '%slave%para%';
+------------------------+---------------+
| Variable_name | Value |
+------------------------+---------------+
| slave_parallel_type | LOGICAL_CLOCK |
| slave_parallel_workers | 128 |
+------------------------+---------------+
2 rows in set (0.02 sec)
遅延現象：
スレーブ ライブラリは追跡しており、大きなトランザクションではないことを示していますが、Seconds_Behind_Master遅延は増加しています。
Retrieved_Gtid_Set: 00000000-0000-0024-0046-41a8003b4b99:242966351-253068975,
00000000-0000-0040-0095-5fff003b4b99:91056629-110569633,
00000000-0000-005c-0ced-7bae003b4b99:150292055-160253193,
31f4399f-ade5-11ed-a544-00163ebdeb51:1-12,
Executed_Gtid_Set: 00000000-0000-0024-0046-41a8003b4b99:1-252250235,
00000000-0000-0040-0095-5fff003b4b99:1-109120315,
00000000-0000-005c-0ced-7bae003b4b99:1-159504296,
31f4399f-ade5-11ed-a544-00163ebdeb51:1-12,
Auto_Position: 1
現時点では、並列レプリケーションが存在せず、メイン ライブラリがグループ送信を設定していない可能性があると考えられます (単なる推測です)。
5.3 さらに確認するには、メイン ライブラリのバイナリログを確認してください。
メイン ライブラリのパラメータ設定を確認します。グループに対してルールが送信されたままです。
greatsql> show variables like '%binlog_transac%';
+--------------------------------------------+----------+
| Variable_name | Value |
+--------------------------------------------+----------+
| binlog_transaction_compression | OFF |
| binlog_transaction_compression_level_zstd | 3 |
| binlog_transaction_dependency_history_size | 25000 |
| binlog_transaction_dependency_tracking | WRITESET |
+--------------------------------------------+----------+
4 rows in set (0.02 sec)
グループ送信の構成を確認してください。これは、グループ送信がないことを意味します。
greatsql> show variables like '%group%delay%';
+-----------------------------------------+-------+
| Variable_name | Value |
+-----------------------------------------+-------+
| binlog_group_commit_sync_delay | 0 |
| binlog_group_commit_sync_no_delay_count | 0 |
+-----------------------------------------+-------+
2 rows in set (0.01 sec)
さらに検証した後、binlog を確認すると、last_committed が実際に異なっており、並列処理が不可能であることがわかりました。
5.4 メインライブラリのパラメータを設定し、そのバイナリログを再度解析する
モードbinlog_transaction_dependency_trackingに変更されますWRITESET
greatsql> show variables like '%transaction%';
+----------------------------------------------------------+-----------------+
| Variable_name | Value |
+----------------------------------------------------------+-----------------+
| binlog_direct_non_transactional_updates | OFF |
| binlog_transaction_compression | OFF |
| binlog_transaction_compression_level_zstd | 3 |
| binlog_transaction_dependency_history_size | 25000 |
| binlog_transaction_dependency_tracking | WRITESET |
| kill_idle_transaction | 300 |
| performance_schema_events_transactions_history_long_size | 10000 |
| performance_schema_events_transactions_history_size | 10 |
| replica_transaction_retries | 10 |
| session_track_transaction_info | OFF |
| slave_transaction_retries | 10 |
| transaction_alloc_block_size | 8192 |
| transaction_allow_batching | OFF |
| transaction_isolation | REPEATABLE-READ |
| transaction_prealloc_size | 4096 |
| transaction_read_only | OFF |
| transaction_write_set_extraction | XXHASH64 |
+----------------------------------------------------------+-----------------+
17 rows in set (0.00 sec)
バイナリログを再度確認すると、その多くが並行して再生できることがわかります。
5.5 最適化の完了
メインライブラリは大量のバッチで書き込みを行っていますが、遅延は徐々に縮小しており、今日では遅延が 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) を友達として追加し、コミュニティ アシスタントがあなたをグループに追加するまで待ちます。