PolarDB:一貫性レベル

問題と解決策

データレプリケーションは、プライマリノードからPolarDBの読み取り専用ノードにデータをレプリケートするために使用される簡単な方法です。 プライマリノードの先読みログ (WAL) を読み取り専用ノードに非同期で転送するだけです。 データレプリケーションにより、読み取り専用ノードでクエリを処理できます。 これにより、プライマリノードの負荷が軽減され、高可用性が保証されます。 読み取り専用ノードを使用して読み取り要求を処理すると、次の問題が発生する可能性があります。

• 1. 通常、プライマリデータベースとセカンダリデータベースは異なるエンドポイントを提供します。 異なるデータベースにアクセスする場合は、アプリケーションのコードを変更して、データベースへの接続に使用するエンドポイントを変更する必要があります。

• 2. データは非同期的にレプリケートされます。 クライアントがデータ変更をコミットした後、データはすぐにリードレプリカに同期されない場合があります。 読み取り専用ノードのデータは最新ではない場合があります。 この場合、データは一致しません。

最初の問題を解決するために、PolarDBはPolarProxyをプロキシとして使用して読み書き分離操作を実行します。 ほとんどの場合、プロキシはアプリケーションからPolarDBへの接続を確立し、各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以上であるノードに要求を転送する。 これにより、セッションの一貫性が確保されます。 PolarDBは、効率的な方法で物理レプリケーションを実行します。

  

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

• 適用シナリオ

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

一貫性レベルのベストプラクティス

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

• 異なるセッション間で高いデータ一貫性が必要な場合は、次のいずれかのソリューションを選択できます。

  ヒントを使用して、特定のクエリをプライマリノードに強制的に送信します。

  /* FORCE_MASTER */ select * from user;

  説明

  • MySQLの公式コマンドラインでヒントを含む上記のステートメントを実行する場合は、ステートメントに -cパラメーターを追加します。 それ以外の場合、MySQLの公式コマンドラインがヒントを除外するため、ヒントは無効になります。 詳細については、「mysqlクライアントオプション」をご参照ください。

  • ヒントは、ルーティングのために最高の優先順位が割り当てられ、一貫性レベルまたはトランザクション分割によって制限されません。 ヒントを使用する前に、ビジネスへの影響を評価してください。

  • ヒントには、環境変数を変更するステートメントを含めることはできません。 たとえば、/* FORCE_SLAVE */ set names utf8; ステートメントを実行すると、エラーが発生する可能性があります。