このトピックでは、PolarDB for MySQL が物理レプリケーションアーキテクチャを活用してセミ同期レプリケーション（セミ同期）の効率を向上させ、プライマリゾーンへのパフォーマンスへの影響を軽減する仕組みについて説明します。背景情報、機能の詳細、注意事項、性能テスト、およびよくある質問を網羅しています。
背景情報
標準の MySQL は、バイナリログに基づくセミ同期レプリケーションを提供しています。このモードでは、トランザクションをコミットする前に、プライマリゾーンがセカンダリゾーンから当該トランザクションによって生成されたバイナリログの受信確認を受け取る必要があります。この同期方式は追加の遅延を生じさせ、プライマリゾーンの書き込みパフォーマンスに影響を与えます。
PolarDB for MySQL は、物理レプリケーションアーキテクチャを採用し、プライマリゾーンとセカンダリゾーン間で redo ログを効率的に同期します。このアプローチにより、セミ同期レプリケーションの効率が大幅に向上し、プライマリゾーンのパフォーマンス損失が軽減されます。高同時実行ワークロード下では、非同期レプリケーションと比較してパフォーマンスの低下は約 10 % です。
標準の MySQL におけるバイナリログベースのセミ同期レプリケーションと比較して、PolarDB for MySQL の物理レプリケーションベースのアプローチは、より高い同期効率を実現します。トランザクション実行中に redo ログレコードが生成され、リアルタイムでセカンダリゾーンにストリーミングされます。そのため、コミット時にプライマリゾーンは対応する redo ログレコードがセカンダリゾーンに正常に同期されたことを待つだけで済みます。一方、従来のバイナリログベースのセミ同期メカニズムでは、バイナリログ全体がコミット時点で初めて生成され、プライマリゾーンはそのバイナリログ全体が同期された後でのみクライアントに成功メッセージを返すことができます。
仕組み
PolarDB for MySQL のセミ同期レプリケーションは、物理レプリケーションアーキテクチャを活用し、redo ログを使用してプライマリゾーンとセカンダリゾーン間でデータを同期します。書き込みリクエストに対して、プライマリゾーンでデータが変更された際に redo ログレコードが生成され、物理レプリケーションリンク経由で同期されます。プライマリゾーンは、対応する書き込みトランザクションが成功応答を返す前に、セカンダリゾーンから redo ログの受信確認を待つ必要があります。
コミット前の最大待機時間
セカンダリゾーンの問題によりプライマリゾーンの書き込みリクエストが無期限にブロックされることを防ぐため、カーネルは書き込みトランザクションのコミット前の最大待機時間を制限しています。この期間内にセカンダリゾーンから確認応答が届かない場合、プライマリゾーンは自動的にトランザクションをコミットします。
アダプティブメカニズム
極端なケースでは、セカンダリゾーンがプライマリゾーンにタイムリーな確認応答を送信できないことがあります。これにより、すべての書き込みリクエストがタイムアウトするまで待機した後にコミットされ、パフォーマンスが低下する可能性があります。この問題を回避するため、セミ同期にはアダプティブメカニズムが組み込まれており、プライマリゾーンとセカンダリゾーン間のネットワーク通信を動的に監視します。タイムアウトが頻繁に発生する場合、システムは自動的に非同期レプリケーションにフォールバックし、プライマリゾーンの書き込み処理に影響が出ないようにします。同期状態が正常に戻ったと検出された場合、システムは自動的にセミ同期を再有効化します。
適用範囲
ご利用のクラスターは、以下の要件を満たしている必要があります。
製品エディション：Enterprise Edition および Standard Edition
エンジンバージョン：
MySQL 8.0.1：
リビジョンバージョン 8.0.1.35.1 以降：セミ同期を有効化できます。
リビジョンバージョン 8.0.1.1.40 以降：セミ同期を有効化でき、アダプティブメカニズムもサポートされます。
リビジョンバージョン 8.0.1.1.44.2 以降：セミ同期を有効化でき、トランザクションコミット前のデフォルトの最大待機時間を制御するための
innodb_polar_wait_slave_reply_max_timeパラメーターが利用可能です。デフォルト値は 500 ms です。
MySQL 8.0.2：リビジョンバージョン 8.0.2.2.32 以降：セミ同期を有効化でき、アダプティブメカニズムおよび
innodb_polar_wait_slave_reply_max_timeパラメーターもサポートされます。
注意事項
PolarDB for MySQL の物理レプリケーションベースのセミ同期モードは、クロスゾーン自動フェイルオーバー時のデータ整合性を大幅に向上させます。この機能の有効化手順については、「クロスゾーン自動フェイルオーバー」をご参照ください。
RPO および RTO：
非同期レプリケーションの場合、クロスゾーン自動フェイルオーバーはデータ損失を伴います。RPO は通常 100 ms 未満ですが、最悪のシナリオでは 60 秒未満となります。この機能をご利用になる前に、その影響を十分に評価してください。
セミ同期レプリケーションを有効化すると、パフォーマンスが約 10 % 低下します。トランザクションコミットのデフォルト待機時間は 500 ms です。この時間が超過した場合、システムは非同期レプリケーションにフォールバックし、セカンダリゾーンへの同期を待機しなくなります。フォールバックが発生しない場合、RPO は 0 になります。
非同期およびセミ同期レプリケーションのいずれにおいても、RTO は 30 秒未満です。
性能テスト
本トピックのテスト結果は、テスト対象バージョンのパフォーマンスを反映したものであり、最新バージョンのパフォーマンスを示すものではありません。
テスト方法：本テストでは、同一スペックのクラスターを用いて、次の 3 つのモードにおける秒間クエリ数 (QPS) パフォーマンスを比較しました。PolarDB for MySQL（非同期レプリケーション）、PolarDB for MySQL（セミ同期）、および標準 MySQL（セミ同期）です。
テストツール：Sysbench (oltp_write_only)。
テストスペック：16 コア、64 GB。
テスト対象バージョン：PolarDB for MySQL 8.0.1（リビジョンバージョン 8.0.1.35.1）。最新バージョンとは若干の差異がある可能性があります。
データ量：1,000 万行 × 10 テーブル。
結果として、高同時実行シナリオではセミ同期レプリケーションを有効化することでパフォーマンスが約 10 % 低下することが示されました。また、あらゆる同時実行レベルにおいて、PolarDB for MySQL の redo ログベースのセミ同期レプリケーションのパフォーマンスは、MySQL のバイナリログベースのセミ同期レプリケーションを上回ることが確認されました。
よくある質問
Q1：セミ同期を有効化した後、パフォーマンスの低下が 10 % を超えています。なぜでしょうか？
A1：高同時実行シナリオでは、パフォーマンス低下のベストケースが約 10 % です。これは、redo ログがバッチ処理されるため、ネットワーク遅延によるオーバーヘッドが効果的に低減されるためです。一方、低同時実行シナリオではバッチ処理によるパフォーマンス改善効果が小さく、より顕著なパフォーマンス低下を引き起こす可能性があります。書き込みスレッドが 1 本の場合、redo I/O はバッチ化されず、セミ同期レプリケーションの有効化によって追加されるネットワークラウンドトリップ遅延がパフォーマンスを大きく低下させます。
Q2：innodb_polar_wait_slave_reply_max_time パラメーターがコンソールに表示されません。適切な値に調整するにはどうすればよいですか？
A2：このパラメーターは、PolarDB for MySQL Enterprise Edition クラスターで、メジャーバージョン 8.0.1 かつリビジョンバージョン 8.0.1.1.44.2 以降の場合にのみ変更可能です。コンソールにパラメーターが表示されない場合は、まずご利用のクラスターバージョンが要件を満たしているかご確認ください。要件を満たしていない場合は、バージョンアップグレードを実施してください。
ほとんどのケースでは、このパラメーターを変更する必要はありません。デフォルト値は 500 ms です。特定の要件（例：トランザクションがコミットされる前に必ずセカンダリゾーンとの同期を待機させる必要がある場合）がある場合は、この値を増加させることができます。ただし、多くのシナリオではデフォルトの 500 ms で十分です。トランザクションの待機時間を制限したい場合は、パラメーター値を小さく設定することも可能です。ただし、0 ms や 1 ms など非常に小さな値を設定すると、セミ同期モードが非同期レプリケーションにフォールバックする可能性があります。これは、可用性ゾーン間のネットワーク遅延が通常 1 ms 以内である一方で、セミ同期レプリケーションには少なくとも 1 回のネットワークラウンドトリップが必要となるためです。このパラメーターを変更する際は、ご利用環境のネットワーク遅延を考慮してください。
Q3：セミ同期のアダプティブメカニズムはどのようなタイミングで有効になりますか？セミ同期を有効化しつつ、アダプティブメカニズムを無効化することは可能ですか？
A3：現在、セミ同期を有効化すると、アダプティブメカニズムもデフォルトで有効になります。このメカニズムはプライマリゾーンとセカンダリゾーン間の同期状態を動的に監視し、リアルタイムで調整を行います。アダプティブメカニズムを個別に無効化することはできません。セミ同期機能を常にアクティブに保ちたい場合は、innodb_polar_wait_slave_reply_max_time をより大きな値に設定できます。アダプティブメカニズムはこのパラメーターを使用してタイムアウトを検出します。
Q4：セミ同期がフォールバックしない場合の RPO は 0 とのことですが、この「フォールバック」とアダプティブメカニズムによるセミ同期の動的無効化は同じ意味ですか？
A4：これらは異なる概念です。「フォールバックなし」とは、トランザクションの redo ログがセカンダリゾーンに同期された後でのみコミットされることを意味します。この場合、RPO が厳密に 0 であることが保証されます。一方、アダプティブメカニズムはトランザクションレベルではなくネットワークパケットレベルで監視を行っています。アダプティブメカニズムがセミ同期を動的に無効化するのは、通常、複数のトランザクションがすでに同期タイムアウトによりコミットされた後です。言い換えれば、セミ同期が有効化されており、アダプティブメカニズムによって無効化されていなくても、RPO が厳密に 0 であるとは限りません。同期タイムアウトにより少数のトランザクションがコミットされる可能性がありますが、これはまれなイベントです。したがって、セミ同期機能は RPO を 0 に近づけることを保証します。