すべてのプロダクト
Search

このプロダクト

    PolarDB:一貫性レベル

    ドキュメントセンター

    PolarDB:一貫性レベル

    最終更新日:Jun 04, 2024

    PolarDBは、整合性要件を満たすために、最終的な整合性、セッション整合性、グローバル整合性、およびグローバル整合性 (高性能モード) の整合性レベルを提供します。

    問題と解決策

    MySQLは、読み書き分離をサポートするプロキシを提供します。 プロキシは、アプリケーションからMySQLへの接続を確立し、SQL文を解析する。 次に、プロキシは、UPDATE、DELETE、INSERT、およびCREATE操作などの書き込み操作の要求をプライマリデータベースに転送し、SELECT操作の要求をセカンダリデータベースに転送します。 データベースの負荷が大きい場合、レプリケーションの遅延が増加します。 たとえば、DDL文を実行して大きなテーブルに列を追加したり、大量のデータを挿入したりすると、大きなレプリケーション遅延が発生します。 この場合、読み取り専用ノードから最新のデータを取得することはできません。 読み書き分離機能はこの問題を解決できません。

    PolarDBは、非同期物理レプリケーションを使用して、プライマリノードと読み取り専用ノード間でデータを同期します。 プライマリノードのデータが更新された後、更新は読み取り専用ノードに同期されます。 レプリケーション遅延は、プライマリノードの書き込み負荷によって異なります。 通常、複製遅延はわずか数ミリ秒である。 非同期レプリケーションは、プライマリノードと読み取り専用ノード間の最終的な一貫性を保証します。 PolarDBは、整合性要件を満たすために次の整合性レベルを提供します。

    最終的な一貫性。

    • 説明

      PolarDBは、読み書き分離アーキテクチャで実行されます。 従来の読み書き分離は、最終的な一貫性のみを保証します。 異なるノードから取り出された結果は、一次 /二次複製遅延のために異なり得る。 たとえば、セッション内で次のステートメントを繰り返し実行すると、SELECTステートメントによって異なる結果が返される場合があります。 実際のクエリ結果は、レプリケーションの遅延によって異なります。 

      INSERT INTO t1(id、price) 値 (111、96);
UPDATE t1 SET price = 100 WHERE id=111;
SELECT価格からt1;

    • シナリオ

      プライマリノードの負荷を軽減し、読み取り専用ノードにできるだけ多くの読み取り要求を送信するために、最終的な一貫性を選択することを推奨します。

    セッションの整合性。

    • 説明

      最終的な一貫性によって引き起こされるデータの不一致を排除するために、ほとんどの場合、要求は分割される。 高い整合性を必要とする要求は、プライマリノードに送信される。 少なくとも最終的な一貫性を必要とする要求は、読み書き分離機能を使用して読み取り専用ノードに送信されます。 ただし、これはプライマリノードの負荷を増加させ、読み書き分割のパフォーマンスを低下させ、アプリケーションの開発を複雑にします。

      この問題を解決するために、PolarDBはセッションの一貫性を提供します。 セッションの一貫性は、因果的一貫性としても知られています。 セッションの一貫性により、セッション内で読み取り要求が送信される前に更新されるデータを取得できるようになります。 これは、データが単調であることを保証する。

      PolarDBは、PolarProxyを使用して読み書き分離を実現します。 PolarProxyは、各ノードに適用されるredoログを追跡し、各ログシーケンス番号 (LSN) を記録します。 プライマリノードのデータが更新されると、PolarDBは新しい更新のLSNをセッションLSNとして記録します。 新しい読み取り要求が到着すると、PolarDBはセッションLSNを各ノードのLSNと比較し、LSNがセッションLSN以上であるノードに要求を転送します。 これにより、セッションの一貫性が確保されます。 このソリューションでは、PolarDBは物理レプリケーションを効率的に実行し、プライマリ負荷の負荷を増加させます。

      4

      効率的な同期を確保するために、読み取り専用ノードがクライアントに結果を返すときに、データは他の読み取り専用ノードにレプリケートされます。 これにより、後続の読み取り要求が到着する前に、読み取り専用ノードでデータを更新できます。 ほとんどのシナリオでは、多数の読み取り要求と少数の書き込み要求が存在します。 したがって、このメカニズムは、検証結果に基づいて、セッションの一貫性、読み取り /書き込み分割、および負荷分散を保証できます。

    • シナリオ

      PolarDBクラスターの整合性レベルが高いほど、プライマリデータベースの負荷が重くなり、クラスターのパフォーマンスが低下します。 セッションの一貫性を使用することを推奨します。 この一貫性レベルは、クラスターのパフォーマンスへの影響を最小限に抑え、ほとんどのシナリオの要件を満たします。

    グローバルな一貫性

    • 説明

      いくつかのシナリオでは、依存関係は個々のセッション内および異なるセッション間に存在する。 たとえば、接続プールを使用する場合、同じスレッドで実行されるリクエストは、異なる接続を使用して送信される可能性があります。 これらの要求は、データベース内の異なるセッションに属する。 ただし、これらの要求はビジネスプロセス内で相互に依存しており、セッションの一貫性はデータの一貫性を保証できません。 この問題を解決するために、PolarDBはグローバルな一貫性を提供します。

      会话间存在的依赖关系

      PolarDBクラスターのPolarProxyが読み取りリクエストを受信すると、PolarProxyはプライマリノードの最新のLSNをチェックします。 例えば、最新のLSNはLSN0である。 内部バッチ操作は、PolarProxyがプライマリノードで最新のLSNをクエリする回数を減らすように最適化されています。 次に、すべての読み取り専用ノードのLSNがLSN0に更新された後、PolarProxyは読み取り要求を読み取り専用ノードに送信します。 このように、読み出し要求に対して返されるデータは、読み出し要求が開始される前に更新された最新のデータである。

      次の表に、グローバル一貫性の設定パラメーターを示します。

      パラメーター

      説明

      ConsistTimeout

      グローバル一貫性タイムアウト: 読み取り専用ノードのLSNをプライマリノードの最新のLSNに更新するためのタイムアウト期間。 更新操作がタイムアウトすると、PolarDBが提供するPolarProxyは、ConsistTimeoutActionパラメーターで指定された操作を実行します。

      有効な値: 0 ~ 60000 デフォルト値は 20 です。 単位：ミリ秒。

      ConsistTimeoutAction

      グローバル一貫性タイムアウトポリシー。 ConsistTimeoutパラメーターで指定されたタイムアウト期間内に読み取り専用ノードのLSNをプライマリノードの最新の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の設定」をご参照ください。