PolarDB:サービスモード

PolarDB-Xは、2つのモードでバイナリログ (binlog) を提供します。 2つのモードを同時に使用することができる。

• シングルストリームモード: シングルストリームモードは、Global Binlogモードとも呼ばれます。 このモードでは、すべてのデータノード (DN) のbinlogがグローバルキューにマージされます。 トランザクションの完全性と順序を保証する単一のログストリームが提供されます。 シングルストリームモードは、データの一貫性をより強く保証します。 たとえば、転送シナリオでは、PolarDB-XインスタンスのシングルストリームビンログをサブスクライブするダウンストリームMySQLデータベースで、いつでも一貫性のある残高を照会できます。

• マルチストリームモード: マルチストリームモードは、Binlog-Xモードとも呼ばれます。 このモードでは、すべてのDNのbinlogはグローバルキューにマージされません。 代わりに、ビンログはハッシュアルゴリズムを使用して異なるログストリームに分散されます。 マルチストリームモードは、トランザクションの完全性をある程度損なうが、拡張性を大幅に向上させる。 大規模クラスターのシングルストリームbinlogが直面するシングルポイントボトルネックを解決できます。

単一ストリームモード

すべてのDNの生のbinlogがソートされ、1つのキューにマージされ、内部の詳細が削除されます。 このように、PolarDB-Xは、MySQLのbinlog形式およびダンププロトコルと互換性のあるログストリームを提供します。 デフォルトでは、PolarDB-Xインスタンスを購入すると、シングルストリームbinlog機能が有効になります。

使用上の注意

• 変更データキャプチャ (CDC) コンポーネントのマスターノードとスレーブノードは、binlogファイルを相互に複製して、2つのノード間のデータの一貫性を確保します。 ダウンストリームシステムは、ファイル名と位置に基づいてbinlogを消費します。 マスターノードとスレーブノードの切り替えが発生しても, ファイル名と位置は変わりません。

• 分散トランザクションは、トランザクションポリシーがTimestamp Oracle (TSO) に設定されている場合にのみマージできます。 そうでない場合、データの最終的な一貫性のみを保証できます。 デフォルトでは、PolarDB-XはトランザクションポリシーとしてTSOを使用します。

• データ行のパーティションキー値を変更する必要がある場合は、トランザクションポリシーがTSOに設定されている分散トランザクション内で値が変更されていることを確認してください。 このように、DELETEイベントはINSERTイベントよりも早くbinlogに記録されます。 これによりデータの整合性が保証されます。 具体的には、データの一貫性を確保してパーティションキー値を変更するには、まずトランザクションポリシーをTSOに設定してから、次のいずれかの操作を実行する必要があります。

  • UPDATEステートメントを実行して、パーティションキーの値を変更します。

  • REPLACEステートメントを実行して、パーティションキーの値を変更します。

  • トランザクションを明示的に開始してDELETEステートメントを実行し、パーティションキーの値を変更してから、INSERTステートメントを実行します。

マルチストリームモード

マルチストリームbinlogは、MySQLのbinlog形式およびダンププロトコルと完全に互換性があります。 各binlogストリームは、スタンドアロンMySQLデータベースからのログストリームとして扱うことができます。 CHANGE MASTERやSHOW BINLOG EVENTSなどのSQL文を各ログストリームで実行して、ビンログを消費または表示できます。

デフォルトでは、マルチストリームbinlog機能は無効になっています。 マルチストリームbinlog機能を使用するには、コンソールでこの機能を個別に有効にする必要があります。 PolarDB-Xインスタンスに複数のマルチストリームグループを作成できます。 各マルチストリームグループは、複数のログストリームを含む。 異なるグループは互いに分離されています。 ビジネス要件に基づいて、マルチストリームグループのログストリーム数や分割レベルなどのパラメーターを設定できます。

レベルの分割

マルチストリームbinlog機能は、3つの分割レベルを提供します。 マルチストリームグループを作成するときに、ビジネスシナリオに基づいて分割レベルを設定できます。

• データベースレベル (顺番)

  Binlogは、データベース名を使用して計算されたハッシュ値に基づいて、異なるログストリームに分散されます。 このようにして、データベースのbinlogは常に同じログストリームに順番にルーティングされます。 この分割レベルは、単一のPolarDB-Xインスタンスに多数のデータベースがあるシナリオに適しています。 トランザクションにデータベース間の操作が含まれない場合、トランザクションの整合性は、データベースレベルで分割されるbinlogで保証できます。

• テーブルレベル (順番に)

  ビンログは、テーブル名を使用して計算されたハッシュ値に基づいて、異なるログストリームに分散されます。 このようにして、テーブルのbinlogは常に同じログストリームに順番にルーティングされます。 この分割レベルは、多数のテーブルが存在するシナリオに適しており、DML操作やDDL操作などの単一のテーブルに対する操作は、ログストリーム内で順番に保持されることが期待されます。

• 行レベル (順番に)

  ビンログは、データ行の主キー値を使用して計算されたハッシュ値に基づいて、異なるログストリームに分散されます。 このようにして、データ行のbinlogは常に同じログストリームに順番にルーティングされます。 この分割レベルは、binlogが完全に分散されることが予想され、データベースまたはテーブルに対して順番に保持する必要がないシナリオに適しています。 この分割レベルを使用するには、データテーブルにプライマリキーが含まれていることを確認します。 主キーを含まないテーブルのBinlogは直接破棄されます。

サービス層、データベースおよびテーブル層で分割レベルを設定できます。 レイヤーで分割レベルを設定した後は、分割レベルを変更することはできません。 それ以外の場合、同じビンログが異なるログストリームに表示されます。 これにより、データの不整合が発生します。 マルチストリームグループを作成する前に、ビジネス要件に基づいて分割レベルを計画することをお勧めします。

• サービス層

  サービス層で設定された分割レベルは、マルチストリームグループのデフォルトの分割レベルです。 データベースまたはテーブルの分割レベルを設定しない場合は、サービス層で設定された分割レベルが使用されます。

• データベースとテーブルのレイヤー

  データベースまたはテーブルの分割レベルを個別に設定できます。 データベースまたはテーブルに設定された分割レベルは、サービス層で設定された分割レベルよりも優先されます。 これは、差別化された管理の要件を満たします。

分割レベルが行レベルに (順番に) 設定されている場合、次の制限に注意してください。データテーブルにUNIQUE制約が含まれており、一意のキースワップが発生すると、データの不一致が発生する可能性があります。 次の図に示すように、idの値が1と2のデータ行には、一意のキー名の値aが連続して保持されます。 宛先データベース内のdelete(id=1,name=1) およびinsert(id=2,name=a) ステートメントの実行順序は不明です。 insert(id=2,name=2) ステートメントがdelete(id=1,name=1) ステートメントの前に実行されると、書き込み競合が発生します。 同様のシナリオでは、分割レベルをテーブルレベルに (順番に) 設定することをお勧めします。

使用上の注意

• マルチストリームグループを作成した後は、ログストリームの数を調整できません。 マルチストリームグループを作成する前に、ログストリームの数を計画します。 ログストリームの数をDNの数以上に設定することを推奨します。

• マルチストリームグループを作成した後、有効になる分割レベルを変更することはできません。 マルチストリームグループを作成する前に、分割レベルを計画することをお勧めします。

• 新しいテーブルの分割レベルを個別に設定する場合は、データがテーブルに書き込まれる前に分割レベルを設定します。

• 分割レベルが (順番に) テーブルレベルに設定されている場合でも、テーブルの名前を変更できます。 システムは常に初期テーブル名に基づいてデータを配信します。

• 分割レベルが (順番に) テーブルレベルに設定されている場合、大きなテーブルのbinlogは常に特定のログストリームにルーティングされます。 これにより、データスキューの問題が発生します。 この場合、大きなテーブルの分割レベルを個別に設定できます。

• 有効になるログストリームの数または分割レベルを調整する場合は、別のマルチストリームグループを作成して、元のマルチストリームグループを置き換えることができます。 この場合、ログ消費を調整するために、いくつかのO&M操作を下流のシステムで実行する必要があります。

• 次の表に、DDL文を各ログストリームに配信する方法を示します。

  分割レベル	配布モード	説明
  データベースレベル	ユニキャスト + 放送	CREATE DATABASEおよびDROP DATABASEステートメントは、すべてのログストリームにブロードキャストされます。 これは、データベース内のテーブルに個別の分割レベルを設定できるためです。 したがって、データベースの作成と削除をブロードキャストする必要があります。 他のタイプのDDLステートメントは、固定ログストリームにユニキャストされます。
  テーブルレベル	ユニキャスト + 放送	CREATE DATABASEおよびDROP DATABASEステートメントは、すべてのログストリームにブロードキャストされます。 これは、データベース内のテーブルに個別の分割レベルを設定できるためです。 したがって、データベースの作成と削除をブロードキャストする必要があります。 他のタイプのDDLステートメントは、固定ログストリームにユニキャストされます。
  行レベル	ブロードキャスト	すべてのタイプのDDL文は、すべてのログストリームにブロードキャストされます。

ビンログの透明な消費

CDCコンポーネントは、binlogファイルをローカルディスクに優先的に保存し、ファイルをObject storage Service (OSS) などのリモートストレージにリアルタイムでアップロードできます。 一般に、ファイルはローカルディスクに短期間保存され、リモートストレージには15日間などの長期間保存されます。 CDCコンポーネントは、ローカルディスクとリモートストレージ間のストレージの違いを保護する透過的な消費機能を提供します。 ダウンストリームシステムは、適応なしでリモートストレージ上のbinlogファイルにアクセスできます。 透過消費機能は、CDC V2.0.0以降でサポートされています。