すべてのプロダクト
Search
ドキュメントセンター

PolarDB:整合性レベル

最終更新日:Jun 28, 2025

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 は物理レプリケーションを使用するため、セッション整合性を迅速に実現できます。

    4

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

  • シナリオ

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

グローバル整合性

  • 説明

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

    会话间存在的依赖关系

    PolarDB クラスタの PolarProxy が読み取りリクエストを受信すると、プライマリノードの最新の LSN をチェックします。オーバーヘッドを最小限に抑えるために、複数の読み取りリクエストがグループ化され、プライマリノードの LSN が一括でフェッチされます。最新の LSN(たとえば、LSN0)を取得した後、PolarProxy は少なくとも 1 つの読み取り専用ノードが LSN を LSN0 に同期するのを待機します。この同期が確認されると、PolarProxy は読み取りリクエストを読み取り専用ノードに転送します。このプロセスにより、読み取り操作で、リクエストが開始された時点までのすべてのコミット済み更新を反映したデータが取得されます。

    次の表に、グローバル整合性の構成パラメータを示します。

    パラメータ

    説明

    ConsistTimeout

    グローバル一貫性タイムアウト:PolarProxy が読み取りリクエストを受信した後、読み取り専用ノードがプライマリノードの最新の LSN に更新されるのを PolarProxy が待機する最大期間。期間がタイムアウトすると、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; を使用すると、エラーが発生する可能性があります。

整合性レベルの設定方法