Data Transmission Service:PolarDB for MySQL クラスタからのデータ同期の使用上の注意と制限

カテゴリ

説明

ソースデータベースの制限

• 同期対象のテーブルには、PRIMARY KEY 制約または UNIQUE 制約があり、すべてのフィールドが一意である必要があります。そうでない場合、宛先データベースに重複データレコードが含まれる可能性があります。

  説明

  同期対象のテーブルにプライマリキーと UNIQUE 制約がない場合は、双方向同期インスタンスを構成する際に Exactly-Once 書き込み機能を有効にする必要があります。詳細については、「プライマリキーまたは UNIQUE 制約のないテーブルを同期する」をご参照ください。

• 同期対象のオブジェクトとしてテーブルを選択し、宛先データベースでテーブルまたは列の名前変更などのテーブルの変更が必要な場合は、1 つのデータ同期タスクで最大 1,000 個のテーブルを同期できます。 1,000 個を超えるテーブルを同期するタスクを実行すると、リクエストエラーが発生します。この場合、複数のタスクを構成してテーブルを同期するか、データベース全体を同期するタスクを構成することをお勧めします。

• バイナリログについては、次の要件を満たす必要があります。

  • バイナリロギング機能が有効になっており、loose_polar_log_bin パラメータが ON に設定されている必要があります。そうでない場合、事前チェック中にエラーメッセージが返され、DTS タスクを開始できません。詳細については、「バイナリロギングを有効にする」および「パラメータを変更する」をご参照ください。

    説明

    PolarDB for MySQL クラスタのバイナリロギング機能を有効にすると、バイナリログによって使用されるストレージスペースの料金が発生します。

  • PolarDB for MySQL クラスタのバイナリログは、少なくとも 3 日間保持する必要があります。バイナリログの保存期間を 7 日間に設定することをお勧めします。例外的な状況では、データの不整合または損失が発生する可能性があります。上記の要件に基づいてバイナリログの保存期間を構成してください。そうでない場合、DTS のサービスレベル契約 (SLA) におけるサービスの信頼性またはパフォーマンスが保証されない場合があります。

    説明

    PolarDB for MySQL クラスタのバイナリログの保存期間を設定する方法の詳細については、「バイナリロギングを有効にする」トピックの「保存期間を変更する」セクションをご参照ください。

• スキーマ同期と完全データ同期中は、DDL 文を実行してデータベースまたはテーブルのスキーマを変更しないでください。変更すると、データ同期タスクが失敗します。

その他の制限

• DTS は、ソース PolarDB for MySQL クラスタの読み取り専用ノードを同期しません。

• DTS は、ソース PolarDB for MySQL クラスタから Object Storage Service (OSS) 外部テーブルを同期しません。

• DTS は、コメントを使用して定義されたパーサーが使用されているデータを同期しません。

• 同期するデータに、4 バイトを占める珍しい文字や絵文字などの情報が含まれている場合、データを受信する宛先データベースとテーブルは UTF8mb4 文字セットを使用する必要があります。

  説明

  DTS のスキーマ同期機能を使用する場合は、宛先データベースのインスタンスパラメータ character_set_server を UTF8mb4 文字セットに設定します。

• データを同期する前に、データ同期がソースデータベースと宛先データベースのパフォーマンスに与える影響を評価してください。オフピーク時にデータを同期することをお勧めします。初期完全データ同期中、DTS はソースデータベースと宛先データベースの読み取りリソースと書き込みリソースを使用します。これにより、データベースサーバーの負荷が増加する可能性があります。

• 初期完全データ同期中、同時 INSERT 操作により、宛先データベースのテーブルで断片化が発生します。初期完全データ同期が完了すると、宛先データベースの使用済み表領域のサイズはソースデータベースのサイズよりも大きくなります。

• データ同期中に、pt-online-schema-change などのツールを使用してソーステーブルで DDL 操作を実行しないことをお勧めします。実行すると、データ同期タスクが失敗します。

• データ同期中に他のソースからのデータが宛先データベースに書き込まれない場合は、Data Management (DMS) を使用してソーステーブルでオンライン DDL 操作を実行できます。詳細については、「ロックフリーの DDL 操作を実行する」をご参照ください。

• データ同期中に他のソースからのデータが宛先データベースに書き込まれると、ソースデータベースと宛先データベース間でデータの不整合が発生します。たとえば、他のソースからのデータが宛先データベースに書き込まれている間に DMS を使用してオンライン DDL 文を実行すると、宛先データベースでデータ損失が発生する可能性があります。

• 宛先データベースで DDL 文の実行に失敗した場合でも、データ同期タスクは引き続き実行されます。タスクログで実行に失敗した DDL 文を確認できます。タスクログを表示する方法の詳細については、「タスクログを表示する」をご参照ください。

• ソースデータベースから宛先データベースにアカウントを同期する場合は、前提条件と注意事項を理解する必要があります。詳細については、「データベースアカウントを移行する」をご参照ください。

• DTS タスクの実行に失敗した場合、DTS テクニカルサポートは 8 時間以内にタスクの復元を試みます。復元中、タスクが再起動され、タスクのパラメータが変更される場合があります。

  説明

  タスクのパラメータのみが変更される可能性があります。データベースのパラメータは変更されません。 変更される可能性のあるパラメータには、「DTS インスタンスのパラメータを変更する」トピックの「インスタンスパラメータを変更する」セクションのパラメータが含まれますが、これらに限定されません。

特別なケース

PolarDB for MySQL クラスタ間の双方向データ同期

• DTS は、2 つの PolarDB for MySQL クラスタ間でのみ双方向データ同期をサポートします。 DTS は、3 つ以上の PolarDB for MySQL クラスタ間の双方向データ同期をサポートしていません。

• DDL 同期方向の制限：データの整合性と双方向データ同期の安定性を確保するために、DDL 操作は順方向にのみ同期できます。

• DTS が双方向データ同期タスクを実行する場合、DTS は循環同期を防ぐために宛先データベースに dts という名前のデータベースを作成します。タスクの実行中は、dts データベースを変更しないでください。

• 双方向データ同期インスタンスには、順方向同期タスクと逆方向同期タスクが含まれています。インスタンスを構成またはリセットするときに、順方向同期タスクと逆方向同期タスクの両方でオブジェクトを同期する必要がある場合は、次のルールが適用されます。

  • タスクの 1 つだけが、オブジェクトの完全データと増分データの両方を同期できます。もう一方のタスクは、オブジェクトの増分データのみを同期します。

  • 現在のタスクのソースデータは、タスク内の宛先データベースにのみ同期できます。同期されたデータは、他のタスクのソースデータとして使用されません。

• DTS は、CREATE DATABASE IF NOT EXISTS `test` 文をソースデータベースでスケジュールどおりに実行して、バイナリログファイルの位置を進めます。

カテゴリ

説明

ソースデータベースの制限

• 同期対象のテーブルには、PRIMARY KEY 制約または UNIQUE 制約があり、すべてのフィールドが一意である必要があります。そうでない場合、宛先データベースに重複データレコードが含まれる可能性があります。

  説明

  同期対象のテーブルにプライマリキーと UNIQUE 制約がない場合は、双方向同期インスタンスを構成する際に Exactly-Once 書き込み機能を有効にする必要があります。詳細については、「プライマリキーまたは UNIQUE 制約のないテーブルを同期する」をご参照ください。

• 同期対象のオブジェクトとしてテーブルを選択し、宛先データベースでテーブルまたは列の名前変更などのテーブルの変更が必要な場合は、1 つのデータ同期タスクで最大 1,000 個のテーブルを同期できます。 1,000 個を超えるテーブルを同期するタスクを実行すると、リクエストエラーが発生します。この場合、複数のタスクを構成してテーブルを同期するか、データベース全体を同期するタスクを構成することをお勧めします。

• バイナリログについては、次の要件を満たす必要があります。

  • バイナリロギング機能が有効になっており、loose_polar_log_bin パラメータが ON に設定されている必要があります。そうでない場合、事前チェック中にエラーメッセージが返され、DTS タスクを開始できません。詳細については、「バイナリロギングを有効にする」および「パラメータを変更する」をご参照ください。

    説明

    PolarDB for MySQL クラスタのバイナリロギング機能を有効にすると、バイナリログによって使用されるストレージスペースの料金が発生します。

  • PolarDB for MySQL クラスタのバイナリログは、少なくとも 3 日間保持する必要があります。バイナリログの保存期間を 7 日間に設定することをお勧めします。例外的な状況では、データの不整合または損失が発生する可能性があります。上記の要件に基づいてバイナリログの保存期間を構成してください。そうでない場合、DTS のサービスレベル契約 (SLA) におけるサービスの信頼性またはパフォーマンスが保証されない場合があります。

    説明

    PolarDB for MySQL クラスタのバイナリログの保存期間を設定する方法の詳細については、「バイナリロギングを有効にする」トピックの「保存期間を変更する」セクションをご参照ください。

• スキーマ同期と完全データ同期中は、DDL 文を実行してデータベースまたはテーブルのスキーマを変更しないでください。変更すると、データ同期タスクが失敗します。

その他の制限

• DTS は、ソース PolarDB for MySQL クラスタの読み取り専用ノードを同期しません。

• DTS は、ソース PolarDB for MySQL クラスタから Object Storage Service (OSS) 外部テーブルを同期しません。

• DTS は、コメントを使用して定義されたパーサーが使用されているデータを同期しません。

• 同期するデータに、4 バイトを占める珍しい文字や絵文字などの情報が含まれている場合、データを受信する宛先データベースとテーブルは UTF8mb4 文字セットを使用する必要があります。

  説明

  DTS のスキーマ同期機能を使用する場合は、宛先データベースのインスタンスパラメータ character_set_server を UTF8mb4 文字セットに設定します。

• データを同期する前に、データ同期がソースデータベースと宛先データベースのパフォーマンスに与える影響を評価してください。オフピーク時にデータを同期することをお勧めします。初期完全データ同期中、DTS はソースデータベースと宛先データベースの読み取りリソースと書き込みリソースを使用します。これにより、データベースサーバーの負荷が増加する可能性があります。

• 初期完全データ同期中、同時 INSERT 操作により、宛先データベースのテーブルで断片化が発生します。初期完全データ同期が完了すると、宛先データベースの使用済み表領域のサイズはソースデータベースのサイズよりも大きくなります。

• データ同期中に、pt-online-schema-change などのツールを使用してソーステーブルで DDL 操作を実行しないことをお勧めします。実行すると、データ同期タスクが失敗します。

• データ同期中に他のソースからのデータが宛先データベースに書き込まれない場合は、Data Management (DMS) を使用してソーステーブルでオンライン DDL 操作を実行できます。詳細については、「ロックフリーの DDL 操作を実行する」をご参照ください。

• データ同期中は、DTS のみを使用して宛先データベースにデータを書き込むことをお勧めします。これにより、ソースと宛先の間のデータの不整合を防ぎます。たとえば、他のソースからのデータが宛先データベースに書き込まれている間に DMS を使用してオンライン DDL 文を実行すると、宛先データベースでデータ損失が発生する可能性があります。

• 宛先データベースで DDL 文の実行に失敗した場合でも、データ同期タスクは引き続き実行されます。タスクログで実行に失敗した DDL 文を確認できます。タスクログを表示する方法の詳細については、「タスクログを表示する」をご参照ください。

• MySQL データベースの列名は大文字と小文字が区別されません。したがって、ソースデータベースの複数の列の名前が大文字と小文字のみ異なる場合、同期中に列のデータは宛先 MySQL データベースの同じ列に書き込まれます。これにより、予期しない同期結果が発生する可能性があります。

• データ同期が完了した後、つまり、インスタンスの [ステータス] が [完了] に変更された後、analyze table <テーブル名> コマンドを実行して、データが宛先テーブルに書き込まれているかどうかを確認することをお勧めします。たとえば、ソース MySQL データベースで高可用性 (HA) スイッチオーバーがトリガーされた場合、データはメモリにのみ書き込まれる可能性があります。その結果、データ損失が発生します。

• 双方向データ同期インスタンスには、順方向同期タスクと逆方向同期タスクが含まれています。インスタンスを構成またはリセットするときに、順方向同期タスクと逆方向同期タスクの両方でオブジェクトを同期する必要がある場合は、次のルールが適用されます。

  • タスクの 1 つだけが、オブジェクトの完全データと増分データの両方を同期できます。もう一方のタスクは、オブジェクトの増分データのみを同期します。

  • 現在のタスクのソースデータは、タスク内の宛先データベースにのみ同期できます。同期されたデータは、他のタスクのソースデータとして使用されません。

• DTS タスクの実行に失敗した場合、DTS テクニカルサポートは 8 時間以内にタスクの復元を試みます。復元中、タスクが再起動され、タスクのパラメータが変更される場合があります。

  説明

  タスクのパラメータのみが変更される可能性があります。データベースのパラメータは変更されません。 変更される可能性のあるパラメータには、「DTS インスタンスのパラメータを変更する」トピックの「インスタンスパラメータを変更する」セクションのパラメータが含まれますが、これらに限定されません。

特別なケース

DTS は、CREATE DATABASE IF NOT EXISTS `test` 文をソースデータベースでスケジュールどおりに実行して、バイナリログファイルの位置を進めます。

カテゴリ

説明

ソースデータベースの制限

• 同期対象のテーブルには、PRIMARY KEY 制約または UNIQUE 制約があり、すべてのフィールドが一意である必要があります。そうでない場合、宛先データベースに重複データレコードが含まれる可能性があります。

• 同期対象のオブジェクトとしてテーブルを選択し、宛先データベースでテーブルまたは列の名前変更などのテーブルの変更が必要な場合は、1 つのデータ同期タスクで最大 1,000 個のテーブルを同期できます。 1,000 個を超えるテーブルを同期するタスクを実行すると、リクエストエラーが発生します。この場合、複数のタスクを構成してテーブルを同期するか、データベース全体を同期するタスクを構成することをお勧めします。

• バイナリログについては、次の要件を満たす必要があります。

  • バイナリロギング機能が有効になっており、loose_polar_log_bin パラメータが ON に設定されている必要があります。そうでない場合、事前チェック中にエラーメッセージが返され、DTS タスクを開始できません。詳細については、「バイナリロギングを有効にする」および「パラメータを変更する」をご参照ください。

    説明

    PolarDB for MySQL クラスタのバイナリロギング機能を有効にすると、バイナリログによって使用されるストレージスペースの料金が発生します。

  • PolarDB for MySQL クラスタのバイナリログは、少なくとも 3 日間保持する必要があります。バイナリログの保存期間を 7 日間に設定することをお勧めします。例外的な状況では、データの不整合または損失が発生する可能性があります。上記の要件に基づいてバイナリログの保存期間を構成してください。そうでない場合、DTS のサービスレベル契約 (SLA) におけるサービスの信頼性またはパフォーマンスが保証されない場合があります。

    説明

    PolarDB for MySQL クラスタのバイナリログの保存期間を設定する方法の詳細については、「バイナリロギングを有効にする」トピックの「保存期間を変更する」セクションをご参照ください。

• 完全データ同期中は、DDL 操作を実行してデータベースまたはテーブルのスキーマを変更しないでください。変更すると、データ同期タスクが失敗します。

その他の制限

• 同期対象のオブジェクトの要件：

  • DTS は、BIT、VARBIT、GEOMETRY、ARRAY、UUID、TSQUERY、TSVECTOR、TXID_SNAPSHOT のデータ型を同期しません。

  • プレフィックスインデックスは同期できません。ソースデータベースにプレフィックスインデックスが含まれている場合、データ同期タスクが失敗する可能性があります。

  • DTS は、ソース PolarDB for MySQL クラスタの読み取り専用ノードを同期しません。

  • DTS は、ソース PolarDB for MySQL クラスタから Object Storage Service (OSS) 外部テーブルを同期しません。

• スキーマ同期はサポートされていません。データ同期タスクを構成する前に、同期するデータベースとテーブルに基づいて、宛先インスタンスにデータベースとテーブルを作成する必要があります。

• データを同期する前に、データ同期がソースデータベースと宛先データベースのパフォーマンスに与える影響を評価してください。オフピーク時にデータを同期することをお勧めします。初期完全データ同期中、DTS はソースデータベースと宛先データベースの読み取りリソースと書き込みリソースを使用します。これにより、データベースサーバーの負荷が増加する可能性があります。

• 初期完全データ同期中、同時 INSERT 操作により、宛先データベースのテーブルで断片化が発生します。初期完全データ同期が完了すると、宛先データベースの使用済み表領域のサイズはソースデータベースのサイズよりも大きくなります。

• データ同期中に、pt-online-schema-change などのツールを使用してソーステーブルで DDL 操作を実行しないことをお勧めします。実行すると、データ同期タスクが失敗します。

• データ同期中に他のソースからのデータが宛先データベースに書き込まれない場合は、Data Management (DMS) を使用してソーステーブルでオンライン DDL 操作を実行できます。詳細については、「ロックフリーの DDL 操作を実行する」をご参照ください。

• データ同期中に他のソースからのデータが宛先データベースに書き込まれると、ソースデータベースと宛先データベース間でデータの不整合が発生します。たとえば、他のソースからのデータが宛先データベースに書き込まれている間に DMS を使用してオンライン DDL 文を実行すると、宛先データベースでデータ損失が発生する可能性があります。

• DTS タスクの実行に失敗した場合、DTS テクニカルサポートは 8 時間以内にタスクの復元を試みます。復元中、タスクが再起動され、タスクのパラメータが変更される場合があります。

  説明

  タスクのパラメータのみが変更される可能性があります。データベースのパラメータは変更されません。 変更される可能性のあるパラメータには、「DTS インスタンスのパラメータを変更する」トピックの「インスタンスパラメータを変更する」セクションのパラメータが含まれますが、これらに限定されません。

特別なケース

DTS は、CREATE DATABASE IF NOT EXISTS `test` 文をソースデータベースでスケジュールどおりに実行して、バイナリログファイルの位置を進めます。

カテゴリ

説明

ソースデータベースの制限

• 同期対象のテーブルには、PRIMARY KEY 制約または UNIQUE 制約があり、すべてのフィールドが一意である必要があります。そうでない場合、宛先データベースに重複データレコードが含まれる可能性があります。

• 同期対象のオブジェクトとしてテーブルを選択し、宛先データベースでテーブルまたは列の名前変更などのテーブルの変更が必要な場合は、1 つのデータ同期タスクで最大 1,000 個のテーブルを同期できます。 1,000 個を超えるテーブルを同期するタスクを実行すると、リクエストエラーが発生します。この場合、複数のタスクを構成してテーブルを同期するか、データベース全体を同期するタスクを構成することをお勧めします。

• バイナリログについては、次の要件を満たす必要があります。

  • バイナリロギング機能が有効になっており、loose_polar_log_bin パラメータが ON に設定されている必要があります。そうでない場合、事前チェック中にエラーメッセージが返され、DTS タスクを開始できません。詳細については、「バイナリロギングを有効にする」および「パラメータを変更する」をご参照ください。

    説明

    PolarDB for MySQL クラスタのバイナリロギング機能を有効にすると、バイナリログによって使用されるストレージスペースの料金が発生します。

  • PolarDB for MySQL クラスタのバイナリログは、少なくとも 3 日間保持する必要があります。バイナリログの保存期間を 7 日間に設定することをお勧めします。例外的な状況では、データの不整合または損失が発生する可能性があります。上記の要件に基づいてバイナリログの保存期間を構成してください。そうでない場合、DTS のサービスレベル契約 (SLA) におけるサービスの信頼性またはパフォーマンスが保証されない場合があります。

    説明

    PolarDB for MySQL クラスタのバイナリログの保存期間を設定する方法の詳細については、「バイナリロギングを有効にする」トピックの「保存期間を変更する」セクションをご参照ください。

• データ同期中に、プライマリキーを変更したり、コメントを追加したりする DDL 文を実行しないでください。これらの文は有効になりません。たとえば、ALTER TABLE table_name COMMENT='テーブルのコメント'; 文は実行しないでください。

• スキーマ同期と完全データ同期中は、DDL 文を実行してデータベースまたはテーブルのスキーマを変更しないでください。変更すると、データ同期タスクが失敗します。

その他の制限

• プレフィックスインデックスは同期できません。ソースデータベースにプレフィックスインデックスが含まれている場合、データ同期タスクが失敗する可能性があります。

• 宛先データベースでカスタムプライマリキーを指定するか、[データベース、テーブル、および列の構成] で [プライマリキー列] を構成する必要があります。そうでない場合、データ同期が失敗する可能性があります。

• DTS は、ソース PolarDB for MySQL クラスタの読み取り専用ノードを同期しません。

• DTS は、ソース PolarDB for MySQL クラスタから Object Storage Service (OSS) 外部テーブルを同期しません。

• AnalyticDB for MySQL の制限により、AnalyticDB for MySQL クラスタ内のノードのディスク容量使用率が 80% を超えると、例外が発生し、DTS タスクが遅延します。同期するオブジェクトに基づいて必要なディスク容量を見積もることをお勧めします。宛先クラスタに十分なストレージ容量があることを確認してください。

• DTS タスクの実行中に宛先 AnalyticDB for MySQL V3.0 クラスタがバックアップされている場合、DTS タスクは失敗します。

• データを同期する前に、データ同期がソースデータベースと宛先データベースのパフォーマンスに与える影響を評価してください。オフピーク時にデータを同期することをお勧めします。初期完全データ同期中、DTS はソースデータベースと宛先データベースの読み取りリソースと書き込みリソースを使用します。これにより、データベースサーバーの負荷が増加する可能性があります。

• 初期完全データ同期中、同時 INSERT 操作により、宛先データベースのテーブルで断片化が発生します。初期完全データ同期が完了すると、宛先データベースの使用済み表領域のサイズはソースデータベースのサイズよりも大きくなります。

• データ同期中に、pt-online-schema-change などのツールを使用してソーステーブルで DDL 操作を実行しないことをお勧めします。実行すると、データ同期タスクが失敗します。

• データ同期中に他のソースからのデータが宛先データベースに書き込まれない場合は、Data Management (DMS) を使用してソーステーブルでオンライン DDL 操作を実行できます。詳細については、「ロックフリーの DDL 操作を実行する」をご参照ください。

• データ同期中に他のソースからのデータが宛先データベースに書き込まれると、ソースデータベースと宛先データベース間でデータの不整合が発生します。たとえば、他のソースからのデータが宛先データベースに書き込まれている間に DMS を使用してオンライン DDL 文を実行すると、宛先データベースでデータ損失が発生する可能性があります。

• 宛先データベースで DDL 文の実行に失敗した場合でも、データ同期タスクは引き続き実行されます。タスクログで実行に失敗した DDL 文を確認できます。タスクログを表示する方法の詳細については、「タスクログを表示する」をご参照ください。

• DTS タスクの実行に失敗した場合、DTS テクニカルサポートは 8 時間以内にタスクの復元を試みます。復元中、タスクが再起動され、タスクのパラメータが変更される場合があります。

  説明

  タスクのパラメータのみが変更される可能性があります。データベースのパラメータは変更されません。 変更される可能性のあるパラメータには、「DTS インスタンスのパラメータを変更する」トピックの「インスタンスパラメータを変更する」セクションのパラメータが含まれますが、これらに限定されません。

特別なケース

DTS は、CREATE DATABASE IF NOT EXISTS `test` 文をソースデータベースでスケジュールどおりに実行して、バイナリログファイルの位置を進めます。

カテゴリ

説明

ソースデータベースの制限

• 同期対象のテーブルには、PRIMARY KEY 制約または UNIQUE 制約があり、すべてのフィールドが一意である必要があります。そうでない場合、宛先データベースに重複データレコードが含まれる可能性があります。

• 同期対象のオブジェクトとしてテーブルを選択し、宛先データベースでテーブルまたは列の名前変更などのテーブルの変更が必要な場合は、1 つのデータ同期タスクで最大 1,000 個のテーブルを同期できます。 1,000 個を超えるテーブルを同期するタスクを実行すると、リクエストエラーが発生します。この場合、複数のタスクを構成してテーブルを同期するか、データベース全体を同期するタスクを構成することをお勧めします。

• バイナリログについては、次の要件を満たす必要があります。

  • バイナリロギング機能が有効になっており、loose_polar_log_bin パラメータが ON に設定されている必要があります。そうでない場合、事前チェック中にエラーメッセージが返され、DTS タスクを開始できません。詳細については、「バイナリロギングを有効にする」および「パラメータを変更する」をご参照ください。

    説明

    PolarDB for MySQL クラスタのバイナリロギング機能を有効にすると、バイナリログによって使用されるストレージスペースの料金が発生します。

  • PolarDB for MySQL クラスタのバイナリログは、少なくとも 3 日間保持する必要があります。バイナリログの保存期間を 7 日間に設定することをお勧めします。例外的な状況では、データの不整合または損失が発生する可能性があります。上記の要件に基づいてバイナリログの保存期間を構成してください。そうでない場合、DTS のサービスレベル契約 (SLA) におけるサービスの信頼性またはパフォーマンスが保証されない場合があります。

    説明

    PolarDB for MySQL クラスタのバイナリログの保存期間を設定する方法の詳細については、「バイナリロギングを有効にする」トピックの「保存期間を変更する」セクションをご参照ください。

• データ同期中に、プライマリキーを変更したり、コメントを追加したりする DDL 文を実行しないでください。これらの文は有効になりません。たとえば、ALTER TABLE table_name COMMENT='テーブルのコメント'; 文は実行しないでください。

• 同期するデータに DATETIME 値 0000-00-00 00:00:00 が含まれている場合、データ同期タスクが失敗する可能性があります。

  説明

  DTS は、宛先データベースにデータを同期するときに、この値を null に変換します。この問題を回避するには、ソースデータベースの DATETIME 値を一時的に 0001-01-01 00:00:00 に変更するか、宛先データベースの対応するフィールドを空のままにします。

• スキーマ同期と完全データ同期中は、DDL 文を実行してデータベースまたはテーブルのスキーマを変更しないでください。変更すると、データ同期タスクが失敗します。

その他の制限

• 同期対象のオブジェクトの要件：

  • 同期対象のオブジェクトとして選択できるのはテーブルのみです。

  • DTS は、BIT、VARBIT、GEOMETRY、ARRAY、UUID、TSQUERY、TSVECTOR、TXID_SNAPSHOT のデータ型を同期しません。

  • プレフィックスインデックスは同期できません。ソースデータベースにプレフィックスインデックスが含まれている場合、データ同期タスクが失敗する可能性があります。

  • DTS は、ソース PolarDB for MySQL クラスタの読み取り専用ノードを同期しません。

  • DTS は、ソース PolarDB for MySQL クラスタから Object Storage Service (OSS) 外部テーブルを同期しません。

• 同期するソーステーブルにプライマリキーがある場合、宛先テーブルのプライマリキー列はソーステーブルのプライマリキー列と同じです。同期するソーステーブルにプライマリキーがない場合、宛先テーブルのプライマリキー列は宛先テーブルの分散キーと同じです。

• 宛先テーブルの一意キー (プライマリキー列を含む) には、分散キーのすべての列が含まれている必要があります。

• データを同期する前に、データ同期がソースデータベースと宛先データベースのパフォーマンスに与える影響を評価してください。オフピーク時にデータを同期することをお勧めします。初期完全データ同期中、DTS はソースデータベースと宛先データベースの読み取りリソースと書き込みリソースを使用します。これにより、データベースサーバーの負荷が増加する可能性があります。

• 初期完全データ同期中、同時 INSERT 操作により、宛先データベースのテーブルで断片化が発生します。初期完全データ同期が完了すると、宛先データベースの使用済み表領域のサイズはソースデータベースのサイズよりも大きくなります。

• データ同期中に、pt-online-schema-change などのツールを使用してソーステーブルで DDL 操作を実行しないことをお勧めします。実行すると、データ同期タスクが失敗します。

• データ同期中に他のソースからのデータが宛先データベースに書き込まれない場合は、Data Management (DMS) を使用してソーステーブルでオンライン DDL 操作を実行できます。詳細については、「ロックフリーの DDL 操作を実行する」をご参照ください。

• データ同期中に他のソースからのデータが宛先データベースに書き込まれると、ソースデータベースと宛先データベース間でデータの不整合が発生します。たとえば、他のソースからのデータが宛先データベースに書き込まれている間に DMS を使用してオンライン DDL 文を実行すると、宛先データベースでデータ損失が発生する可能性があります。

• データの同期先となるテーブルは、追加最適化 (AO) テーブルにすることはできません。

• フルテーブル同期以外で列マッピングが使用されている場合、またはソーステーブルと宛先テーブルのスキーマに不整合がある場合、宛先データベースに含まれていないソースデータベースの列のデータは失われます。

• DTS タスクの実行に失敗した場合、DTS テクニカルサポートは 8 時間以内にタスクの復元を試みます。復元中、タスクが再起動され、タスクのパラメータが変更される場合があります。

  説明

  タスクのパラメータのみが変更される可能性があります。データベースのパラメータは変更されません。 変更される可能性のあるパラメータには、「DTS インスタンスのパラメータを変更する」トピックの「インスタンスパラメータを変更する」セクションのパラメータが含まれますが、これらに限定されません。

特別なケース

DTS は、CREATE DATABASE IF NOT EXISTS `test` 文をソースデータベースでスケジュールどおりに実行して、バイナリログファイルの位置を進めます。

カテゴリ

説明

ソースデータベースの制限

• 同期対象のテーブルには、PRIMARY KEY 制約または UNIQUE 制約があり、すべてのフィールドが一意である必要があります。そうでない場合、宛先データベースに重複データレコードが含まれる可能性があります。

• 同期対象のオブジェクトとしてテーブルを選択し、宛先データベースでテーブルまたは列の名前変更などのテーブルの変更が必要な場合は、1 つのデータ同期タスクで最大 1,000 個のテーブルを同期できます。 1,000 個を超えるテーブルを同期するタスクを実行すると、リクエストエラーが発生します。この場合、複数のタスクを構成してテーブルを同期するか、データベース全体を同期するタスクを構成することをお勧めします。

• バイナリログについては、次の要件を満たす必要があります。

  • バイナリロギング機能が有効になっており、loose_polar_log_bin パラメータが ON に設定されている必要があります。そうでない場合、事前チェック中にエラーメッセージが返され、DTS タスクを開始できません。詳細については、「バイナリロギングを有効にする」および「パラメータを変更する」をご参照ください。

    説明

    PolarDB for MySQL クラスタのバイナリロギング機能を有効にすると、バイナリログによって使用されるストレージスペースの料金が発生します。

  • PolarDB for MySQL クラスタのバイナリログは、少なくとも 3 日間保持する必要があります。バイナリログの保存期間を 7 日間に設定することをお勧めします。例外的な状況では、データの不整合または損失が発生する可能性があります。上記の要件に基づいてバイナリログの保存期間を構成してください。そうでない場合、DTS のサービスレベル契約 (SLA) におけるサービスの信頼性またはパフォーマンスが保証されない場合があります。

    説明

    PolarDB for MySQL クラスタのバイナリログの保存期間を設定する方法の詳細については、「バイナリロギングを有効にする」トピックの「保存期間を変更する」セクションをご参照ください。

• スキーマ同期と完全データ同期中は、DDL 文を実行してデータベースまたはテーブルのスキーマを変更しないでください。変更すると、データ同期タスクが失敗します。

その他の制限

• 宛先 DataHub プロジェクトの 1 つの文字列の長さは 2 MB を超えることはできません。

• 同期対象のオブジェクトとして選択できるのは、テーブルとデータベースのみです。

• DTS は、ソース PolarDB for MySQL クラスタの読み取り専用ノードを同期しません。

• DTS は、ソース PolarDB for MySQL クラスタから Object Storage Service (OSS) 外部テーブルを同期しません。

• データ同期中に、pt-online-schema-change などのツールを使用してソーステーブルで DDL 操作を実行しないことをお勧めします。実行すると、データ同期タスクが失敗します。

• データ同期中に他のソースからのデータが宛先データベースに書き込まれない場合は、Data Management (DMS) を使用してソーステーブルでオンライン DDL 操作を実行できます。詳細については、「ロックフリーの DDL 操作を実行する」をご参照ください。

• データ同期中に他のソースからのデータが宛先データベースに書き込まれると、ソースデータベースと宛先データベース間でデータの不整合が発生します。たとえば、他のソースからのデータが宛先データベースに書き込まれている間に DMS を使用してオンライン DDL 文を実行すると、宛先データベースでデータ損失が発生する可能性があります。

• DTS タスクの実行に失敗した場合、DTS テクニカルサポートは 8 時間以内にタスクの復元を試みます。復元中、タスクが再起動され、タスクのパラメータが変更される場合があります。

  説明

  タスクのパラメータのみが変更される可能性があります。データベースのパラメータは変更されません。 変更される可能性のあるパラメータには、「DTS インスタンスのパラメータを変更する」トピックの「インスタンスパラメータを変更する」セクションのパラメータが含まれますが、これらに限定されません。

特別なケース

DTS は、CREATE DATABASE IF NOT EXISTS `test` 文をソースデータベースでスケジュールどおりに実行して、バイナリログファイルの位置を進めます。

制限タイプ

説明

ソースデータベースの制限

• 同期対象のテーブルには、PRIMARY KEY 制約または UNIQUE 制約があり、すべてのフィールドが一意である必要があります。そうでない場合、宛先データベースに重複データレコードが含まれる可能性があります。

  説明

  同期対象のテーブルにプライマリキーと UNIQUE 制約がない場合は、双方向同期インスタンスを構成する際に Exactly-Once 書き込み機能を有効にする必要があります。詳細については、「プライマリキーまたは UNIQUE 制約のないテーブルを同期する」をご参照ください。

• 同期対象のオブジェクトとしてテーブルを選択し、宛先データベースでテーブルまたは列の名前変更などのテーブルの変更が必要な場合は、1 つのデータ同期タスクで最大 1,000 個のテーブルを同期できます。 1,000 個を超えるテーブルを同期するタスクを実行すると、リクエストエラーが発生します。この場合、複数のタスクを構成してテーブルを同期するか、データベース全体を同期するタスクを構成することをお勧めします。

• バイナリログについては、次の要件を満たす必要があります。

  • バイナリロギング機能が有効になっており、loose_polar_log_bin パラメータが ON に設定されている必要があります。そうでない場合、事前チェック中にエラーメッセージが返され、DTS タスクを開始できません。詳細については、「バイナリロギングを有効にする」および「パラメータを変更する」をご参照ください。

    説明

    PolarDB for MySQL クラスタのバイナリロギング機能を有効にすると、バイナリログによって使用されるストレージスペースの料金が発生します。

  • PolarDB for MySQL クラスタのバイナリログは、少なくとも 3 日間保持する必要があります。バイナリログの保存期間を 7 日間に設定することをお勧めします。例外的な状況では、データの不整合または損失が発生する可能性があります。上記の要件に基づいてバイナリログの保存期間を構成してください。そうでない場合、DTS のサービスレベル契約 (SLA) におけるサービスの信頼性またはパフォーマンスが保証されない場合があります。

    説明

    PolarDB for MySQL クラスタのバイナリログの保存期間を設定する方法の詳細については、「バイナリロギングを有効にする」トピックの「保存期間を変更する」セクションをご参照ください。

• スキーマ同期と完全データ同期中は、DDL 文を実行してデータベースまたはテーブルのスキーマを変更しないでください。変更すると、データ同期タスクが失敗します。

その他の制限

• DTS は、ソース PolarDB for MySQL クラスタの読み取り専用ノードを同期しません。

• ソースデータベースから同期するテーブルに列を追加するには、次の手順を実行します。宛先 Elasticsearch クラスタでテーブルのマッピングを変更し、ソース PolarDB for MySQL クラスタで DDL 文を実行してから、データ同期タスクを一時停止して開始します。

• PolarDB for MySQL クラスタでサポートされているデータ型と Elasticsearch クラスタでサポートされているデータ型は 1 対 1 で対応していません。したがって、初期スキーマ同期中に、DTS はソースデータベースのデータ型を宛先データベースのデータ型に変換します。詳細については、「スキーマ同期のデータ型マッピング」をご参照ください。

• データを同期する前に、データ同期がソースデータベースと宛先データベースのパフォーマンスに与える影響を評価してください。オフピーク時にデータを同期することをお勧めします。初期完全データ同期中、DTS はソースデータベースと宛先データベースの読み取りリソースと書き込みリソースを使用します。これにより、データベースサーバーの負荷が増加する可能性があります。

• 初期完全データ同期中、同時 INSERT 操作により、宛先データベースのテーブルで断片化が発生します。初期完全データ同期が完了すると、宛先データベースの使用済み表領域のサイズはソースデータベースのサイズよりも大きくなります。

• データ同期中に、pt-online-schema-change などのツールを使用してソーステーブルで DDL 操作を実行しないことをお勧めします。実行すると、データ同期タスクが失敗します。

• データ同期中に他のソースからのデータが宛先データベースに書き込まれない場合は、Data Management (DMS) を使用してソーステーブルでオンライン DDL 操作を実行できます。詳細については、「ロックフリーの DDL 操作を実行する」をご参照ください。

• データ同期中は、DTS のみを使用して宛先データベースにデータを書き込むことをお勧めします。これにより、ソースデータベースと宛先データベース間でデータの不整合が発生するのを防ぎます。

特別なケース

DTS は、CREATE DATABASE IF NOT EXISTS `test` 文をソースデータベースでスケジュールどおりに実行して、バイナリログファイルの位置を進めます。

カテゴリ

説明

ソースデータベースの制限

• 同期対象のテーブルには、PRIMARY KEY 制約または UNIQUE 制約があり、すべてのフィールドが一意である必要があります。そうでない場合、宛先データベースに重複データレコードが含まれる可能性があります。

• 同期対象のオブジェクトとしてテーブルを選択し、宛先データベースでテーブルまたは列の名前変更などのテーブルの変更が必要な場合は、1 つのデータ同期タスクで最大 1,000 個のテーブルを同期できます。 1,000 個を超えるテーブルを同期するタスクを実行すると、リクエストエラーが発生します。この場合、複数のタスクを構成してテーブルを同期するか、データベース全体を同期するタスクを構成することをお勧めします。

• バイナリログについては、次の要件を満たす必要があります。

  • バイナリロギング機能が有効になっており、loose_polar_log_bin パラメータが ON に設定されている必要があります。そうでない場合、事前チェック中にエラーメッセージが返され、DTS タスクを開始できません。詳細については、「バイナリロギングを有効にする」および「パラメータを変更する」をご参照ください。

    説明

    PolarDB for MySQL クラスタのバイナリロギング機能を有効にすると、バイナリログによって使用されるストレージスペースの料金が発生します。

  • PolarDB for MySQL クラスタのバイナリログは、少なくとも 3 日間保持する必要があります。バイナリログの保存期間を 7 日間に設定することをお勧めします。例外的な状況では、データの不整合または損失が発生する可能性があります。上記の要件に基づいてバイナリログの保存期間を構成してください。そうでない場合、DTS のサービスレベル契約 (SLA) におけるサービスの信頼性またはパフォーマンスが保証されない場合があります。

    説明

    PolarDB for MySQL クラスタのバイナリログの保存期間を設定する方法の詳細については、「バイナリロギングを有効にする」トピックの「保存期間を変更する」セクションをご参照ください。

• スキーマ同期と完全データ同期中は、DDL 文を実行してデータベースまたはテーブルのスキーマを変更しないでください。変更すると、データ同期タスクが失敗します。

その他の制限

• DTS は、ソース PolarDB for MySQL クラスタの読み取り専用ノードを同期しません。

• DTS は、ソース PolarDB for MySQL クラスタから Object Storage Service (OSS) 外部テーブルを同期しません。

• データを同期する前に、データ同期がソースデータベースと宛先データベースのパフォーマンスに与える影響を評価してください。オフピーク時にデータを同期することをお勧めします。初期完全データ同期中、DTS はソースデータベースと宛先データベースの読み取りリソースと書き込みリソースを使用します。これにより、データベースサーバーの負荷が増加する可能性があります。

• 初期完全データ同期中、同時 INSERT 操作により、宛先データベースのテーブルで断片化が発生します。初期完全データ同期が完了すると、宛先データベースの使用済み表領域のサイズはソースデータベースのサイズよりも大きくなります。

• データ同期中に、pt-online-schema-change などのツールを使用してソーステーブルで DDL 操作を実行しないことをお勧めします。実行すると、データ同期タスクが失敗します。

• データ同期中に他のソースからのデータが宛先データベースに書き込まれない場合は、Data Management (DMS) を使用してソーステーブルでオンライン DDL 操作を実行できます。詳細については、「ロックフリーの DDL 操作を実行する」をご参照ください。

• データ同期中に他のソースからのデータが宛先データベースに書き込まれると、ソースデータベースと宛先データベース間でデータの不整合が発生します。たとえば、他のソースからのデータが宛先データベースに書き込まれている間に DMS を使用してオンライン DDL 文を実行すると、宛先データベースでデータ損失が発生する可能性があります。

• データ同期中に宛先 Kafka データベースがスケーリングされた場合は、データベースを再起動する必要があります。

• DTS タスクの実行に失敗した場合、DTS テクニカルサポートは 8 時間以内にタスクの復元を試みます。復元中、タスクが再起動され、タスクのパラメータが変更される場合があります。

  説明

  タスクのパラメータのみが変更される可能性があります。データベースのパラメータは変更されません。 変更される可能性のあるパラメータには、「DTS インスタンスのパラメータを変更する」トピックの「インスタンスパラメータを変更する」セクションのパラメータが含まれますが、これらに限定されません。

特別なケース

DTS は、CREATE DATABASEIF NOT EXISTS `test` 文をソースデータベースでスケジュールどおりに実行して、バイナリログファイルの位置を進めます。

カテゴリ

説明

ソースデータベースの制限

• 同期対象のテーブルには、PRIMARY KEY 制約または UNIQUE 制約があり、すべてのフィールドが一意である必要があります。そうでない場合、宛先データベースに重複データレコードが含まれる可能性があります。

• 同期対象のオブジェクトとしてテーブルを選択し、宛先データベースでテーブルまたは列の名前変更などのテーブルの変更が必要な場合は、1 つのデータ同期タスクで最大 1,000 個のテーブルを同期できます。 1,000 個を超えるテーブルを同期するタスクを実行すると、リクエストエラーが発生します。この場合、複数のタスクを構成してテーブルを同期するか、データベース全体を同期するタスクを構成することをお勧めします。

• バイナリログについては、次の要件を満たす必要があります。

  • バイナリロギング機能が有効になっており、loose_polar_log_bin パラメータが ON に設定されている必要があります。そうでない場合、事前チェック中にエラーメッセージが返され、DTS タスクを開始できません。詳細については、「バイナリロギングを有効にする」および「パラメータを変更する」をご参照ください。

    説明

    PolarDB for MySQL クラスタのバイナリロギング機能を有効にすると、バイナリログによって使用されるストレージスペースの料金が発生します。

  • PolarDB for MySQL クラスタのバイナリログは、少なくとも 3 日間保持する必要があります。バイナリログの保存期間を 7 日間に設定することをお勧めします。例外的な状況では、データの不整合または損失が発生する可能性があります。上記の要件に基づいてバイナリログの保存期間を構成してください。そうでない場合、DTS のサービスレベル契約 (SLA) におけるサービスの信頼性またはパフォーマンスが保証されない場合があります。

    説明

    PolarDB for MySQL クラスタのバイナリログの保存期間を設定する方法の詳細については、「バイナリロギングを有効にする」トピックの「保存期間を変更する」セクションをご参照ください。

• スキーマ同期と完全データ同期中は、DDL 文を実行してデータベースまたはテーブルのスキーマを変更しないでください。変更すると、データ同期タスクが失敗します。

その他の制限

• DTS は、ソース PolarDB for MySQL クラスタの読み取り専用ノードを同期しません。

• DTS は、ソース PolarDB for MySQL クラスタから Object Storage Service (OSS) 外部テーブルを同期しません。

• データを同期する前に、データ同期がソースデータベースと宛先データベースのパフォーマンスに与える影響を評価してください。オフピーク時にデータを同期することをお勧めします。初期完全データ同期中、DTS はソースデータベースと宛先データベースの読み取りリソースと書き込みリソースを使用します。これにより、データベースサーバーの負荷が増加する可能性があります。

• 初期完全データ同期中、同時 INSERT 操作により、宛先データベースのテーブルで断片化が発生します。初期完全データ同期が完了すると、宛先データベースの使用済み表領域のサイズはソースデータベースのサイズよりも大きくなります。

• データ同期中に、pt-online-schema-change などのツールを使用してソーステーブルで DDL 操作を実行しないことをお勧めします。実行すると、データ同期タスクが失敗します。

• データ同期中に他のソースからのデータが宛先データベースに書き込まれない場合は、Data Management (DMS) を使用してソーステーブルでオンライン DDL 操作を実行できます。詳細については、「ロックフリーの DDL 操作を実行する」をご参照ください。

• データ同期中に他のソースからのデータが宛先データベースに書き込まれると、ソースデータベースと宛先データベース間でデータの不整合が発生します。たとえば、他のソースからのデータが宛先データベースに書き込まれている間に DMS を使用してオンライン DDL 文を実行すると、宛先データベースでデータ損失が発生する可能性があります。

• MaxCompute は PRIMARY KEY 制約をサポートしていません。ネットワークエラーが発生した場合、DTS は重複したデータレコードを MaxCompute プロジェクトに同期する可能性があります。

• DTS タスクの実行に失敗した場合、DTS テクニカルサポートは 8 時間以内にタスクの復元を試みます。復元中、タスクが再起動され、タスクのパラメータが変更される場合があります。

  説明

  タスクのパラメータのみが変更される可能性があります。データベースのパラメータは変更されません。 変更される可能性のあるパラメータには、「DTS インスタンスのパラメータを変更する」トピックの「インスタンスパラメータを変更する」セクションのパラメータが含まれますが、これらに限定されません。

特別なケース

DTS は、CREATE DATABASE IF NOT EXISTS `test` 文をソースデータベースでスケジュールどおりに実行して、バイナリログファイルの位置を進めます。

カテゴリ

説明

ソースデータベースの制限

• 同期対象のテーブルには、PRIMARY KEY 制約または UNIQUE 制約があり、すべてのフィールドが一意である必要があります。そうでない場合、宛先データベースに重複データレコードが含まれる可能性があります。

• 同期対象のオブジェクトとしてテーブルを選択し、宛先データベースでテーブルまたは列の名前変更などのテーブルの変更が必要な場合は、1 つのデータ同期タスクで最大 1,000 個のテーブルを同期できます。 1,000 個を超えるテーブルを同期するタスクを実行すると、リクエストエラーが発生します。この場合、複数のタスクを構成してテーブルを同期するか、データベース全体を同期するタスクを構成することをお勧めします。

• バイナリログについては、次の要件を満たす必要があります。

  • バイナリロギング機能が有効になっており、loose_polar_log_bin パラメータが ON に設定されている必要があります。そうでない場合、事前チェック中にエラーメッセージが返され、DTS タスクを開始できません。詳細については、「バイナリロギングを有効にする」および「パラメータを変更する」をご参照ください。

    説明

    PolarDB for MySQL クラスタのバイナリロギング機能を有効にすると、バイナリログによって使用されるストレージスペースの料金が発生します。

  • PolarDB for MySQL クラスタのバイナリログは、少なくとも 3 日間保持する必要があります。バイナリログの保存期間を 7 日間に設定することをお勧めします。例外的な状況では、データの不整合または損失が発生する可能性があります。上記の要件に基づいてバイナリログの保存期間を構成してください。そうでない場合、DTS のサービスレベル契約 (SLA) におけるサービスの信頼性またはパフォーマンスが保証されない場合があります。

    説明

    PolarDB for MySQL クラスタのバイナリログの保存期間を設定する方法の詳細については、「バイナリロギングを有効にする」トピックの「保存期間を変更する」セクションをご参照ください。

• スキーマ同期と完全データ同期中は、DDL 文を実行してデータベースまたはテーブルのスキーマを変更しないでください。変更すると、データ同期タスクが失敗します。

その他の制限

• DTS は、ソース PolarDB for MySQL クラスタの読み取り専用ノードを同期しません。

• DTS は、ソース PolarDB for MySQL クラスタから Object Storage Service (OSS) 外部テーブルを同期しません。

• DTS タスクを実行するには、宛先データベースのトリガーと外部キーを無効にする必要があります。無効にしないと、タスクは失敗します。

• データを同期する前に、データ同期がソースデータベースと宛先データベースのパフォーマンスに与える影響を評価してください。オフピーク時にデータを同期することをお勧めします。初期完全データ同期中、DTS はソースデータベースと宛先データベースの読み取りリソースと書き込みリソースを使用します。これにより、データベースサーバーの負荷が増加する可能性があります。

• 初期完全データ同期中、同時 INSERT 操作により、宛先データベースのテーブルで断片化が発生します。初期完全データ同期が完了すると、宛先データベースの使用済み表領域のサイズはソースデータベースのサイズよりも大きくなります。

• データ同期中に、pt-online-schema-change などのツールを使用してソーステーブルで DDL 操作を実行しないことをお勧めします。実行すると、データ同期タスクが失敗します。

• データ同期中に他のソースからのデータが宛先データベースに書き込まれない場合は、Data Management (DMS) を使用してソーステーブルでオンライン DDL 操作を実行できます。詳細については、「ロックフリーの DDL 操作を実行する」をご参照ください。

• データ同期中に他のソースからのデータが宛先データベースに書き込まれると、ソースデータベースと宛先データベース間でデータの不整合が発生します。たとえば、他のソースからのデータが宛先データベースに書き込まれている間に DMS を使用してオンライン DDL 文を実行すると、宛先データベースでデータ損失が発生する可能性があります。

• 宛先の自己管理 Oracle データベースが Oracle Real Application Cluster (RAC) データベースである場合、データ同期タスクを構成するときに、Single Client Access Name (SCAN) IP アドレスではなく、単一の仮想 IP アドレス (VIP) のみを使用できます。 VIP を指定した後、Oracle RAC データベースのノードフェールオーバーはサポートされません。

• DTS タスクの実行に失敗した場合、DTS テクニカルサポートは 8 時間以内にタスクの復元を試みます。復元中、タスクが再起動され、タスクのパラメータが変更される場合があります。

  説明

  タスクのパラメータのみが変更される可能性があります。データベースのパラメータは変更されません。 変更される可能性のあるパラメータには、「DTS インスタンスのパラメータを変更する」トピックの「インスタンスパラメータを変更する」セクションのパラメータが含まれますが、これらに限定されません。

特別なケース

DTS は、CREATE DATABASE IF NOT EXISTS `test` 文をソースデータベースでスケジュールどおりに実行して、バイナリログファイルの位置を進めます。