PolarDBは、整合性要件を満たすために、最終的な整合性、セッション整合性、グローバル整合性、およびグローバル整合性 (高性能モード) の整合性レベルを提供します。
問題と解決策
MySQLは、読み書き分離をサポートするプロキシを提供します。 プロキシは、アプリケーションからMySQLへの接続を確立し、SQL文を解析する。 次に、プロキシは、UPDATE、DELETE、INSERT、およびCREATE操作などの書き込み操作の要求をプライマリデータベースに転送し、SELECT操作の要求をセカンダリデータベースに転送します。 データベースの負荷が大きい場合、レプリケーションの遅延が増加します。 たとえば、DDL文を実行して大きなテーブルに列を追加したり、大量のデータを挿入したりすると、大きなレプリケーション遅延が発生します。 この場合、読み取り専用ノードから最新のデータを取得することはできません。 読み書き分離機能はこの問題を解決できません。
PolarDBは、非同期物理レプリケーションを使用して、プライマリノードと読み取り専用ノード間でデータを同期します。 プライマリノードのデータが更新された後、更新は読み取り専用ノードに同期されます。 レプリケーション遅延は、プライマリノードの書き込み負荷によって異なります。 ほとんどの場合、レプリケーション遅延はわずか数ミリ秒です。 非同期レプリケーションは、プライマリノードと読み取り専用ノード間の最終的な一貫性を保証します。 PolarDBは、整合性要件を満たすために次の整合性レベルを提供します。
最終的な一貫性
説明
PolarDBは読み書き分離アーキテクチャを使用します。 従来の読み書き分離は、最終的な一貫性のみを保証します。 異なるノードから取り出された結果は、一次 /二次複製遅延のために異なり得る。 たとえば、セッション内で次のステートメントを繰り返し実行すると、SELECTステートメントによって異なる結果が返される場合があります。 実際のクエリ結果は、レプリケーションの遅延によって異なります。
INSERT INTO t1(id, price) VALUES(111, 96); UPDATE t1 SET price = 100 WHERE id=111; SELECT price FROM t1;シナリオ
プライマリノードの負荷を軽減し、読み取り専用ノードにできるだけ多くの読み取り要求を送信するために、最終的な一貫性を選択することを推奨します。
セッションの整合性
説明
最終的な一貫性によって引き起こされるデータの不一致を排除するために、ほとんどの場合、要求は分割される。 高い整合性を必要とする要求は、プライマリノードに送信される。 少なくとも最終的な一貫性を必要とする要求は、読み書き分離機能を使用して読み取り専用ノードに送信されます。 ただし、これはプライマリノードの負荷を増加させ、読み書き分割のパフォーマンスを低下させ、アプリケーションの開発を複雑にします。
この問題を解決するために、PolarDBはセッションの一貫性を提供します。 セッションの一貫性により、セッション内で読み取り要求が送信される前に更新されたデータを取得できるようになります。 これは、データが単調であることを保証する。
PolarDBは、PolarProxyを使用して読み書き分離を実現します。 PolarProxyは、各ノードに適用されるredoログを追跡し、各ノードのログシーケンス番号 (LSN) を記録します。 データが更新されるたびに、PolarDBは更新のLSNをセッションLSNとして記録します。 新しい読み取り要求が受信されると、PolarDBはセッションLSNを各ノードのLSNと比較し、LSNがセッションLSN以上であるノードに要求を転送します。 読み取り専用ノードのLSNがセッションLSNより小さい場合、PolarDBは、指定されたタイムアウト期間内にノードが最新のデータに更新された場合にのみ、要求をノードに転送します。 これにより、セッションの一貫性が確保されます。 このソリューションは、プライマリノードの負荷を増加させる可能性があります。 ただし、PolarDBは物理レプリケーションを使用するため、セッションの一貫性をすばやく実現できます。
効率的な同期を確保するために、読み取り専用ノードがクライアントに結果を返すときに、データは他の読み取り専用ノードにレプリケートされます。 これにより、後続の読み取り要求が到着する前に、読み取り専用ノードでデータを更新できます。 ほとんどのシナリオでは、多数の読み取り要求と少数の書き込み要求が存在します。 したがって、このメカニズムは、検証結果に基づいて、セッションの一貫性、読み取り /書き込み分割、および負荷分散を保証できます。
シナリオ
PolarDBクラスターの整合性レベルが高いほど、プライマリデータベースの負荷が重くなり、クラスターのパフォーマンスが低下します。 セッションの一貫性を使用することを推奨します。 この一貫性レベルは、クラスターのパフォーマンスへの影響を最小限に抑え、ほとんどのシナリオの要件を満たします。
グローバルな一貫性
説明
いくつかのシナリオでは、依存関係は個々のセッション内および異なるセッション間に存在する。 たとえば、接続プールを使用する場合、同じスレッドで実行されるリクエストは、異なる接続を使用して送信される可能性があります。 これらの要求は、データベース内の異なるセッションに属する。 これらのリクエストはビジネスプロセス内で相互に依存しており、セッションの一貫性はデータの一貫性を保証できません。 この問題を解決するために、PolarDBはグローバルな一貫性を提供します。
PolarDBクラスターのPolarProxyが読み取りリクエストを受信すると、PolarProxyはプライマリノードの最新のLSNをチェックします。 例えば、最新のLSNはLSN0である。 内部バッチ操作は、PolarProxyがプライマリノードで最新のLSNをクエリする回数を減らすように最適化されています。 すべての読み取り専用ノードのLSNがLSN0に更新された後、PolarProxyは読み取り要求を読み取り専用ノードに送信します。 このように、読み出し要求に対して返されるデータは、読み出し要求が開始される前に更新された最新のデータである。
次の表に、グローバル一貫性の設定パラメーターを示します。
パラメーター
説明
ConsistTimeout
グローバル一貫性タイムアウト: PolarProxyが読み取り要求を受信した後、読み取り専用ノードがプライマリノードの最新のLSNに更新されるのをPolarProxyが待機する最大期間。 デュレーションがタイムアウトした場合、PolarProxyはConsistTimeoutActionパラメーターで指定された操作を実行します。
有効な値: 0 ~ 60000 デフォルト値は 20 です。 単位：ミリ秒。
ConsistTimeoutAction
グローバル一貫性タイムアウトポリシー: 読み取り専用ノードのLSNが、ConsistTimeoutパラメーターで指定されたタイムアウト期間内にプライマリノードの最新のLSNに更新されない場合、PolarDBが提供するPolarProxyは、ConsistTimeoutActionパラメーターで指定された操作を実行します。
有効な値：
0: PolarProxyは読み取り要求をプライマリノードに送信します。 デフォルト値です。
1: PolarProxyは、
wait replication complete timeout, please retryエラーメッセージをアプリケーションに返します。
説明グローバル一貫性タイムアウトおよびグローバル一貫性タイムアウトポリシーパラメーターの変更方法については、「PolarProxyの設定」をご参照ください。
シナリオ
プライマリ /セカンダリレプリケーションの遅延が大きい場合、グローバル一貫性を使用すると、多数のリクエストがプライマリノードに転送される可能性があります。 これは、プライマリノード上の負荷を増加させ、サービス待ち時間を増加させ得る。 したがって、多数の読み取り要求と少数の書き込み要求が処理されるシナリオでは、グローバル一貫性を使用することを推奨します。
グローバル整合性 (高性能モード)
PolarDB for MySQLは、グローバルな一貫性 (高性能モード) を提供します。 グローバル一貫性 (高パフォーマンスモード) は、グローバル一貫性よりも高いデータ一貫性レベルである強力なデータ一貫性をサポートします。
PolarTransは、コミットタイムスタンプストア (CTS) とリモートダイレクトメモリアクセス (RDMA) を使用して、カーネルレベルでグローバルな一貫性 (高性能モード) を提供します。 これにより、クラスター内の読み取り専用ノード宛てのすべての読み取り要求に対して、強力な一貫性が実装されます。
制限、動作方法、機能の有効化方法、パフォーマンスデータなど、グローバル整合性 (高パフォーマンスモード) の詳細については、「グローバル整合性 (高パフォーマンスモード) 」をご参照ください。
整合性レベルの選択方法
PolarDBクラスターの整合性レベルが高いほど、クラスターパフォーマンスが低いことを示します。
セッション整合性を使用することを推奨します。 この一貫性レベルは、クラスターのパフォーマンスへの影響を最小限に抑え、ほとんどのシナリオの要件を満たします。
異なるセッション間で高いデータ一貫性が必要な場合は、次のいずれかのソリューションを選択できます。
グローバル整合性 (高パフォーマンスモード) またはグローバル整合性を使用します。
説明PolarDB For MySQL 5.7、8.0.1、または8.0.2クラスターの場合、厳密な整合性が必要な場合は、グローバル整合性 (高パフォーマンスモード) を推奨します。
PolarDB For MySQL 5.6クラスターの場合、このバージョンはグローバル一貫性 (高パフォーマンスモード) をサポートしていないため、厳密な一貫性のためにグローバル一貫性を選択できます。
ヒントを使用して、特定のクエリをプライマリノードに強制的に送信します。
/*FORCE_MASTER*/ select * from user;説明MySQLの公式コマンドラインでヒントを含む上記のステートメントを実行する場合は、ステートメントに -cパラメーターを追加します。 それ以外の場合、ヒントはMySQLの公式コマンドラインで除外されるため、ヒントは無効になります。 詳細については、「mysqlクライアントオプション」をご参照ください。
ヒントは、ルーティングのために最高の優先順位が割り当てられ、一貫性レベルまたはトランザクション分割によって制限されません。 ヒントを使用する前に、ビジネスへの影響を評価してください。
ヒントには、環境変数を変更するSQLステートメントを含めることはできません。 たとえば、
/* FORCE_SLAVE */ set names utf8;を使用すると、エラーが発生する可能性があります。
整合性レベルを設定する方法は?
グローバル整合性 (ハイパフォーマンスモード) を有効にする方法については、「グローバル整合性 (ハイパフォーマンスモード) 」をご参照ください。
整合性レベルを最終的な整合性、セッション整合性、またはグローバル整合性に設定する方法については、「PolarProxyの設定」をご参照ください。