ソースデータベースが PolarDB for MySQL クラスターである場合の注意事項と制限 - Data Transmission Service

ソースクラスターが PolarDB for MySQL クラスターである場合、データ同期タスクを設定する前に、このトピックの注意事項と制限を確認してください。これにより、タスクが正常に実行されるようになります。

PolarDB for MySQL ソースインスタンスの同期シナリオの概要

同期シナリオの注意事項と制限を確認してください:

説明

デフォルトでは、DTS はターゲットデータベースにデータを同期する際に外部キー制約を無効にします。したがって、ソースデータベースでのカスケードや削除などの操作は、次のタイプのターゲットデータベースには同期されません:

MySQL (ApsaraDB RDS for MySQL および自己管理 MySQL)
PolarDB for MySQL
PolarDB-X 1.0
AnalyticDB for MySQL
AnalyticDB for PostgreSQL
Elasticsearch

PolarDB for MySQL クラスター間の同期
PolarDB for MySQL から ApsaraDB RDS for MySQL または自己管理 MySQL への同期
PolarDB for MySQL から PolarDB-X 1.0 への同期
PolarDB for MySQL から AnalyticDB for MySQL への同期
PolarDB for MySQL から Alibaba Cloud DataHub への同期
PolarDB for MySQL から Elasticsearch への同期
PolarDB for MySQL から Alibaba Cloud Message Queue for Apache Kafka または自己管理 Kafka への同期
PolarDB for MySQL から AnalyticDB for PostgreSQL への同期
PolarDB for MySQL から MaxCompute への同期
PolarDB for MySQL から自己管理 Oracle への同期

PolarDB for MySQL クラスター間の同期

次の表に、注意事項と制限を示します。

タイプ	説明
ソースデータベースの制限	同期するテーブルには、プライマリキーまたは一意制約が必要であり、フィールドは一意である必要があります。そうでない場合、ターゲットデータベースに重複データが表示される可能性があります。説明双方向同期インスタンスで同期するテーブルにプライマリキーまたは一意制約がない場合は、Exactly-Once 書き込み機能を有効にできます。詳細については、「プライマリキーまたは一意制約のないテーブルを同期する」をご参照ください。テーブルレベルでデータを同期し、列名のマッピングなどのテーブルを編集する必要がある場合、1 つのデータ同期タスクでサポートされるテーブルは最大 1,000 です。この制限を超えると、タスクの送信時にエラーが報告されます。この場合、テーブルを複数の同期タスクに分割するか、データベース全体を同期するタスクを設定します。バイナリログ: バイナリログを有効にし、`loose_polar_log_bin` パラメーターを `ON` に設定する必要があります。そうしないと、事前チェック中にエラーが報告され、DTS インスタンスの起動に失敗します。バイナリログの有効化とパラメーターの変更の詳細については、「バイナリログを有効にする」および「クラスターとノードのパラメーターを設定する」をご参照ください。説明 PolarDB for MySQL クラスターのバイナリログを有効にすると、ストレージ領域が消費され、料金が発生します。 PolarDB for MySQL クラスターのバイナリログは、少なくとも 3 日間保持する必要があります。7 日間保持することをお勧めします。そうしないと、DTS がバイナリログを取得できないため、DTS タスクが失敗する可能性があります。極端な場合、これによりデータの不整合やデータ損失が発生する可能性があります。必要な期間よりも短いバイナリログ保持期間によって引き起こされた問題は、DTS サービスレベルアグリーメント (SLA) の対象外です。説明 PolarDB for MySQL クラスターのバイナリログの保持期間を設定する方法の詳細については、「保持期間の変更」をご参照ください。初期スキーマ同期および初期完全同期中は、データベースまたはテーブルのスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ同期タスクは失敗します。
その他の制限	ソース PolarDB for MySQL クラスターの読み取り専用ノードからデータを同期することはできません。ソース PolarDB for MySQL クラスターから OSS 外部テーブルを同期することはできません。 INDEX と PARTITION の同期はサポートされていません。初期完全同期中のデータベースインスタンスのプライマリ/セカンダリフェールオーバーはサポートされていません。フェールオーバーが発生した場合は、同期タスクを速やかに再設定してください。複数のテーブルのマージなど、ソースデータベースで一時テーブルを使用するオンライン DDL 操作を実行すると、ターゲットデータベースでデータが失われたり、同期インスタンスが失敗したりする可能性があります。同期インスタンスの実行中にプライマリキーまたは一意キーの競合が発生した場合: ソースデータベースとターゲットデータベースのスキーマが同じで、ターゲットデータベースのデータレコードのプライマリキー値または一意キー値がソースデータベースのデータレコードと同じ場合: 完全なデータ同期中、DTS はデータレコードをターゲットデータベースに同期しません。ターゲットデータベース内の既存のデータレコードは保持されます。増分データ同期中、DTS はデータレコードをターゲットデータベースに同期します。ターゲットデータベース内の既存のデータレコードは上書きされます。ソースデータベースとターゲットデータベースのスキーマが異なる場合、データの初期化に失敗することがあります。この場合、一部の列のみが同期されるか、データ同期インスタンスが失敗します。注意して進めてください。 DTS は、コメント構文を使用して定義されたパーサを同期しません。同期するデータに、一般的でない文字や絵文字など、4 バイトのストレージを必要とするコンテンツが含まれている場合、ターゲットデータベースとテーブルは utf8mb4 文字セットを使用する必要があります。説明 DTS を使用してスキーマを同期する場合、ターゲットデータベースのインスタンスレベルのパラメーター `character_set_server` を utf8mb4 に設定する必要があります。データを同期する前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。オフピーク時にデータを同期することをお勧めします。そうしないと、初期完全同期によってソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースが消費され、データベースの負荷が増加する可能性があります。初期完全同期では同時 INSERT 操作が実行されるため、ターゲットデータベーステーブルに断片化が発生します。その結果、初期完全同期の完了後、ターゲットインスタンスの表領域はソースインスタンスの表領域よりも大きくなります。テーブルレベルのデータ同期の場合、pt-online-schema-change などのツールを使用してソースデータベースの同期オブジェクトに対してオンライン DDL 操作を実行しないでください。そうしないと、同期が失敗します。テーブルレベルのデータ同期の場合、DTS からのデータ以外のデータがターゲットデータベースに書き込まれない場合は、Data Management (DMS) を使用してオンライン DDL 操作を実行できます。詳細については、「テーブルをロックせずにスキーマを変更する」をご参照ください。 DTS 同期中は、DTS からのデータ以外のデータをターゲットデータベースに書き込まないでください。そうしないと、ソースデータベースとターゲットデータベースの間でデータの不整合が発生する可能性があります。たとえば、他のデータがターゲットデータベースに書き込まれている間に DMS を使用してオンライン DDL 操作を実行すると、ターゲットデータベースでデータが失われる可能性があります。 DDL 操作がターゲットデータベースへの書き込みに失敗した場合、DTS タスクは実行を継続します。失敗した DDL 操作については、タスクログを確認する必要があります。タスクログの表示方法の詳細については、「タスクログの表示」をご参照ください。ソースデータベースからアカウントを同期するには、前提条件を満たし、関連する注意事項を理解する必要があります。詳細については、「データベースアカウントを移行する」をご参照ください。インスタンスに障害が発生した場合、DTS ヘルプデスクは 8 時間以内にインスタンスの回復を試みます。回復プロセス中に、インスタンスの再起動やパラメーターの調整などの操作が実行される場合があります。説明パラメーターが調整されると、DTS インスタンスのパラメーターのみが変更されます。データベースのパラメーターは変更されません。変更される可能性のあるパラメーターには、インスタンスパラメーターの変更に記載されているものが含まれますが、これらに限定されません。
その他の注意事項	PolarDB for MySQL クラスター間の双方向同期: DTS は現在、2 つの PolarDB for MySQL クラスター間でのみ双方向同期をサポートしています。複数の PolarDB for MySQL クラスター間での双方向同期はサポートされていません。 DDL 構文の同期方向の制限。双方向同期リンクの安定性とデータ整合性を確保するために、フォワード DDL 同期のみがサポートされています。リバース DDL 同期はサポートされていません。双方向同期タスクが実行されているとき、DTS はデータループ同期を防ぐために、フォワードタスクとリバースタスクのターゲットデータベースに DTS という名前のデータベースを作成します。タスクの実行中はこのデータベースを変更しないでください。また、タスクに使用されるデータベースアカウントにこのデータベースに対する読み取りおよび書き込み権限があることを確認してください。双方向同期インスタンスには、フォワードタスクとリバースタスクが含まれます。双方向同期インスタンスを設定またはリセットするときに、一方のタスクのターゲットオブジェクトがもう一方のタスクの同期オブジェクトである場合: 完全データと増分データの両方を同期できるのは 1 つのタスクのみです。もう一方のタスクは増分データのみを同期できます。現在のタスクのソースデータは、現在のタスクの宛先にのみ同期できます。同期されたデータは、他のタスクのソースデータとして使用されません。 DTS は、ソースデータベースで CREATE DATABASE IF NOT EXISTS `test` コマンドを定期的に実行して、バイナリログのオフセットを進めます。

PolarDB for MySQL から ApsaraDB RDS for MySQL または自己管理 MySQL への同期

次の表に、注意事項と制限を示します。

タイプ	説明
ソースデータベースの制限	同期するテーブルには、プライマリキーまたは一意制約が必要であり、フィールドは一意である必要があります。そうでない場合、ターゲットデータベースに重複データが表示される可能性があります。説明双方向同期インスタンスで同期するテーブルにプライマリキーまたは一意制約がない場合は、Exactly-Once 書き込み機能を有効にできます。詳細については、「プライマリキーまたは一key制約のないテーブルを同期する」をご参照ください。テーブルレベルでデータを同期し、列名のマッピングなどのテーブルを編集する必要がある場合、1 つのデータ同期タスクでサポートされるテーブルは最大 1,000 です。この制限を超えると、タスクの送信時にエラーが報告されます。この場合、テーブルを複数の同期タスクに分割するか、データベース全体を同期するタスクを設定します。バイナリログ: バイナリログを有効にし、`loose_polar_log_bin` パラメーターを `ON` に設定する必要があります。そうしないと、事前チェック中にエラーが報告され、DTS インスタンスの起動に失敗します。バイナリログの有効化とパラメーターの変更の詳細については、「バイナリログを有効にする」および「クラスターとノードのパラメーターを設定する」をご参照ください。説明 PolarDB for MySQL クラスターのバイナリログを有効にすると、ストレージ領域が消費され、料金が発生します。 PolarDB for MySQL クラスターのバイナリログは、少なくとも 3 日間保持する必要があります。7 日間保持することをお勧めします。そうしないと、DTS がバイナリログを取得できないため、DTS タスクが失敗する可能性があります。極端な場合、これによりデータの不整合やデータ損失が発生する可能性があります。必要な期間よりも短いバイナリログ保持期間によって引き起こされた問題は、DTS サービスレベルアグリーメント (SLA) の対象外です。説明 PolarDB for MySQL クラスターのバイナリログの保持期間を設定する方法の詳細については、「保持期間の変更」をご参照ください。初期スキーマ同期および初期完全同期中は、データベースまたはテーブルのスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ同期タスクは失敗します。
その他の制限	ソース PolarDB for MySQL クラスターの読み取り専用ノードからデータを同期することはできません。ソース PolarDB for MySQL クラスターから OSS 外部テーブルを同期することはできません。 INDEX と PARTITION の同期はサポートされていません。初期完全同期中のデータベースインスタンスのプライマリ/セカンダリフェールオーバーはサポートされていません。フェールオーバーが発生した場合は、同期タスクを速やかに再設定してください。複数のテーブルのマージなど、ソースデータベースで一時テーブルを使用するオンライン DDL 操作を実行すると、ターゲットデータベースでデータが失われたり、同期インスタンスが失敗したりする可能性があります。 DTS は、コメント構文を使用して定義されたパーサを同期しません。同期インスタンスの実行中にプライマリキーまたは一意キーの競合が発生した場合: ソースデータベースとターゲットデータベースのスキーマが同じで、ターゲットデータベースのデータレコードのプライマリキー値または一意キー値がソースデータベースのデータレコードと同じ場合: 完全なデータ同期中、DTS はデータレコードをターゲットデータベースに同期しません。ターゲットデータベース内の既存のデータレコードは保持されます。増分データ同期中、DTS はデータレコードをターゲットデータベースに同期します。ターゲットデータベース内の既存のデータレコードは上書きされます。ソースデータベースとターゲットデータベースのスキーマが異なる場合、データの初期化に失敗することがあります。この場合、一部の列のみが同期されるか、データ同期インスタンスが失敗します。注意して進めてください。同期するデータに、一般的でない文字や絵文字など、4 バイトのストレージを必要とするコンテンツが含まれている場合、ターゲットデータベースとテーブルは utf8mb4 文字セットを使用する必要があります。説明 DTS を使用してスキーマを同期する場合、ターゲットデータベースのインスタンスレベルのパラメーター `character_set_server` を utf8mb4 に設定する必要があります。データを同期する前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。オフピーク時にデータを同期することをお勧めします。そうしないと、初期完全同期によってソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースが消費され、データベースの負荷が増加する可能性があります。初期完全同期では同時 INSERT 操作が実行されるため、ターゲットデータベーステーブルに断片化が発生します。その結果、初期完全同期の完了後、ターゲットインスタンスの表領域はソースインスタンスの表領域よりも大きくなります。テーブルレベルのデータ同期の場合、pt-online-schema-change などのツールを使用してソースデータベースの同期オブジェクトに対してオンライン DDL 操作を実行しないでください。そうしないと、同期が失敗します。テーブルレベルのデータ同期の場合、DTS からのデータ以外のデータがターゲットデータベースに書き込まれない場合は、Data Management (DMS) を使用してオンライン DDL 操作を実行できます。詳細については、「テーブルをロックせずにスキーマを変更する」をご参照ください。 DTS 同期中は、DTS からのデータ以外のデータをターゲットデータベースに書き込まないでください。そうしないと、ソースデータベースとターゲットデータベースの間でデータの不整合が発生する可能性があります。たとえば、他のデータがターゲットデータベースに書き込まれている間に DMS を使用してオンライン DDL 操作を実行すると、ターゲットデータベースでデータが失われる可能性があります。 DDL 操作がターゲットデータベースへの書き込みに失敗した場合、DTS タスクは実行を継続します。失敗した DDL 操作については、タスクログを確認する必要があります。タスクログの表示方法の詳細については、「タスクログの表示」をご参照ください。大文字と小文字のみが異なる名前のフィールドをターゲットの MySQL データベースの同じテーブルに書き込むと、同期結果が期待どおりにならない場合があります。これは、MySQL データベースの列名では大文字と小文字が区別されないためです。データ同期が完了した後 (インスタンスのステータスが完了になった後)、`analyze table <table_name>` コマンドを使用して、すべてのデータがターゲットテーブルに書き込まれたことを確認することをお勧めします。たとえば、ターゲットの MySQL データベースで HA スイッチオーバーメカニズムがトリガーされた後、データがメモリにのみ書き込まれ、データが失われる可能性があります。双方向同期インスタンスには、フォワードタスクとリバースタスクが含まれます。双方向同期インスタンスを設定またはリセットするときに、一方のタスクのターゲットオブジェクトがもう一方のタスクの同期オブジェクトである場合: 完全データと増分データの両方を同期できるのは 1 つのタスクのみです。もう一方のタスクは増分データのみを同期できます。現在のタスクのソースデータは、現在のタスクの宛先にのみ同期できます。同期されたデータは、他のタスクのソースデータとして使用されません。インスタンスに障害が発生した場合、DTS ヘルプデスクは 8 時間以内にインスタンスの回復を試みます。回復プロセス中に、インスタンスの再起動やパラメーターの調整などの操作が実行される場合があります。説明パラメーターを調整する場合、DTS インスタンスのパラメーターのみが変更されます。データベースのパラメーターは変更されません。変更される可能性のあるパラメーターには、インスタンスパラメーターの変更で説明されているパラメーターが含まれますが、これらに限定されません。
その他の注意事項	DTS は、ソースデータベースで CREATE DATABASE IF NOT EXISTS `test` コマンドを定期的に実行して、バイナリログのオフセットを進めます。

PolarDB for MySQL から PolarDB-X 1.0 への同期

次の表に、注意事項と制限を示します。

タイプ	説明
ソースデータベースの制限	同期するテーブルには、プライマリキーまたは一意制約が必要であり、フィールドは一意である必要があります。そうでない場合、ターゲットデータベースに重複データが表示される可能性があります。テーブルレベルでデータを同期し、列名のマッピングなどのテーブルを編集する必要がある場合、1 つのデータ同期タスクでサポートされるテーブルは最大 1,000 です。この制限を超えると、タスクの送信時にエラーが報告されます。この場合、テーブルを複数の同期タスクに分割するか、データベース全体を同期するタスクを設定します。バイナリログ: バイナリログを有効にし、`loose_polar_log_bin` パラメーターを `ON` に設定する必要があります。そうしないと、事前チェック中にエラーが報告され、DTS インスタンスの起動に失敗します。バイナリログの有効化とパラメーターの変更の詳細については、「バイナリログを有効にする」および「クラスターとノードのパラメーターを設定する」をご参照ください。説明 PolarDB for MySQL クラスターのバイナリログを有効にすると、ストレージ領域が消費され、料金が発生します。 PolarDB for MySQL クラスターのバイナリログは、少なくとも 3 日間保持する必要があります。7 日間保持することをお勧めします。そうしないと、DTS がバイナリログを取得できないため、DTS タスクが失敗する可能性があります。極端な場合、これによりデータの不整合やデータ損失が発生する可能性があります。必要な期間よりも短いバイナリログ保持期間によって引き起こされた問題は、DTS サービスレベルアグリーメント (SLA) の対象外です。説明 PolarDB for MySQL クラスターのバイナリログの保持期間を設定する方法の詳細については、「保持期間の変更」をご参照ください。完全なデータ同期中、データベースまたはテーブルのスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ同期タスクは失敗します。
その他の制限	同期オブジェクトの要件: BIT、VARBIT、GEOMETRY、ARRAY、UUID、TSQUERY、TSVECTOR、および TXID_SNAPSHOT 型のデータの同期はサポートされていません。プレフィックスインデックスの同期はサポートされていません。ソースデータベースにプレフィックスインデックスがある場合、データ同期が失敗する可能性があります。ソース PolarDB for MySQL クラスターの読み取り専用ノードからデータを同期することはできません。ソース PolarDB for MySQL クラスターから OSS 外部テーブルを同期することはできません。初期完全同期中のデータベースインスタンスのプライマリ/セカンダリフェールオーバーはサポートされていません。フェールオーバーが発生した場合は、同期タスクを速やかに再設定してください。複数のテーブルのマージなど、ソースデータベースで一時テーブルを使用するオンライン DDL 操作を実行すると、ターゲットデータベースでデータが失われたり、同期インスタンスが失敗したりする可能性があります。初期スキーマ同期はサポートされていません。同期タスクを設定する前に、ターゲットインスタンスに対応するデータベースとテーブルを作成する必要があります。同期インスタンスの実行中にプライマリキーまたは一意キーの競合が発生した場合: ソースデータベースとターゲットデータベースのスキーマが同じで、ターゲットデータベースのデータレコードのプライマリキー値または一意キー値がソースデータベースのデータレコードと同じ場合: 完全なデータ同期中、DTS はデータレコードをターゲットデータベースに同期しません。ターゲットデータベース内の既存のデータレコードは保持されます。増分データ同期中、DTS はデータレコードをターゲットデータベースに同期します。ターゲットデータベース内の既存のデータレコードは上書きされます。ソースデータベースとターゲットデータベースのスキーマが異なる場合、データの初期化に失敗することがあります。この場合、一部の列のみが同期されるか、データ同期インスタンスが失敗します。注意して進めてください。データを同期する前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。オフピーク時にデータを同期することをお勧めします。そうしないと、初期完全同期によってソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースが消費され、データベースの負荷が増加する可能性があります。初期完全同期では同時 INSERT 操作が実行されるため、ターゲットデータベーステーブルに断片化が発生します。その結果、初期完全同期の完了後、ターゲットインスタンスの表領域はソースインスタンスの表領域よりも大きくなります。テーブルレベルのデータ同期の場合、pt-online-schema-change などのツールを使用してソースデータベースの同期オブジェクトに対してオンライン DDL 操作を実行しないでください。そうしないと、同期が失敗します。テーブルレベルのデータ同期の場合、DTS からのデータ以外のデータがターゲットデータベースに書き込まれない場合は、Data Management (DMS) を使用してオンライン DDL 操作を実行できます。詳細については、「テーブルをロックせずにスキーマを変更する」をご参照ください。 DTS 同期中は、DTS からのデータ以外のデータをターゲットデータベースに書き込まないでください。そうしないと、ソースデータベースとターゲットデータベースの間でデータの不整合が発生する可能性があります。たとえば、他のデータがターゲットデータベースに書き込まれている間に DMS を使用してオンライン DDL 操作を実行すると、ターゲットデータベースでデータが失われる可能性があります。インスタンスに障害が発生した場合、DTS ヘルプデスクは 8 時間以内にインスタンスの回復を試みます。回復プロセス中に、インスタンスの再起動やパラメーターの調整などの操作が実行される場合があります。説明パラメーターを調整する場合、DTS インスタンスのパラメーターのみが変更されます。データベースのパラメーターは変更されません。変更される可能性のあるパラメーターには、インスタンスパラメーターの変更で説明されているパラメーターが含まれますが、これらに限定されません。
その他の注意事項	DTS は、ソースデータベースで CREATE DATABASE IF NOT EXISTS `test` コマンドを定期的に実行して、バイナリログのオフセットを進めます。

PolarDB for MySQL から AnalyticDB for MySQL への同期

次の表に、注意事項と制限を示します。

タイプ	説明
ソースデータベースの制限	同期するテーブルには、プライマリキーまたは一意制約が必要であり、フィールドは一意である必要があります。そうでない場合、ターゲットデータベースに重複データが表示される可能性があります。テーブルレベルでデータを同期し、列名のマッピングなどのテーブルを編集する必要がある場合、1 つのデータ同期タスクでサポートされるテーブルは最大 1,000 です。この制限を超えると、タスクの送信時にエラーが報告されます。この場合、テーブルを複数の同期タスクに分割するか、データベース全体を同期するタスクを設定します。バイナリログ: バイナリログを有効にし、`loose_polar_log_bin` パラメーターを `ON` に設定する必要があります。そうしないと、事前チェック中にエラーが報告され、DTS インスタンスの起動に失敗します。バイナリログの有効化とパラメーターの変更の詳細については、「バイナリログを有効にする」および「クラスターとノードのパラメーターを設定する」をご参照ください。説明 PolarDB for MySQL クラスターのバイナリログを有効にすると、ストレージ領域が消費され、料金が発生します。 PolarDB for MySQL クラスターのバイナリログは、少なくとも 3 日間保持する必要があります。7 日間保持することをお勧めします。そうしないと、DTS がバイナリログを取得できないため、DTS タスクが失敗する可能性があります。極端な場合、これによりデータの不整合やデータ損失が発生する可能性があります。必要な期間よりも短いバイナリログ保持期間によって引き起こされた問題は、DTS サービスレベルアグリーメント (SLA) の対象外です。説明 PolarDB for MySQL クラスターのバイナリログの保持期間を設定する方法の詳細については、「保持期間の変更」をご参照ください。同期中に、`ALTER TABLE table_name COMMENT='Table comment';` などのテーブルへのコメントの追加やプライマリキーの変更などの DDL 操作を実行しないでください。そうしないと、データ同期中に DDL 操作の実行に失敗します。初期スキーマ同期および初期完全同期中は、データベースまたはテーブルのスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ同期タスクは失敗します。
その他の制限	プレフィックスインデックスの同期はサポートされていません。ソースデータベースにプレフィックスインデックスがある場合、データ同期が失敗する可能性があります。初期完全同期中のデータベースインスタンスのプライマリ/セカンダリフェールオーバーはサポートされていません。フェールオーバーが発生した場合は、同期タスクを速やかに再設定してください。複数のテーブルのマージなど、ソースデータベースで一時テーブルを使用するオンライン DDL 操作を実行すると、ターゲットデータベースでデータが失われたり、同期インスタンスが失敗したりする可能性があります。同期インスタンスの実行中にプライマリキーまたは一意キーの競合が発生した場合: ソースデータベースとターゲットデータベースのスキーマが同じで、ターゲットデータベースのデータレコードのプライマリキー値または一意キー値がソースデータベースのデータレコードと同じ場合: 完全なデータ同期中、DTS はデータレコードをターゲットデータベースに同期しません。ターゲットデータベース内の既存のデータレコードは保持されます。増分データ同期中、DTS はデータレコードをターゲットデータベースに同期します。ターゲットデータベース内の既存のデータレコードは上書きされます。ソースデータベースとターゲットデータベースのスキーマが異なる場合、データの初期化に失敗することがあります。この場合、一部の列のみが同期されるか、データ同期インスタンスが失敗します。注意して進めてください。ターゲットデータベースにはカスタムプライマリキーが必要です。または、データベーステーブル列の設定ステップでプライマリキー列の追加を設定する必要があります。そうしないと、データ同期が失敗する可能性があります。ソース PolarDB for MySQL クラスターの読み取り専用ノードからデータを同期することはできません。 INDEX、PARTITION、VIEW、PROCEDURE、FUNCTION、TRIGGER、および FK の同期はサポートされていません。ソース PolarDB for MySQL クラスターから OSS 外部テーブルを同期することはできません。 AnalyticDB for MySQL の制限により、AnalyticDB for MySQL クラスター内のノードのディスク領域使用率が 80% を超えると、DTS タスクが異常になり、レイテンシーが発生します。同期するオブジェクトに基づいて必要な領域を事前に見積もり、宛先クラスターに十分なストレージ領域があることを確認してください。 DTS タスクの実行中に宛先の AnalyticDB for MySQL 3.0 クラスターがバックアップされている場合、タスクは失敗します。データを同期する前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。オフピーク時にデータを同期することをお勧めします。そうしないと、初期完全同期によってソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースが消費され、データベースの負荷が増加する可能性があります。初期完全同期では同時 INSERT 操作が実行されるため、ターゲットデータベーステーブルに断片化が発生します。その結果、初期完全同期の完了後、ターゲットインスタンスの表領域はソースインスタンスの表領域よりも大きくなります。テーブルレベルのデータ同期の場合、pt-online-schema-change などのツールを使用してソースデータベースの同期オブジェクトに対してオンライン DDL 操作を実行しないでください。そうしないと、同期が失敗します。テーブルレベルのデータ同期の場合、DTS からのデータ以外のデータがターゲットデータベースに書き込まれない場合は、Data Management (DMS) を使用してオンライン DDL 操作を実行できます。詳細については、「テーブルをロックせずにスキーマを変更する」をご参照ください。 DTS 同期中は、DTS からのデータ以外のデータをターゲットデータベースに書き込まないでください。そうしないと、ソースデータベースとターゲットデータベースの間でデータの不整合が発生する可能性があります。たとえば、他のデータがターゲットデータベースに書き込まれている間に DMS を使用してオンライン DDL 操作を実行すると、ターゲットデータベースでデータが失われる可能性があります。 DDL 操作がターゲットデータベースへの書き込みに失敗した場合、DTS タスクは実行を継続します。失敗した DDL 操作については、タスクログを確認する必要があります。タスクログの表示方法の詳細については、「タスクログの表示」をご参照ください。インスタンスに障害が発生した場合、DTS ヘルプデスクは 8 時間以内にインスタンスの回復を試みます。回復プロセス中に、インスタンスの再起動やパラメーターの調整などの操作が実行される場合があります。説明パラメーターを調整する場合、DTS インスタンスのパラメーターのみが変更されます。データベースのパラメーターは変更されません。変更される可能性のあるパラメーターには、インスタンスパラメーターの変更で説明されているパラメーターが含まれますが、これらに限定されません。
その他の注意事項	DTS は、ソースデータベースで CREATE DATABASE IF NOT EXISTS `test` コマンドを定期的に実行して、バイナリログのオフセットを進めます。

PolarDB for MySQL から AnalyticDB for PostgreSQL への同期

次の表に、注意事項と制限を示します。

タイプ	説明
ソースデータベースの制限	同期するテーブルには、プライマリキーまたは一意制約が必要であり、フィールドは一意である必要があります。そうでない場合、ターゲットデータベースに重複データが表示される可能性があります。テーブルレベルでデータを同期し、列名のマッピングなどのテーブルを編集する必要がある場合、1 つのデータ同期タスクでサポートされるテーブルは最大 1,000 です。この制限を超えると、タスクの送信時にエラーが報告されます。この場合、テーブルを複数の同期タスクに分割するか、データベース全体を同期するタスクを設定します。バイナリログ: バイナリログを有効にし、`loose_polar_log_bin` パラメーターを `ON` に設定する必要があります。そうしないと、事前チェック中にエラーが報告され、DTS インスタンスの起動に失敗します。バイナリログの有効化とパラメーターの変更の詳細については、「バイナリログを有効にする」および「クラスターとノードのパラメーターを設定する」をご参照ください。説明 PolarDB for MySQL クラスターのバイナリログを有効にすると、ストレージ領域が消費され、料金が発生します。 PolarDB for MySQL クラスターのバイナリログは、少なくとも 3 日間保持する必要があります。7 日間保持することをお勧めします。そうしないと、DTS がバイナログを取得できないため、DTS タスクが失敗する可能性があります。極端な場合、これによりデータの不整合やデータ損失が発生する可能性があります。必要な期間よりも短いバイナリログ保持期間によって引き起こされた問題は、DTS サービスレベルアグリーメント (SLA) の対象外です。説明 PolarDB for MySQL クラスターのバイナリログの保持期間を設定する方法の詳細については、「保持期間の変更」をご参照ください。同期中に、`ALTER TABLE table_name COMMENT='Table comment';` などのテーブルへのコメントの追加やプライマリキーの変更などの DDL 操作を実行しないでください。そうしないと、データ同期中に DDL 操作の実行に失敗します。ソースデータベースで同期するデータに `0000-00-00 00:00:00` の日付データが含まれている場合、タスクが失敗することがあります。説明 DTS は、この日付データをターゲットデータベースに同期するときに `null` に変換します。ソースデータを一時的に `0001-01-01 00:00:00` に変更するか、ターゲットデータベースの対応するフィールドに null 値を許可するように設定できます。初期スキーマ同期および初期完全同期中は、データベースまたはテーブルのスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ同期タスクは失敗します。
その他の制限	同期オブジェクトの要件: テーブルレベルの同期のみがサポートされています。 BIT、VARBIT、GEOMETRY、ARRAY、UUID、TSQUERY、TSVECTOR、および TXID_SNAPSHOT 型のデータの同期はサポートされていません。プレフィックスインデックスの同期はサポートされていません。ソースデータベースにプレフィックスインデックスがある場合、データ同期が失敗する可能性があります。ソース PolarDB for MySQL クラスターの読み取り専用ノードからデータを同期することはできません。ソース PolarDB for MySQL クラスターから OSS 外部テーブルを同期することはできません。 PARTITION、VIEW、PROCEDURE、FUNCTION、TRIGGER、FK、および INDEX の同期はサポートされていません。初期完全同期中のデータベースインスタンスのプライマリ/セカンダリフェールオーバーはサポートされていません。フェールオーバーが発生した場合は、同期タスクを速やかに再設定してください。複数のテーブルのマージなど、ソースデータベースで一時テーブルを使用するオンライン DDL 操作を実行すると、ターゲットデータベースでデータが失われたり、同期インスタンスが失敗したりする可能性があります。同期インスタンスの実行中にプライマリキーまたは一意キーの競合が発生した場合: ソースデータベースとターゲットデータベースのスキーマが同じで、ターゲットデータベースのデータレコードのプライマリキー値または一意キー値がソースデータベースのデータレコードと同じ場合: 完全なデータ同期中、DTS はデータレコードをターゲットデータベースに同期しません。ターゲットデータベース内の既存のデータレコードは保持されます。増分データ同期中、DTS はデータレコードをターゲットデータベースに同期します。ターゲットデータベース内の既存のデータレコードは上書きされます。ソースデータベースとターゲットデータベースのスキーマが異なる場合、データの初期化に失敗することがあります。この場合、一部の列のみが同期されるか、データ同期インスタンスが失敗します。注意して進めてください。同期するテーブルにプライマリキーがある場合、ターゲットテーブルのプライマリキー列はソーステーブルのプライマリキー列と同じでなければなりません。同期するテーブルにプライマリキーがない場合、ターゲットテーブルのプライマリキー列は分散キーと同じでなければなりません。ターゲットテーブルの一意キー (プライマリキー列を含む) には、分散キーのすべての列が含まれている必要があります。データを同期する前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。オフピーク時にデータを同期することをお勧めします。そうしないと、初期完全同期によってソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースが消費され、データベースの負荷が増加する可能性があります。初期完全同期では同時 INSERT 操作が実行されるため、ターゲットデータベーステーブルに断片化が発生します。その結果、初期完全同期の完了後、ターゲットインスタンスの表領域はソースインスタンスの表領域よりも大きくなります。テーブルレベルのデータ同期の場合、pt-online-schema-change などのツールを使用してソースデータベースの同期オブジェクトに対してオンライン DDL 操作を実行しないでください。そうしないと、同期が失敗します。テーブルレベルのデータ同期の場合、DTS からのデータ以外のデータがターゲットデータベースに書き込まれない場合は、Data Management (DMS) を使用してオンライン DDL 操作を実行できます。詳細については、「テーブルをロックせずにスキーマを変更する」をご参照ください。 DTS 同期中は、DTS からのデータ以外のデータをターゲットデータベースに書き込まないでください。そうしないと、ソースデータベースとターゲットデータベースの間でデータの不整合が発生する可能性があります。たとえば、他のデータがターゲットデータベースに書き込まれている間に DMS を使用してオンライン DDL 操作を実行すると、ターゲットデータベースでデータが失われる可能性があります。 AO テーブルはターゲットテーブルとしてサポートされていません。完全でないテーブル同期に列マッピングを使用する場合、またはソーステーブルスキーマとターゲットテーブルスキーマが一致しない場合、ターゲットテーブルにない列のデータは失われます。インスタンスに障害が発生した場合、DTS ヘルプデスクは 8 時間以内にインスタンスの回復を試みます。回復プロセス中に、インスタンスの再起動やパラメーターの調整などの操作が実行される場合があります。説明パラメーターを調整する場合、DTS インスタンスのパラメーターのみが変更されます。データベースのパラメーターは変更されません。変更される可能性のあるパラメーターには、インスタンスパラメーターの変更で説明されているパラメーターが含まれますが、これらに限定されません。
その他の注意事項	DTS は、ソースデータベースで CREATE DATABASE IF NOT EXISTS `test` コマンドを定期的に実行して、バイナリログのオフセットを進めます。

PolarDB for MySQL から Alibaba Cloud DataHub への同期

次の表に、注意事項と制限を示します。

タイプ	説明
ソースデータベースの制限	同期するテーブルには、プライマリキーまたは一意制約が必要であり、フィールドは一意である必要があります。そうでない場合、ターゲットデータベースに重複データが表示される可能性があります。テーブルレベルでデータを同期し、列名のマッピングなどのテーブルを編集する必要がある場合、1 つのデータ同期タスクでサポートされるテーブルは最大 1,000 です。この制限を超えると、タスクの送信時にエラーが報告されます。この場合、テーブルを複数の同期タスクに分割するか、データベース全体を同期するタスクを設定します。バイナリログ: バイナリログを有効にし、`loose_polar_log_bin` パラメーターを `ON` に設定する必要があります。そうしないと、事前チェック中にエラーが報告され、DTS インスタンスの起動に失敗します。バイナリログの有効化とパラメーターの変更の詳細については、「バイナリログを有効にする」および「クラスターとノードのパラメーターを設定する」をご参照ください。説明 PolarDB for MySQL クラスターのバイナリログを有効にすると、ストレージ領域が消費され、料金が発生します。 PolarDB for MySQL クラスターのバイナリログは、少なくとも 3 日間保持する必要があります。7 日間保持することをお勧めします。そうしないと、DTS がバイナリログを取得できないため、DTS タスクが失敗する可能性があります。極端な場合、これによりデータの不整合やデータ損失が発生する可能性があります。必要な期間よりも短いバイナリログ保持期間によって引き起こされた問題は、DTS サービスレベルアグリーメント (SLA) の対象外です。説明 PolarDB for MySQL クラスターのバイナリログの保持期間を設定する方法の詳細については、「保持期間の変更」をご参照ください。初期スキーマ同期および初期完全同期中は、データベースまたはテーブルのスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ同期タスクは失敗します。
その他の制限	宛先の DataHub Topic の単一の String フィールドの最大長は 2 MB です。データベースレベルおよびテーブルレベルのデータ同期がサポートされています。ソース PolarDB for MySQL クラスターの読み取り専用ノードからデータを同期することはできません。ソース PolarDB for MySQL クラスターから OSS 外部テーブルを同期することはできません。初期完全同期中のデータベースインスタンスのプライマリ/セカンダリフェールオーバーはサポートされていません。フェールオーバーが発生した場合は、同期タスクを速やかに再設定してください。テーブルレベルのデータ同期の場合、pt-online-schema-change などのツールを使用してソースデータベースの同期オブジェクトに対してオンライン DDL 操作を実行しないでください。そうしないと、同期が失敗します。テーブルレベルのデータ同期の場合、DTS からのデータ以外のデータがターゲットデータベースに書き込まれない場合は、Data Management (DMS) を使用してオンライン DDL 操作を実行できます。詳細については、「テーブルをロックせずにスキーマを変更する」をご参照ください。 DTS 同期中は、DTS からのデータ以外のデータをターゲットデータベースに書き込まないでください。そうしないと、ソースデータベースとターゲットデータベースの間でデータの不整合が発生する可能性があります。たとえば、他のデータがターゲットデータベースに書き込まれている間に DMS を使用してオンライン DDL 操作を実行すると、ターゲットデータベースでデータが失われる可能性があります。インスタンスに障害が発生した場合、DTS ヘルプデスクは 8 時間以内にインスタンスの回復を試みます。回復プロセス中に、インスタンスの再起動やパラメーターの調整などの操作が実行される場合があります。説明パラメーターを調整する場合、DTS インスタンスのパラメーターのみが変更されます。データベースのパラメーターは変更されません。変更される可能性のあるパラメーターには、インスタンスパラメーターの変更で説明されているパラメーターが含まれますが、これらに限定されません。
その他の注意事項	DTS は、ソースデータベースで CREATE DATABASE IF NOT EXISTS `test` コマンドを定期的に実行して、バイナリログのオフセットを進めます。

PolarDB for MySQL から Elasticsearch への同期

次の表に、注意事項と制限を示します。

制限タイプ	説明
ソースデータベースの制限	同期するテーブルには、プライマリキーまたは一意制約が必要であり、フィールドは一意である必要があります。そうでない場合、ターゲットデータベースに重複データが表示される可能性があります。説明双方向同期インスタンスで同期するテーブルにプライマリキーまたは一意制約がない場合は、Exactly-Once 書き込み機能を有効にできます。詳細については、「プライマリキーまたは一意制約のないテーブルを同期する」をご参照ください。テーブルレベルでデータを同期し、列名のマッピングなどのテーブルを編集する必要がある場合、1 つのデータ同期タスクでサポートされるテーブルは最大 1,000 です。この制限を超えると、タスクの送信時にエラーが報告されます。この場合、テーブルを複数の同期タスクに分割するか、データベース全体を同期するタスクを設定します。バイナリログ: バイナリログを有効にし、`loose_polar_log_bin` パラメーターを `ON` に設定する必要があります。そうしないと、事前チェック中にエラーが報告され、DTS インスタンスの起動に失敗します。バイナリログの有効化とパラメーターの変更の詳細については、「バイナリログを有効にする」および「クラスターとノードのパラメーターを設定する」をご参照ください。説明 PolarDB for MySQL クラスターのバイナリログを有効にすると、ストレージ領域が消費され、料金が発生します。 PolarDB for MySQL クラスターのバイナリログは、少なくとも 3 日間保持する必要があります。7 日間保持することをお勧めします。そうしないと、DTS がバイナリログを取得できないため、DTS タスクが失敗する可能性があります。極端な場合、これによりデータの不整合やデータ損失が発生する可能性があります。必要な期間よりも短いバイナリログ保持期間によって引き起こされた問題は、DTS サービスレベルアグリーメント (SLA) の対象外です。説明 PolarDB for MySQL クラスターのバイナリログの保持期間を設定する方法の詳細については、「保持期間の変更」をご参照ください。初期スキーマ同期および初期完全同期中は、データベースまたはテーブルのスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ同期タスクは失敗します。
その他の制限	ソース PolarDB for MySQL クラスターの読み取り専用ノードからデータを同期することはできません。ソースデータベースから同期するテーブルに列を追加するには、次の手順を実行します: 宛先の Elasticsearch クラスターでテーブルのマッピングを変更し、ソースの PolarDB for MySQL クラスターで DDL 文を実行してから、データ同期タスクを一時停止して開始します。 PolarDB for MySQL クラスターでサポートされているデータ型と Elasticsearch クラスターでサポートされているデータ型は 1 対 1 で対応していません。したがって、初期スキーマ同期中に、DTS はソースデータベースのデータ型をターゲットデータベースのデータ型に変換します。詳細については、「スキーマ同期のデータ型マッピング」をご参照ください。データを同期する前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。オフピーク時にデータを同期することをお勧めします。そうしないと、初期完全同期によってソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースが消費され、データベースの負荷が増加する可能性があります。初期完全同期では同時 INSERT 操作が実行されるため、ターゲットデータベーステーブルに断片化が発生します。その結果、初期完全同期の完了後、ターゲットインスタンスの表領域はソースインスタンスの表領域よりも大きくなります。テーブルレベルのデータ同期の場合、pt-online-schema-change などのツールを使用してソースデータベースの同期オブジェクトに対してオンライン DDL 操作を実行しないでください。そうしないと、同期が失敗します。テーブルレベルのデータ同期の場合、DTS からのデータ以外のデータがターゲットデータベースに書き込まれない場合は、Data Management (DMS) を使用してオンライン DDL 操作を実行できます。詳細については、「テーブルをロックせずにスキーマを変更する」をご参照ください。データ同期中は、DTS のみを使用してターゲットデータベースにデータを書き込むことをお勧めします。これにより、ソースデータベースとターゲットデータベース間のデータの不整合を防ぐことができます。
特殊なケース	DTS は、ソースデータベースで CREATE DATABASE IF NOT EXISTS `test` ステートメントをスケジュールどおりに実行して、バイナリログファイルの位置を前方に移動します。

PolarDB for MySQL から Alibaba Cloud Message Queue for Apache Kafka または自己管理 Kafka への同期

次の表に、注意事項と制限を示します。

タイプ	説明
ソースデータベースの制限	同期するテーブルには、プライマリキーまたは一意制約が必要であり、フィールドは一意である必要があります。そうでない場合、ターゲットデータベースに重複データが表示される可能性があります。テーブルレベルでデータを同期し、列名のマッピングなどのテーブルを編集する必要がある場合、1 つのデータ同期タスクでサポートされるテーブルは最大 1,000 です。この制限を超えると、タスクの送信時にエラーが報告されます。この場合、テーブルを複数の同期タスクに分割するか、データベース全体を同期するタスクを設定します。バイナリログ: バイナリログを有効にし、`loose_polar_log_bin` パラメーターを `ON` に設定する必要があります。そうしないと、事前チェック中にエラーが報告され、DTS インスタンスの起動に失敗します。バイナリログの有効化とパラメーターの変更の詳細については、「バイナリログを有効にする」および「クラスターとノードのパラメーターを設定する」をご参照ください。説明 PolarDB for MySQL クラスターのバイナリログを有効にすると、ストレージ領域が消費され、料金が発生します。 PolarDB for MySQL クラスターのバイナリログは、少なくとも 3 日間保持する必要があります。7 日間保持することをお勧めします。そうしないと、DTS がバイナリログを取得できないため、DTS タスクが失敗する可能性があります。極端な場合、これによりデータの不整合やデータ損失が発生する可能性があります。必要な期間よりも短いバイナリログ保持期間によって引き起こされた問題は、DTS サービスレベルアグリーメント (SLA) の対象外です。説明 PolarDB for MySQL クラスターのバイナリログの保持期間を設定する方法の詳細については、「保持期間の変更」をご参照ください。初期スキーマ同期および初期完全同期中は、データベースまたはテーブルのスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ同期タスクは失敗します。
その他の制限	ソース PolarDB for MySQL クラスターの読み取り専用ノードからデータを同期することはできません。ソース PolarDB for MySQL クラスターから OSS 外部テーブルを同期することはできません。 INDEX、PARTITION、VIEW、PROCEDURE、FUNCTION、TRIGGER、および FK の同期はサポートされていません。初期完全同期中のデータベースインスタンスのプライマリ/セカンダリフェールオーバーはサポートされていません。フェールオーバーが発生した場合は、同期タスクを速やかに再設定してください。データを同期する前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。オフピーク時にデータを同期することをお勧めします。そうしないと、初期完全同期によってソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースが消費され、データベースの負荷が増加する可能性があります。初期完全同期では同時 INSERT 操作が実行されるため、ターゲットデータベーステーブルに断片化が発生します。その結果、初期完全同期の完了後、ターゲットインスタンスの表領域はソースインスタンスの表領域よりも大きくなります。テーブルレベルのデータ同期の場合、pt-online-schema-change などのツールを使用してソースデータベースの同期オブジェクトに対してオンライン DDL 操作を実行しないでください。そうしないと、同期が失敗します。テーブルレベルのデータ同期の場合、DTS からのデータ以外のデータがターゲットデータベースに書き込まれない場合は、Data Management (DMS) を使用してオンライン DDL 操作を実行できます。詳細については、「テーブルをロックせずにスキーマを変更する」をご参照ください。 DTS 同期中は、DTS からのデータ以外のデータをターゲットデータベースに書き込まないでください。そうしないと、ソースデータベースとターゲットデータベースの間でデータの不整合が発生する可能性があります。たとえば、他のデータがターゲットデータベースに書き込まれている間に DMS を使用してオンライン DDL 操作を実行すると、ターゲットデータベースでデータが失われる可能性があります。同期中に、宛先の Kafka クラスターがスケールアウトまたはスケールインされた場合は、インスタンスを再起動する必要があります。インスタンスに障害が発生した場合、DTS ヘルプデスクは 8 時間以内にインスタンスの回復を試みます。回復プロセス中に、インスタンスの再起動やパラメーターの調整などの操作が実行される場合があります。説明パラメーターを調整する場合、DTS インスタンスのパラメーターのみが変更されます。データベースのパラメーターは変更されません。変更される可能性のあるパラメーターには、インスタンスパラメーターの変更で説明されているパラメーターが含まれますが、これらに限定されません。
その他の注意事項	DTS は、ソースデータベースで CREATE DATABASE IF NOT EXISTS `test` コマンドを定期的に実行して、バイナリログのオフセットを進めます。

PolarDB for MySQL から MaxCompute への同期

次の表に、注意事項と制限を示します。

タイプ	説明
ソースデータベースの制限	同期するテーブルには、プライマリキーまたは一意制約が必要であり、フィールドは一意である必要があります。そうでない場合、ターゲットデータベースに重複データが表示される可能性があります。テーブルレベルでデータを同期し、列名のマッピングなどのテーブルを編集する必要がある場合、1 つのデータ同期タスクでサポートされるテーブルは最大 1,000 です。この制限を超えると、タスクの送信時にエラーが報告されます。この場合、テーブルを複数の同期タスクに分割するか、データベース全体を同期するタスクを設定します。バイナリログ: バイナリログを有効にし、`loose_polar_log_bin` パラメーターを `ON` に設定する必要があります。そうしないと、事前チェック中にエラーが報告され、DTS インスタンスの起動に失敗します。バイナリログの有効化とパラメーターの変更の詳細については、「バイナリログを有効にする」および「クラスターとノードのパラメーターを設定する」をご参照ください。説明 PolarDB for MySQL クラスターのバイナリログを有効にすると、ストレージ領域が消費され、料金が発生します。 PolarDB for MySQL クラスターのバイナリログは、少なくとも 3 日間保持する必要があります。7 日間保持することをお勧めします。そうしないと、DTS がバイナリログを取得できないため、DTS タスクが失敗する可能性があります。極端な場合、これによりデータの不整合やデータ損失が発生する可能性があります。必要な期間よりも短いバイナリログ保持期間によって引き起こされた問題は、DTS サービスレベルアグリーメント (SLA) の対象外です。説明 PolarDB for MySQL クラスターのバイナリログの保持期間を設定する方法の詳細については、「保持期間の変更」をご参照ください。初期スキーマ同期および初期完全同期中は、データベースまたはテーブルのスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ同期タスクは失敗します。
その他の制限	ソース PolarDB for MySQL クラスターの読み取り専用ノードからデータを同期することはできません。ソース PolarDB for MySQL クラスターから OSS 外部テーブルを同期することはできません。 INDEX、PARTITION、VIEW、PROCEDURE、FUNCTION、TRIGGER、および FK の同期はサポートされていません。初期完全同期中のデータベースインスタンスのプライマリ/セカンダリフェールオーバーはサポートされていません。フェールオーバーが発生した場合は、同期タスクを速やかに再設定してください。データを同期する前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。オフピーク時にデータを同期することをお勧めします。そうしないと、初期完全同期によってソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースが消費され、データベースの負荷が増加する可能性があります。初期完全同期では同時 INSERT 操作が実行されるため、ターゲットデータベーステーブルに断片化が発生します。その結果、初期完全同期の完了後、ターゲットインスタンスの表領域はソースインスタンスの表領域よりも大きくなります。テーブルレベルのデータ同期の場合、pt-online-schema-change などのツールを使用してソースデータベースの同期オブジェクトに対してオンライン DDL 操作を実行しないでください。そうしないと、同期が失敗します。テーブルレベルのデータ同期の場合、DTS からのデータ以外のデータがターゲットデータベースに書き込まれない場合は、Data Management (DMS) を使用してオンライン DDL 操作を実行できます。詳細については、「テーブルをロックせずにスキーマを変更する」をご参照ください。 DTS 同期中は、DTS からのデータ以外のデータをターゲットデータベースに書き込まないでください。そうしないと、ソースデータベースとターゲットデータベースの間でデータの不整合が発生する可能性があります。たとえば、他のデータがターゲットデータベースに書き込まれている間に DMS を使用してオンライン DDL 操作を実行すると、ターゲットデータベースでデータが失われる可能性があります。 MaxCompute はプライマリキー制約をサポートしていないため、ネットワークの問題やその他の理由で DTS がデータを再送信すると、MaxCompute に重複レコードが表示されることがあります。インスタンスに障害が発生した場合、DTS ヘルプデスクは 8 時間以内にインスタンスの回復を試みます。回復プロセス中に、インスタンスの再起動やパラメーターの調整などの操作が実行される場合があります。説明パラメーターを調整する場合、DTS インスタンスのパラメーターのみが変更されます。データベースのパラメーターは変更されません。変更される可能性のあるパラメーターには、インスタンスパラメーターの変更で説明されているパラメーターが含まれますが、これらに限定されません。
その他の注意事項	DTS は、ソースデータベースで CREATE DATABASE IF NOT EXISTS `test` コマンドを定期的に実行して、バイナリログのオフセットを進めます。

PolarDB for MySQL から自己管理 Oracle への同期

次の表に、注意事項と制限を示します。

タイプ	説明
ソースデータベースの制限	同期するテーブルには、プライマリキーまたは一意制約が必要であり、フィールドは一意である必要があります。そうでない場合、ターゲットデータベースに重複データが表示される可能性があります。テーブルレベルでデータを同期し、列名のマッピングなどのテーブルを編集する必要がある場合、1 つのデータ同期タスクでサポートされるテーブルは最大 1,000 です。この制限を超えると、タスクの送信時にエラーが報告されます。この場合、テーブルを複数の同期タスクに分割するか、データベース全体を同期するタスクを設定します。バイナリログ: バイナリログを有効にし、`loose_polar_log_bin` パラメーターを `ON` に設定する必要があります。そうしないと、事前チェック中にエラーが報告され、DTS インスタンスの起動に失敗します。バイナリログの有効化とパラメーターの変更の詳細については、「バイナリログを有効にする」および「クラスターとノードのパラメーターを設定する」をご参照ください。説明 PolarDB for MySQL クラスターのバイナリログを有効にすると、ストレージ領域が消費され、料金が発生します。 PolarDB for MySQL クラスターのバイナリログは、少なくとも 3 日間保持する必要があります。7 日間保持することをお勧めします。そうしないと、DTS がバイナリログを取得できないため、DTS タスクが失敗する可能性があります。極端な場合、これによりデータの不整合やデータ損失が発生する可能性があります。必要な期間よりも短いバイナリログ保持期間によって引き起こされた問題は、DTS サービスレベルアグリーメント (SLA) の対象外です。説明 PolarDB for MySQL クラスターのバイナリログの保持期間を設定する方法の詳細については、「保持期間の変更」をご参照ください。初期スキーマ同期および初期完全同期中は、データベースまたはテーブルのスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ同期タスクは失敗します。
その他の制限	ソース PolarDB for MySQL クラスターの読み取り専用ノードからデータを同期することはできません。ソース PolarDB for MySQL クラスターから OSS 外部テーブルを同期することはできません。初期完全同期中のデータベースインスタンスのプライマリ/セカンダリフェールオーバーはサポートされていません。フェールオーバーが発生した場合は、同期タスクを速やかに再設定してください。複数のテーブルのマージなど、ソースデータベースで一時テーブルを使用するオンライン DDL 操作を実行すると、ターゲットデータベースでデータが失われたり、同期インスタンスが失敗したりする可能性があります。同期インスタンスの実行中にプライマリキーまたは一意キーの競合が発生した場合: ソースデータベースとターゲットデータベースのスキーマが同じで、ターゲットデータベースのデータレコードのプライマリキー値または一意キー値がソースデータベースのデータレコードと同じ場合: 完全なデータ同期中、DTS はデータレコードをターゲットデータベースに同期しません。ターゲットデータベース内の既存のデータレコードは保持されます。増分データ同期中、DTS はデータレコードをターゲットデータベースに同期します。ターゲットデータベース内の既存のデータレコードは上書きされます。ソースデータベースとターゲットデータベースのスキーマが異なる場合、データの初期化に失敗することがあります。この場合、一部の列のみが同期されるか、データ同期インスタンスが失敗します。注意して進めてください。 DTS インスタンスの実行中は、ターゲットデータベースで有効になっているトリガーと外部キーを無効にしてください。そうしないと、DTS インスタンスは失敗します。データを同期する前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。オフピーク時にデータを同期することをお勧めします。そうしないと、初期完全同期によってソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースが消費され、データベースの負荷が増加する可能性があります。初期完全同期では同時 INSERT 操作が実行されるため、ターゲットデータベーステーブルに断片化が発生します。その結果、初期完全同期の完了後、ターゲットインスタンスの表領域はソースインスタンスの表領域よりも大きくなります。テーブルレベルのデータ同期の場合、pt-online-schema-change などのツールを使用してソースデータベースの同期オブジェクトに対してオンライン DDL 操作を実行しないでください。そうしないと、同期が失敗します。テーブルレベルのデータ同期の場合、DTS からのデータ以外のデータがターゲットデータベースに書き込まれない場合は、Data Management (DMS) を使用してオンライン DDL 操作を実行できます。詳細については、「テーブルをロックせずにスキーマを変更する」をご参照ください。 DTS 同期中は、DTS からのデータ以外のデータをターゲットデータベースに書き込まないでください。そうしないと、ソースデータベースとターゲットデータベースの間でデータの不整合が発生する可能性があります。たとえば、他のデータがターゲットデータベースに書き込まれている間に DMS を使用してオンライン DDL 操作を実行すると、ターゲットデータベースでデータが失われる可能性があります。自己管理 Oracle データベースが Real Application Clusters (RAC) アーキテクチャを使用している場合、Single Client Access Name (SCAN) IP アドレスを設定することはできません。接続情報には、仮想 IP アドレス (VIP) の 1 つのみを設定できます。この設定後、RAC でのノード切り替えはサポートされません。インスタンスに障害が発生した場合、DTS ヘルプデスクは 8 時間以内にインスタンスの回復を試みます。回復プロセス中に、インスタンスの再起動やパラメーターの調整などの操作が実行される場合があります。説明パラメーターを調整する場合、DTS インスタンスのパラメーターのみが変更されます。データベースのパラメーターは変更されません。変更される可能性のあるパラメーターには、インスタンスパラメーターの変更で説明されているパラメーターが含まれますが、これらに限定されません。
その他の注意事項	DTS は、ソースデータベースで CREATE DATABASE IF NOT EXISTS `test` コマンドを定期的に実行して、バイナリログのオフセットを進めます。