MySQL 並列レプリケーションの簡単な分析

01 並列レプリケーションの概念

MySQL のマスター スレーブ レプリケーション アーキテクチャでは、マスター データベースで多くの SQL ステートメントが同時に実行されることがよくあります。これらの SQL ステートメントがロック待機を生成しない限り、複数の SQL スレッドを同時に実行しても問題はありません。

MySQL スレーブ データベースは IO_thread を使用してマスター データベース上の binlog を取得し、それをローカルに保存してリレー ログとしてディスクに書き込み、これらのリレー ログを sql_thread を通じて適用することがわかっています。

MySQL 5.6 より前のバージョンでは、マスター データベースで複数のスレッドが同時に SQL を実行する場合、sql_thread は 1 つしかありませんでした。TPS が高いシナリオでは、マスター データベースが大幅に遅延することがありました。この問題を解決するために、MySQL は sql_thread を複数のワーカーに進化させ、リレー ログ内のトランザクションをスレーブ側で並列に適用することで、リレー ログの適用速度を向上させ、レプリケーションの遅延を削減しました。ここで並列レプリケーションが登場します。

MySQL では、レプリケーション スレッドはパラメータ slave_parallel_workers によって制御されます。通常、8G メモリと 8 コア CPU を搭載したマシンでは、この値を 8 に設定するのが適切です。CPU のコア数が多い場合は、8 から 16 の間の数値に調整できます。

mysql> 'slave_parallel_workers' のような変数を表示します。
+------------------------+-------+
| 変数名 | 値 |
+------------------------+-------+
| スレーブ並列ワーカー | 8 |
+------------------------+-------+
セットに 1 行、警告 1 件 (0.00 秒)

02 並列レプリケーションの進化

並列レプリケーションの本質は、同時に実行される SQL ステートメントのロック競合がないことです。

MySQL バージョン 5.6 では、MySQL がサポートする粒度は、データベースに応じてリレー ログを並列に実行することです。この方法では、異なるデータベース上の SQL がテーブル内の同じ行の内容を変更することは絶対にないため、いくつかの問題を解決できます。こうすることでロックの競合は発生しなくなります。この並列レプリケーション方法は、いくつかのデータベースが均等に分散され、各データベースが同様の頻度で使用されるシナリオに適しています。ビジネスのデータがホット テーブルに集中している場合、並列レプリケーションはシングル スレッド レプリケーションに退化します。

その後、MariaDB の並列レプリケーションにいくつかの改善が行われました。そのアプローチは次のとおりです。

1. マスター データベースで並列送信できるトランザクション、つまり、REDO ログ コミット ステージに入ったトランザクションは、スレーブ データベースでも並列送信できます。したがって、マスター データベースで並列送信されたトランザクションは、commit_id によって識別されます。次の並列トランザクション グループの commit_id は、このグループの commit_id+1 です。

2. すべてのトランザクションのcommit_idをbinlogに書き込む

3. データベースからバイナリログを適用するときは、すべてのバイナリログをcommit_idに応じて異なるワーカーに分割します。

4. このグループ内の commit_id のすべてのトランザクションがスレーブ データベースでコミットされた後、次のトランザクション バッチが実行されます。

この方法により、スレーブからのリレー ログの適用速度が大幅に向上しますが、スレーブが前のトランザクション セットを適用している間、前のセットのワーカーの一部がアイドル状態であっても、次のトランザクション セットが待機状態になるという問題があります。マスター データベースでは、データが常に書き込まれる可能性があります。その結果、マスター ノードとスレーブ ノードのシステム スループットは一致せず、マスター データベースのスループットはスレーブ データベースのスループットよりもはるかに高くなります。

MySQL 5.7 の並列レプリケーションは、MariaDB に基づいて改善されています。トランザクションが redo ログ準備段階に入ると、WAL テクノロジにより、トランザクションが競合検出段階を通過したことがわかります。 MySQL 5.7 の並列レプリケーションでは、マスター データベース上の redo ログ準備フェーズのすべてのトランザクションと、このフェーズ以降のトランザクション、つまり redo ログ コミット フェーズのトランザクションがスレーブ データベース上で並列に実行されるため、ワーカー スレッドの不要な待機が削減されます。

ここで、さらに 2 つのパラメータについて説明する必要があります。

• binnlog_group_commit_sync_delay パラメータは、REDO ログ準備フェーズが完了した後に fsync を呼び出すのにかかるマイクロ秒数を示します。
• binlog_group_commit_sync_no_delay_count パラメータは、fsync を呼び出す前に redo log prepare:write 操作が何回蓄積されるかを示します。

これら 2 つのパラメータは、binlog 書き込みから fsync までの時間を意図的に延長し、binlog 書き込み回数を減らすために使用されます。 MySQL 5.7 の並列レプリケーション戦略では、これらを使用して、より多くの「準備段階で同時にトランザクション」を作成できます。これにより、スタンバイ データベース レプリケーションの並列処理が向上します。

プライマリ データベースのコミットを「意図的に」遅くし、スタンバイ データベースの実行を高速化することができます。 MySQL 5.7 でスタンバイ データベースの遅延に対処する場合、スタンバイ データベースのレプリケーションの同時実行性を向上させるために、これら 2 つのパラメータ値を調整することを検討できます。

上記は、MySQL 並列レプリケーションの詳細についての簡単な分析です。MySQL 並列レプリケーションの詳細については、123WORDPRESS.COM の他の関連記事に注目してください。