PolarDB for MySQLは、データベースカーネルとリモートダイレクトメモリアクセス (RDMA) ネットワークを統合して、厳密に整合性のあるクラスター (SCC) 機能を提供します。 これにより、データのグローバルな一貫性が確保され、データの読み書きのパフォーマンスが向上します。 最終的な一貫性と比較して、SCCがクラスターに対して有効化されている場合、クラスターのパフォーマンス損失は10% 以内です。 このトピックでは、SCCの使用法ノート、技術原則、および有効化方法について説明し、クラスターパフォーマンスの比較結果を示します。
サポートされているバージョン
SCCを有効にする場合、PolarDB for MySQLクラスターは次のいずれかのバージョン要件を満たす必要があります。
エンジンバージョンは8.0.2で、リビジョンバージョンは8.0.2.2.19以降です。
エンジンバージョンは8.0.1で、リビジョンバージョンは8.0.1.1.29以降です。
エンジンバージョンは、5.7.1.0.26以降のリビジョンバージョンで5.7されます。
クラスターバージョンの確認方法の詳細については、「エンジンバージョン」トピックの「エンジンバージョンの照会」セクションをご参照ください。
使用上の注意
デフォルトでは、サーバーレスクラスターのすべての読み取り専用ノードに対してSCCが有効になっています。
グローバルデータベースネットワーク (GDN) のセカンダリクラスターの読み取り専用ノードに対してSCCを有効にすることはできません。
SCCは、高速クエリキャッシュ機能と互換性があります。 ただし、SCCで変更追跡テーブル (MTT) 最適化が有効になっていて、高速クエリキャッシュ機能とSCCの両方を有効にすると、MTT最適化は無効になります。
SCCの技術的な解決
SCCはPolarTransに基づいています。 これは、新しく設計されたタイムスタンプベースのトランザクションシステムであり、ネイティブMySQLのアクティブなトランザクションの数に基づく従来のトランザクション管理方法を再構築することを目的としています。 このシステムは、分散トランザクションの拡張をサポートするだけでなく、単一のクラスタのパフォーマンスを大幅に向上させます。
SCCの実装方法を次の図に示します。 RDMAネットワークは、対話型で多次元の一次 /二次情報同期を確立するために使用される。 これは、従来のプライマリ /セカンダリログレプリケーションアーキテクチャを置き換え、線形Lamportタイムスタンプアルゴリズムを使用して、読み取り専用ノードがタイムスタンプを取得する回数を減らし、ログ再生のための不要な待機時間を防ぎます。
線形ランポートタイムスタンプ: 読み取り専用ノードの効率を最適化して最新の変更されたタイムスタンプを取得するには、線形ランポートタイムスタンプが使用されます。 従来の方法では、読み取り専用ノードは、要求を処理するたびにプライマリノードからタイムスタンプを取得する必要があります。 この場合、ネットワーク速度が高速であっても、高負荷時には大きなオーバーヘッドが発生する。 線形ランポートタイムスタンプの利点は、読み取り専用ノードがプライマリノードから取得したタイムスタンプをローカルに格納できることです。 ローカルに格納されたタイムスタンプよりも早く読み取り専用ノードに到達する要求については、読み取り専用ノードは、プライマリノードから別のタイムスタンプを取得する必要なしに、ローカルタイムスタンプを直接使用することができる。 これは、高負荷の下で頻繁にタイムスタンプを要求することによって生成されるオーバーヘッドを効果的に低減し、読み取り専用ノードの性能を改善する。
階層的なきめ細かい変更の追跡: 読み取り専用ノードのパフォーマンスを最適化するために、プライマリノードでは、グローバルタイムスタンプ、テーブルレベルのタイムスタンプ、およびページレベルのタイムスタンプの3つのレベルのタイムスタンプが使用されます。 読み取り専用ノードがリクエストを処理すると、まずグローバルタイムスタンプを取得します。 グローバルタイムスタンプが読み取り専用ノードがログを再生するときに生成されたタイムスタンプよりも前の場合、読み取り専用ノードはすぐに待機状態にはなりません。 代わりに、読み取り専用ノードは、要求がアクセスするテーブルとページのタイムスタンプをチェックし続けます。 読み取り専用ノードは、リクエストのページレベルのタイムスタンプが条件を満たさない場合にのみ、ログの再生が完了するまで待機します。 これにより、ログ再生のための不要な待ち時間を効果的に防ぎ、読み取り専用ノードの応答速度を向上させます。
RDMAベースのログ出荷: SCCは片側RDMAインターフェイスを使用して、プライマリノードから読み取り専用ノードにログを出荷します。これにより、ログ出荷速度が大幅に向上し、ログ出荷によるCPUオーバーヘッドが削減されます。
Linear Lamportタイムスタンプ
読み取り専用ノードは、線形Lamportタイムスタンプを使用して、読み取り要求の待ち時間と帯域幅の消費を減らすことができます。 リクエストが読み取り専用ノードに到達すると、読み取り専用ノードが別のリクエストのためにプライマリノードからタイムスタンプが取得されたことを検出すると、読み取り専用ノードはタイムスタンプを直接再使用して、プライマリノードへのタイムスタンプのリクエストが繰り返されるのを防ぎます。
上の図では、2つの同時読み取り要求r 1とr 2が読み取り専用ノードに到達します。 読み取り専用ノードは、t 2でプライマリノードに要求を送信してr 2のタイムスタンプを取得し、t 3でプライマリノードからタイムスタンプTS 3 rwを取得する。 これらのイベントの関係を理解することができます: e 2 TS 3 rw e 3。 r 1はt 1で読み取り専用ノードに到達します。 読み取り専用ノード上の各イベントにタイムスタンプを割り当てることによって、読み取り専用ノード上のイベントのシーケンスを決定することができる。 t 1がt 2より前の場合、以下のイベント関係を得ることができる。e 1 e 2 TS 3 rw e 3。 言い換えれば、r 2に対して取得されたタイムスタンプは、r 1が読み取り専用ノードに到達する前に、すべての更新を既にカバーしている。 この場合、r 2のタイムスタンプは、新しいタイムスタンプを取得する必要なく、r 1に直接使用できます。 この原理に基づいて、読み取り専用ノードがプライマリノードからタイムスタンプを取得するたびに、読み取り専用ノードはタイムスタンプをローカルに保存し、タイムスタンプが取得された時刻を記録します。 リクエストの到着時刻が、ローカルにキャッシュされたタイムスタンプが取得された時刻よりも早い場合、タイムスタンプはリクエストに直接使用できます。
階層的できめ細かな修正トラッキング
データ読み取りの強い一貫性を実装するには、読み取り専用ノードは、最初にプライマリノードの現在のトランザクションによってコミットされた最新のタイムスタンプを取得し、そのログをタイムスタンプに再生してから、読み取り要求を処理する必要があります。 しかしながら、ログ再生中、要求されたデータは最新であり、読み取り専用ノードは、ログが再生されるまで待つ必要はない。 待機にかかる不要な時間を防ぐために、SCCはよりきめ細かい変更追跡を使用します。 グローバル・タイムスタンプ、テーブル・レベル・タイムスタンプ、およびページ・レベル・タイムスタンプの3つのレベルの変更情報がプライマリ・ノード上で維持されます。
読み取り専用ノードが読み取り要求を処理すると、まずグローバルタイムスタンプを取得してデータの整合性を確認します。 グローバルタイムスタンプが条件を満たさない場合、読み取り専用ノードは、より詳細な検証のために、宛先テーブルのローカルタイムスタンプを取得します。 テーブルレベルのタイムスタンプが依然として条件を満たさない場合、読み取り専用ノードは、さらなる検証のために宛先ページのタイムスタンプを取得する。 現在のページのタイムスタンプが、読み取り専用ノードがログを再生するタイムスタンプよりも遅い場合にのみ、読み取り専用ノードは、ログの再生が完了するまで待機して、最新のデータが確実に読み取られるようにする必要があります。
メモリ使用量を減らすために、3つのレベルのタイムスタンプがメモリ内のハッシュテーブルに格納されます。 メモリ使用をさらに最適化するために、複数のテーブルまたはページのタイムスタンプを同じハッシュテーブルにマッピングすることができる。 一貫性を確保するために、後のタイムスタンプのみを以前のタイムスタンプに置き換えることができます。 この設計により、読み取り専用ノードが後のタイムスタンプを取得しても一貫性が損なわれないようになります。 次の図は原理を示しています。 この図において、TIDはテーブルIDを示し、PIDはページIDを示す。 読み取り専用ノードによって取得されたタイムスタンプは、他の適格な要求の線形ランポートタイムスタンプの設計に基づいてローカルにキャッシュされます。
RDMAベースのログ配信
SCCでは、プライマリノードは、片側RDMAを介して読み取り専用ノードのキャッシュにログをリモートで書き込みます。 このプロセスは、読み取り専用ノードのCPUリソースを消費せず、低レイテンシを保証します。 次の図に示すように、読み取り専用ノードとプライマリノードの両方で、同じサイズのログバッファが保持されます。 プライマリノードのバックグラウンドスレッドは、プライマリノードのログバッファをRDMAを介して読み取り専用ノードのログバッファに書き込みます。 読み取り専用ノードは、レプリケーションの同期を高速化するために、ファイルを読み取る代わりにローカルログバッファを読み取ります。
RDMAベースのログ出荷の詳細については、「RDMAベースのログ出荷」をご参照ください。
SCCとグローバル整合性
PolarDBには、さまざまなシナリオでの整合性の要件を満たすために、次の4つの整合性レベルが用意されています。最終的な整合性、セッションの整合性、グローバル整合性、SCCです。
SCCは、元のグローバル一貫性レベルのアップグレードであり、グローバル一貫性よりも強力な一貫性に対する要件が厳しくなっています。 したがって、ビジネスシステムでより厳密な整合性が必要な場合は、SCCを使用することを推奨します。
PolarDB For MySQL 5.7、8.0.1、または8.0.2クラスターの場合、厳密な整合性が必要な場合は、SCCを推奨します。
PolarDB For MySQL 5.6クラスターの場合、このバージョンはSCCをサポートしていないため、厳密な整合性のためにグローバル整合性を選択できます。
グローバル整合性を有効にする方法の詳細については、「整合性レベル」トピックの「グローバル整合性」セクションをご参照ください。
SCCの有効化
PolarDB コンソールにログインします。 [クラスター] ページで、管理するクラスターを見つけ、そのIDをクリックしてクラスターの詳細ページに移動します。 [基本情報] ページの [データベースノード] セクションで、SCCを有効にする読み取り専用ノードにポインターを移動し、[SCCの有効化] をクリックします。
この機能は、新しい接続に対してのみ有効です。
読み取り専用ノードに対してSCCを有効にすると、SCCが無効になっているこの読み取り専用ノードと同じクラスターエンドポイントに属する他のノードの整合性レベルは自動的にセッション整合性に切り替えられます。 詳細については、「整合性レベル」トピックの「セッションの整合性」セクションをご参照ください。
性能比較
テスト環境
8 CPUコアと32 GBのメモリを備えたcluster EditionのPolarDB for MySQL 8.0クラスター。
テストツール
Sysbench
テストデータのサイズ
各テーブルに250,000行の25のテーブル
テスト結果
読み取りと書き込みのパフォーマンス
チャートの概要
qps: sysbenchテスト結果の1秒あたりのクエリ数 (QPS) 。
threads: テストで使用される同時sysbenchスレッドの数。
RW: プライマリノード上のQPS。 読み取り専用ノードがグローバルに一貫した読み取り操作を提供できない場合、すべての読み取り操作と書き込み操作がプライマリノードに送信されます。
グローバル整合性: グローバル整合性が有効なQPS。
SCC: 最終的な一貫性とSCCが有効になっているQPS。
最終的な一貫性: 読み取り操作に対して最終的な一貫性が有効になり、SCCが無効になっているQPS。
2つのクラスター間で読み書きのパフォーマンスをテストするシナリオでは、最終的に一貫性が有効になっているクラスターと比較して、SCCが有効になっているクラスターの全体的なパフォーマンス損失は10% 以内です。
