PolarDB-Xはバイナリログを提供しません。 データ品質を確保するために、ビジネス設計、ビジネス開発、およびO&M変更を実行する際の制限に注意することを推奨します。
概要
ビジネスデザインに関する制限
すべてのテーブルにプライマリキーが必要です。 そうしないと、データの不一致が発生する可能性があります (宛先データベースに重複データレコードが含まれる可能性があります) 。
PolarDB-Xのグローバルセカンダリインデックス (GSI) は非同期で更新されるため、使用しないことを推奨します。 GSIを使用する場合、DTSはデータの最終的な一貫性のみを保証できます。
同期するデータベースは、ユニットモードとコピーモードが混在している混在モードでは展開できません。
説明ユニットモードでは、ユーザーはそれぞれのユニットノードで読み取りおよび書き込み操作を実行します。 各ユニットノード内のデータベースと中央ノード内のデータベースとの間で、双方向同期が実施される。 コピーモードでは、ユーザーは中央ノードのデータベースにデータを書き込みます。 次いで、データは、各ユニットノード内のデータベースに同期される。
PolarDB-Xの基盤となるMySQLデータベースを使用して双方向データ同期タスクを設定する場合、FloatおよびDoubleデータ型をビジネステーブル用のDecimalに変換する必要があります。 一方向データ同期タスク、データ移行タスク、または変更追跡タスクのソースインスタンスとしてPolarDB-Xを使用する場合、Floatデータ型とDoubleデータ型を変換する必要はありません。
データ同期タスク、データ移行タスク、および変更追跡タスクは、PolarDB-Xの次のオブジェクト (ストアドプロシージャ、トリガー、関数、ビュー、およびイベント) をサポートしていません。
DTSは、PolarDB-Xのスキーマ同期をサポートしていません。 ターゲットインスタンスにデータベースやテーブルなどのオブジェクトを手動で作成する必要があります。
ソースPolarDB-Xインスタンスには、ビジネスの成長をサポートするのに十分な容量が必要です。
バージョン5.7と8.0のMySQLデータベースがPolarDB-Xインスタンスで実行されている場合、PolarDB-Xインスタンスを変更追跡タスクのソースインスタンスとして使用することはできません。 PolarDB-Xインスタンスのデータを追跡および使用するには、MySQLデータベースごとに変更追跡タスクを設定する必要があります。
データベースアーキテクチャに関する制限
PolarDB-Xインスタンスで使用されているApsaraDB RDS for MySQLインスタンスは、他のPolarDB-Xインスタンスでは使用できません。
PolarDB-Xインスタンス間のデータ同期または移行の場合、ソースとターゲットのApsaraDB RDS For MySQLインスタンスに同等のデプロイが必要です。 たとえば、ソースPolarDB-Xインスタンスが4つのApsaraDB RDS For MySQLインスタンスを使用している場合、ターゲットPolarDB-Xインスタンスも同じ仕様の4つのApsaraDB RDS for MySQLインスタンスを使用する必要があります。
ソースインスタンスとターゲットPolarDB-Xインスタンスのシャーディングルールは同じである必要があります。 そうしないと、データ同期または移行タスクを作成できません。
PolarDB-Xインスタンスのビジネステーブルのデータを同期、移行、または追跡できます。 インスタンス内のメタデータテーブルまたはシステムテーブルのデータを同期、移行、または追跡することはできません。
O&Mの変更に関連する制限
カテゴリ | 説明 | インパクトとソリューション |
PolarDB-X | シャーディングルールを変更します。たとえば、データベースやテーブルのシャードキーを変更したり、シャードの数を変更したりします。 | サポートされていません。 タスクを再作成するには、次の手順を実行する必要があります。
|
ストレージ層のインスタンス数を変更します。たとえば、インスタンスをスケールアウトしたり、頻繁にアクセスされるテーブルを移行したりします。 | ||
ストレージレイヤー | ストレージ層でインスタンスの仕様を変更し、ワークロードを切り替えます。 | DTSタスクは影響を受けません。 |
パラメータ設定を変更します。 | ソースデータベースとターゲットデータベースのパラメーター設定は同じである必要があります。 ストレージレイヤーでインスタンスのパラメーター設定を変更するには、新しいパラメーターが以前のパラメーターに影響を与えないようにする必要があります。 説明 パラメーター設定の変更による影響がわからない場合は、Database Expert Serviceのテクニカルサポートにお問い合わせください。 | |
バックアップとリカバリのポリシーを変更し、ストレージ層でインスタンスの監査と診断を有効にします。 | 変更は現在のインスタンスにのみ有効であり、レプリケーション関係を持つ他のインスタンスには影響しません。 | |
DTSタスク | DDL操作を実行します。 | PolarDB-Xインスタンス内の複数のApsaraDB RDS for MySQLインスタンスからターゲットデータベースにデータをレプリケートするようにDTSタスクを設定した場合、DDL操作を実行するとタスクの待ち時間が発生する可能性があります。 |
データベースまたはテーブルレベルでのDDL操作 | テーブルを追加します。 | サポートされていません。 次の手順を実行する必要があります。
上記の操作が完了した後にのみ、ソースデータベースにデータを書き込むことができます。 データ同期タスクのオブジェクトとしてテーブルを選択した場合、ストレージ層のソースインスタンスとターゲットインスタンスの同期キューに新しいテーブルを追加する必要があります。 |
フィールドの追加、セカンダリインデックスの追加、インデックスの削除、インデックスの変更 (セカンダリインデックスを一意のインデックスに置き換える場合を除く) 。 |
| |
その他のDDL操作を実行します。 | 前述のDDL操作のみがサポートされています。 | |
切り替え 説明 切り替え: DTSを使用してソースデータベースからターゲットデータベースにデータを同期または移行した後、ワークロードをソースデータベースからターゲットデータベースに切り替えます。 | 切り替えを実行します。 | 切り替えを実行する前に、DTSタスクが遅延していないことを確認してください。 そうでない場合、データ品質の問題が発生します。 |
リカバリポイント目標 (RPO) の要件を満たすフェールオーバーを実行します。 説明 RPOは、障害からの回復後に失われる可能性のあるデータの最大量を表します。 RPOは時間によって測定される。 警告 フェイルオーバー: ソースインスタンスまたはソースインスタンスが存在するデータセンターに障害が発生した場合、ワークロードをバックアップシステムに切り替えることができます。 フェイルオーバーは非可逆操作です。 | 障害 (ネットワークの中断、機器の障害、インターネットデータセンターの障害など) が発生し、DTSタスクが遅延した場合は、フェールオーバーを実行する必要があります。 この場合、最後のデータエントリがターゲットデータベースに更新された時刻と障害が発生した時刻の差がRPOよりも小さい場合は、フェールオーバーを実行して業務を回復できます。 たとえば、RPOが5分の場合、フェールオーバーを実行した後、5分以内のデータの品質は保証されません。 一貫性を確保するためにデータを修正する必要がある場合があります。 | |
RPOの要件を満たさないフェールオーバーを実行します。 | DTSタスクは、次の理由により遅延する可能性があります。ソースデータベースで多数のDDL操作が実行され、ネットワーク障害が発生し、ターゲットデータベースのパフォーマンスが低下します。 この場合、データセンターに障害が発生し、最後のデータエントリがターゲットデータベースに更新された時刻と障害が発生した時刻の差がRPOより大きい場合は、データセンターが復旧するまで待ってからフェールオーバーを実行することをお勧めします。 たとえば、RPOが5分の場合、フェールオーバーを実行した後、5分以内のデータの品質は保証されません。 一貫性を確保するためにデータを修正する必要がある場合があります。 |
データ品質に関連する潜在的なリスク
一部の変更または切り替え操作では、ソースデータベースとターゲットデータベース間のスキーマの不一致など、データ品質の問題が発生する場合があります。
ソースインスタンスのプライマリデータベースとセカンダリデータベースの間でデータ遅延が発生した場合、プライマリデータベースに書き込まれたデータはセカンダリデータベースにタイムリーに更新されません。 この場合、ソースインスタンスでプライマリ /セカンダリの切り替えを実行すると、DTSはソースインスタンスのセカンダリデータベースをソースデータベースとして使用し、データ同期、データ移行、または変更の追跡を行います。 その結果、セカンダリデータベースに更新されていないデータが失われます。
切り替えを実行した後にDTSタスクがネットワーク障害から再開された場合、DTSは、障害が発生する前に生成されたデータの同期、移行、または追跡を試みます。 このメカニズムは、宛先データベースのデータ損失を防ぎます。 この場合、ターゲットテーブルにプライマリキーがない場合、ソースデータベースとターゲットデータベースの間でデータが不整合になります。 宛先テーブルにプライマリキーがある場合、DTSが再試行メカニズムを実装したときにデータが一致しない場合がありますが、再試行が終了した後もデータは一致したままです。
DTSタスクは、ネットワーク障害およびDDL動作のために遅延する可能性がある。
DTSタスクは、ソースデータベースへの変更、ターゲットデータベースの不利なパフォーマンス、およびスキーマの不一致により、遅延または中断される可能性があります。
Alibaba Cloudは上記の問題を解決できません。 DTSタスクを再作成するか、ソースデータベースとターゲットデータベースを調整する必要があります。
データ品質を確保するための提案
すべてのDDL操作は慎重に実行する必要があります。 すべてのDDL操作は技術的なエンジニアによって前の限界に従うために確認されなければなりません。
プログラムコードでDDL操作を直接実行しないでください。