:バイナリログ

PolarDB-Xは、2つのモードでバイナリログ機能をサポートしています。 このトピックでは、2つのモードとそのシナリオについて説明します。

使用上の注意

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

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

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

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

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

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

マルチストリームモード

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

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

分割レベル

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

• データベースレベル

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

• テーブルレベル

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

• レコードレベル

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

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

• サービス層

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

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

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

使用上の注意

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

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

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

• 分割レベルをtableに設定した後、テーブルの名前を変更できます。 PolarDB-Xは常に初期テーブル名に基づいてログを分割します。

• 分割レベルがテーブルに設定されている場合、大きなテーブルのバイナリログは、いくつかの特定のログストリームにルーティングされる可能性があります。 これにより、データスキューの問題が発生します。 この場合、大きなテーブルの分割レベルを個別に設定できます。

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

• 分割レベルがレコードに設定されている場合、データテーブルにUNIQUE制約が含まれ、一意のキースワップが発生すると、データの不一致が発生する可能性があります。 例えば、固有キー名の値aは、id値が1及び2であるデータ行によって連続して保持される。 移行先データベース内のdelete(id=1,name=1) 文とinsert(id=2,name=a) 文の実行順序は不明です。 insert(id=2,name=2) ステートメントがdelete(id=1,name=1) ステートメントの前に実行されると、書き込み競合が発生します。 この場合、分割レベルをtableに設定することを推奨します。

透明な消費

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

アクティブなgeo冗長性

外部システムをデータストレージとして使用することに加えて、PolarDB-XのCDCコンポーネントは、アクティブなgeo冗長アーキテクチャでのビジネス展開をサポートします。 たとえば、ユーザーが属する地域に基づいて、さまざまなデータセンターに対する書き込み権限がユーザーに付与されます。 この場合、ユーザーは指定されたデータセンターにのみデータを書き込むことができます。 読み取り動作の場合、各ユーザは、ユーザが存在する地理的領域に最も近いレプリカからデータを読み取ることができる。 PolarDB-Xは、データがデータセンターに書き込まれるときに、CDCコンポーネントを使用してデータをレプリカに同期します。