PolarDB for MySQLの物理レプリケーションに基づく半同期レプリケーション - PolarDB

このトピックでは、PolarDB for MySQLが物理レプリケーションに基づく半同期レプリケーションの効率を向上させ、半同期レプリケーションがプライマリデータベースのパフォーマンスに与える影響を軽減する方法について説明します。このトピックでは、物理レプリケーションに基づく半同期レプリケーション機能の背景情報、機能の動作方法、使用状況、およびパフォーマンステストの結果について説明します。このトピックでは、この機能に関するよくある質問に対する回答も提供します。

背景情報

デフォルトでは、MySQLはバイナリログに基づく半同期レプリケーションをサポートしています。このレプリケーションモードでは、セカンダリデータベースがトランザクション用に生成されたバイナリログを受信して同期したことを確認した後にのみ、プライマリデータベースでトランザクションをコミットできます。ただし、この同期モードでは追加のレイテンシが発生し、プライマリデータベースの書き込みパフォーマンスに一定の影響を与えます。

PolarDB for MySQLは、物理レプリケーションアーキテクチャを使用して、高効率のredoログを使用してプライマリゾーンとセカンダリゾーン間でデータを同期します。これにより、半同期レプリケーションの効率が向上し、プライマリデータベースのパフォーマンス損失が大幅に削減されます。重い同時負荷の下では、物理レプリケーションに基づく半同期レプリケーションは、非同期レプリケーションと比較してパフォーマンスを約10% 低下させます。

バイナリログに基づくMySQL半同期レプリケーションと比較して、物理レプリケーション (redoストリーム) に基づくPolarDB for MySQL半同期レプリケーションは、より高い同期効率を提供します。トランザクションの実行中に、redoログが生成され、リアルタイムでセカンダリゾーンに送信されます。したがって、コミットの再実行ログがセカンダリゾーンに同期された直後にトランザクションをコミットできます。バイナリログに基づくMySQL半同期レプリケーションでは、トランザクションをコミットする場合にのみ、完全なバイナリログを生成できます。操作成功メッセージは、すべてのバイナリログが同期された後にのみクライアントに返すことができます。

機能の説明

PolarDB for MySQLが提供する半同期レプリケーションのロジックは理解しやすいです。この機能は、物理レプリケーションアーキテクチャを使用して、redoログを使用してプライマリゾーンとセカンダリゾーン間でデータを同期します。 Redoログは、関連するデータがプライマリゾーンで変更されたときに、業務システムによって発行された書き込み要求に対して生成されます。 redoログは、物理レプリケーションリンクを介してセカンダリゾーンに同期されます。一次ゾーンが書き込み要求の書き込みトランザクションをコミットし、成功メッセージをビジネスシステムに返す前に、一次ゾーンは、二次ゾーンからのコミットのための再実行ログの受信の確認を待たなければならない。

トランザクションコミット前の最大待ち時間
セカンダリゾーンの予期しない要因により、プライマリゾーンで書き込み要求がコミットされない場合があります。したがって、トランザクションコミットまでの最大待ち時間は、カーネル層で指定される。プライマリゾーンが書き込みトランザクションの指定された最大待機時間内にセカンダリゾーンから確認を受信しない場合、書き込みトランザクションはタイムアウトし、プライマリゾーンは自動的に書き込みトランザクションをコミットします。
適応メカニズム
極端な場合、セカンダリゾーンは、最も早い機会にプライマリゾーンとの同期情報を確認できなくなる可能性がある。その結果、プライマリゾーンはタイムアウト期間後に各書き込み要求をコミットし、パフォーマンスの低下を引き起こします。この問題を防ぐために、PolarDB for MySQLは半同期レプリケーションのアダプティブメカニズムを実装しています。 PolarDB for MySQLは、プライマリゾーンとセカンダリゾーン間のネットワーク接続を監視し、タイムアウトが頻繁に発生すると自動的に非同期レプリケーションに切り替えます。これにより、極端な場合、プライマリゾーンの書き込み要求が半同期レプリケーションの影響を受けないようになります。プライマリゾーンとセカンダリゾーン間のネットワーク接続が回復すると、PolarDB for MySQLは自動的に半同期レプリケーションに戻ります。

使用上の注意

説明

物理レプリケーションに基づくPolarDB for MySQLの半同期レプリケーションにより、ゾーン間のデータの一貫性が大幅に向上します。この機能を有効にする方法の詳細については、「クロスゾーン自動切り替え機能の使用」をご参照ください。

メジャーバージョンが8.0.1、リビジョンバージョンが8.0.1.35.1以降のPolarDB for MySQL Enterprise Editionクラスターのみが、ゾーン間の半同期レプリケーションをサポートしています。
- メジャーバージョンが8.0.1、リビジョンバージョンが8.0.1.1.40以降のPolarDB for MySQL Enterprise Editionクラスターは、半同期レプリケーションのアダプティブメカニズムをサポートしています。
- メジャーバージョンが8.0.1、リビジョンバージョンが8.0.1.1.44.2以降のPolarDB for MySQL Enterprise Editionクラスターは、innodb_polar_wait_slave_reply_max_timeパラメーターをサポートしています。このパラメーターを設定して、半同期レプリケーションを有効にした後、プライマリゾーンで書き込みトランザクションをコミットするまでの最大待機時間を指定できます。このパラメーターのデフォルト値は500 msです。
リカバリポイント目標 (RPO) とリカバリ時間目標 (RTO)
- 非同期レプリケーションでは、クロスゾーン自動切り替えにより損失が発生します。ほとんどの場合、RPOは100ミリ秒未満です。最悪の場合、RPOは60秒未満です。この機能を使用する前に、ビジネスへの影響を評価してください。
- 半同期レプリケーションでは、ゾーン間の自動切り替え機能を有効にした後、クラスターのパフォーマンスが約10% 低下します。デフォルトでは、トランザクションコミットまでの待機時間は500 msです。待機時間が500ミリ秒を超えると、レプリケーションモードは非同期レプリケーションに戻ります。フォールバックが発生しない場合、RPOは0である。
- 非同期および半同期複製では、RTOは30秒未満である。

パフォーマンステスト結果

説明

このトピックのテスト結果は、現在のバージョンのパフォーマンスのみを反映し、最新バージョンは反映しません。

テスト方法: 非同期レプリケーションを使用するPolarDB for MySQLクラスター、PolarDB for MySQL半同期レプリケーション、およびMySQL半同期レプリケーションのクエリ /秒 (QPS) パフォーマンスを比較します。クラスターの仕様は同じです。

テストツール: Sysbenchのoltp_write_onlyモード

クラスター仕様: 16コア64 GB

テスト済みのバージョン: PolarDB for MySQL 8.0.1、リビジョンバージョンは8.0.1.35.1です。最新バージョンとはわずかに異なる場合があります

データ量: 10個のデータテーブル、テーブルごとに1,000万行のデータ

semi-sync

並行性の高いシナリオでは、半同期レプリケーションが有効になった後、パフォーマンスの低下は約10% になります。 redoログに基づくPolarDB for MySQLの半同期レプリケーションのパフォーマンスは、バイナリログに基づくMySQL半同期レプリケーションのパフォーマンスよりも高くなります。

よくある質問

Q1: 半同期レプリケーションを有効にした後、パフォーマンスが10% 以上低下するのはなぜですか。

A1: 並行性の高いシナリオでは、最適なパフォーマンス低下は約10% です。これは、複数のredoログがバッチで処理されるためです。これにより、ネットワーク遅延によるオーバーヘッドが効果的に削減されます。並行性が低いシナリオでは、バッチ処理によるパフォーマンスの向上は明らかではないため、パフォーマンスが大幅に低下する可能性があります。 1つのスレッドのみを使用してデータを書き込む場合、リドゥI/Oをバッチで処理することはできません。半同期レプリケーションを有効にすると、ネットワークの往復遅延によりパフォーマンスが大幅に低下します。

Q2: innodb_polar_wait_slave_reply_max_timeパラメーターがコンソールに表示されないのはなぜですか。このパラメーターを適切な値に調整するにはどうすればよいですか?

A2: このパラメーターは、メジャーバージョンが8.0.1、リビジョンバージョンが8.0.1.1.44.2以降のPolarDB for MySQL Enterprise Editionクラスターでのみ使用できます。コンソールでパラメーターが見つからない場合は、クラスターバージョンが要件を満たしているかどうかを確認します。そうでない場合は、クラスターバージョンを更新します。詳細については、「マイナーバージョンの更新」をご参照ください。

通常、このパラメーターを手動で変更する必要はありません。デフォルト値は500 msです。特別な要件がある場合は、このパラメータを調整できます。たとえば、トランザクションをコミットする前に関連情報がセカンダリゾーンに同期されるまで待つ場合は、このパラメーターの値を増やすことができます。 500ミリ秒のデフォルト値は、ほとんどの場合に適切である。トランザクションコミットまでの待ち時間を制限する場合は、このパラメーターを小さい値に設定できます。一般に、一次ゾーンと二次ゾーンとの間のネットワーク待ち時間は1 ms以内である。半同期複製では、システムは少なくとも1つのネットワーク往復を待たなければならない。このパラメーターが0または1 msなどの小さな値に設定されている場合、システムは半同期レプリケーションから非同期レプリケーションに切り替えることができます。したがって、このパラメーターを変更するときは、実際の状況を考慮する必要があります。

Q3: 半同期複製の適応メカニズムはいつ有効になりますか? 半同期レプリケーションを有効にし、アダプティブメカニズムを無効にできますか?

A3: 半同期レプリケーションが有効になると、適応メカニズムが自動的に有効になります。システムは、プライマリゾーンとセカンダリゾーンの同期ステータスを自動的に監視し、リアルタイムでレプリケーションモードを調整します。アダプティブメカニズムを個別に無効にすることはできません。半同期レプリケーションを有効にしたい場合は、innodb_polar_wait_slave_reply_max_timeパラメーターを大きな値に設定します。適応メカニズムは、パラメータ値に基づいてタイムアウト状態を決定する。

Q4: フォールバックが発生しない場合、RPOは0である。フォールバックは、適応メカニズムによる半同期レプリケーションの動的な無効化を意味しますか?

A4: いいえ、適応メカニズムによる半同期レプリケーションのフォールバックと動的無効化が同じではありません。フォールバックが発生しない場合は、トランザクションをコミットする前に再実行情報をセカンダリゾーンに同期する必要があります。この場合、RPO値0を保証することができる。しかしながら、適応メカニズムは、トランザクションを監視するのではなく、ネットワークパケットの通信を監視する。適応メカニズムが半同期レプリケーションを無効にする場合、同期タイムアウトの場合に複数のトランザクションがコミットされている可能性があります。言い換えれば、たとえ半同期複製が適応メカニズムによって無効にされなくても、RPOは0ではないことがある。同期タイムアウトの場合、少数のトランザクションがコミットされる可能性は低い。半同期レプリケーション機能は、RPOが0に無限に近いことを保証します。