MySQLでのレプリケーションは長い間存在しており、長年にわたって着実に改善されています。それは革命というよりは進化のようなものでした。レプリケーションは多くの人が依存する重要な機能であり、機能する必要があるため、これは完全に理解できます。
前回のMySQLバージョンでは、トランザクションの並列適用のサポートにより、レプリケーションのパフォーマンスが向上しました。 MySQL 5.6では、並列化はスキーマレベルで実行されていました。別々のスキーマで実行されたすべてのトランザクションを一度に実行できました。これは、単一のサーバー上に複数のスキーマがあり、負荷がスキーマ全体にほぼ均等に分散されているワークロードにとっては素晴らしい改善でした。
MySQL 5.7では、「論理クロック」と呼ばれる別の並列化方法が追加されました。すべてのデータが単一のスキーマに格納されている場合でも、スレーブである程度の同時実行性を得ることができました。つまり、ハードウェアによって追加された遅延のために、一部のトランザクションが一緒にコミットされるという事実に基づいていました。 binlog_group_commit_sync_delayを使用してスレーブでより良い並列化を実現するために、そのレイテンシーを手動で追加することもできます。
このソリューションは本当に素晴らしかったですが、欠点がないわけではありません。トランザクションのコミットが遅れると、最終的にはアプリケーションのユーザー向けの部分に影響を与える可能性があります。もちろん、遅延は数ミリ秒の範囲内で設定できますが、それでも、追加の遅延がアプリの速度を低下させます。
MySQL8.0でのレプリケーションパフォーマンスの向上
現在（2017年8月）現在もベータ状態にあるMySQL 8.0は、レプリケーションにいくつかの優れた改善をもたらします。もともとはグループレプリケーション（GR）用に開発されましたが、GRは内部で通常のレプリケーションを使用するため、「通常の」MySQLレプリケーションはその恩恵を受けました。前述の改善点は、バイナリログに保存されている依存関係の追跡情報です。何が起こるかというと、MySQL 8.0には、特定のトランザクション（いわゆるライトセット）の影響を受けた行に関する情報を格納する方法があり、さまざまなトランザクションのライトセットを比較します。これにより、同じ行のサブセットで機能しなかったトランザクションを特定できるため、これらを並行して適用できます。これにより、MySQL 5.7の実装と比較して、並列化レベルを数倍に増やすことができます。覚えておく必要があるのは、最終的に、スレーブはデータの異なるビューを見ることになります。これは、マスターには表示されませんでした。これは、トランザクションがマスターとは異なる順序で適用される可能性があるためです。ただし、これは問題にはなりません。 MySQL 5.7でのマルチスレッドレプリケーションの現在の実装でも、slave-preserve-commit-orderを明示的に有効にしない限り、この問題が発生する可能性があります。
この新しい動作を制御するには、変数 binlog_transaction_dependency_tracking 導入されました。次の3つの値を取ることができます：
- COMMIT_ORDER：これはデフォルトのメカニズムであり、MySQL5.7で使用可能なデフォルトのメカニズムを使用します。
- WRITESET：より適切な並列化が可能になり、マスターは書き込みセットデータをバイナリログに保存し始めます。
- WRITESET_SESSION：これにより、トランザクションがスレーブで順番に実行され、マスターでは見られなかったデータベースの状態を見るスレーブの問題が解消されます。並列化は減少しますが、それでもデフォルト設定よりも優れたスループットを提供できます。
ベンチマーク
7月、mysqlhighavailability.comで、VitorOliveiraが新しいモードのパフォーマンスを測定しようとした投稿を書きました。彼は、古いモードと新しいモードの違いを示すために、ベストケースのシナリオを使用しました。耐久性はまったくありません。今回は、より現実的な設定で同じアプローチを使用することにしました。log_slave_updatesでバイナリログを有効にします。耐久性の設定はデフォルトのままでした（つまり、sync_binlog =1-MySQL 8.0の新しいデフォルト、ダブルライトバッファーが有効、InnoDBチェックサムが有効など）。耐久性の例外は、innodb_flush_log_at_trx_commitが2に設定されていることだけでした。
m4.2xlインスタンス、32G、8コアを使用しました（したがって、slave_parallel_workersは8に設定されました）。また、sysbench、oltp_read_write.luaスクリプトも使用しました。 32テーブルの1600万行が、1000GB gp2ボリューム（3000 IOPS）に保存されました。 1、2、4、8、16、および32の同時sysbench接続のすべてのモードのパフォーマンスをテストしました。プロセスは次のとおりです。スレーブを停止し、100kトランザクションを実行し、スレーブを開始して、スレーブラグをクリアするのにかかる時間を計算します。
まず、sysbenchが1つのスレッドのみを使用して実行されたときに何が起こったのかはわかりません。各テストは、ウォームアップ実行後に5回実行されました。この特定の構成は2回テストされました。結果は安定しています。シングルスレッドのワークロードが最速でした。何が起こったのかを理解するために、さらに調査します。
それ以外の結果は、私たちが期待したものと一致しています。 COMMIT_ORDERは、特にトラフィックが少ない2〜8スレッドの場合、最も低速です。 WRITESET_SESSIONは通常、COMMIT_ORDERよりもパフォーマンスが優れていますが、同時トラフィックが少ない場合はWRITESETよりも低速です。
どのように役立ちますか？
最初の利点は明らかです。ワークロードが遅い側にあるにもかかわらず、スレーブがレプリケーションでフォールバックする傾向がある場合、マスターが8.0にアップグレードされるとすぐに、スレーブはレプリケーションパフォーマンスの向上から恩恵を受けることができます。ここでの2つの注意：最初に-この機能は下位互換性があり、5.7スレーブもこの機能の恩恵を受けることができます。 2番目-8.0はまだベータ状態であることに注意してください。本番環境でベータソフトウェアを使用することはお勧めしませんが、緊急に必要な場合は、これをテストするオプションです。この機能は、スレーブが遅れている場合だけでなく、あなたを助けることができます。それらは完全に追いついている可能性がありますが、新しいスレーブを作成するか、既存のスレーブを再プロビジョニングすると、そのスレーブは遅れます。 「WRITESET」モードを使用できるようになると、新しいホストのプロビジョニングプロセスがはるかに高速になります。
全体として、この機能はあなたが考えるかもしれないはるかに大きな影響を与えるでしょう。 MySQLが同時実行性の低いトラフィックを処理するときにパフォーマンスの低下を示すすべてのベンチマークを考えると、そのような環境でのレプリケーションを高速化するのに役立つものはすべて大幅に改善されます。
中間マスターを使用する場合、これも探すべき機能です。中間マスターは、トランザクションの処理方法と実行方法にシリアル化を追加します。実際には、中間マスターのワークロードは、ほとんどの場合、マスターよりも並列性が低くなります。ライトセットを利用して並列化を改善すると、中間マスターでの並列化が改善されるだけでなく、すべてのスレーブでの並列化も改善されます。 8.0中間マスターを使用してスレーブのレプリケーションパフォーマンスを向上させることも可能です（ただし、すべてのピースが正しく適合することを確認するには深刻なテストが必要です）（MySQL 5.7スレーブはライトセットデータを理解して使用できることに注意してください）単独で生成することはできません）。もちろん、8.0から5.7に複製するのはかなり難しいように聞こえます（8.0がまだベータ版であるという理由だけではありません）。状況によっては、これが機能し、5.7スレーブのCPU使用率を高速化できる場合があります。
MySQLレプリケーションのその他の変更
ライトセットの紹介は最も興味深いものですが、MySQL8.0でMySQLレプリケーションに発生した変更はこれだけではありません。他の重要な変更についても見ていきましょう。 MySQL 5.0より古いマスターを使用する場合、8.0はそのバイナリログ形式をサポートしません。このような設定が多く見られることはないと思いますが、非常に古いMySQLをレプリケーションで使用している場合は、間違いなくアップグレードする時期です。
レプリケーションが可能な限りクラッシュセーフになるように、デフォルト値が変更されました： master_info_repository およびrelay_log_info_repository TABLEに設定されます。 Expire_log_days も変更されました。デフォルト値は30になりました。expire_log_daysに加えて 、新しい変数が追加されました。 binlog_expire_log_seconds 、これにより、よりきめ細かいbinlogローテーションポリシーが可能になります。レプリケーションラグの可観測性を向上させ、マイクロ秒の粒度を導入するために、いくつかの追加のタイムスタンプがバイナリログに追加されました。
とにかく、これはMySQLレプリケーションに関連する変更と機能の完全なリストではありません。詳細については、MySQLの変更ログを確認してください。それらすべてを確認してください。これまでのところ、すべての8.0バージョンに機能が追加されています。
ご覧のとおり、MySQLレプリケーションはまだ変化しており、改善されています。最初に言ったように、それはペースの遅いプロセスでなければなりませんが、何が先にあるかを見るのは本当に素晴らしいことです。また、グループレプリケーションの作業が徐々に減少し、「通常の」MySQLレプリケーションで再利用されるのを見るのも良いことです。