このトピックでは、セルフマネージド MySQL データベースや ApsaraDB RDS for MySQL インスタンスなどの MySQL データベースからデータを移行する際に注意すべき注意事項と制限事項について説明します。データ移行タスクが期待どおりに実行されるように、タスクを構成する前に注意事項と制限事項をお読みください。
MySQL データベースからのデータ移行のシナリオ
以下は、MySQL データベースからデータを移行するシナリオです。シナリオによって注意事項と制限事項が異なる場合があります。特定のシナリオの注意事項と制限事項については、関連セクションをご覧ください。
MySQL データベース間でデータを移行する
次の表は、セルフマネージド MySQL データベースや ApsaraDB RDS for MySQL インスタンスなどの MySQL データベースにデータを移行する際に注意すべき注意事項と制限事項を示しています。
カテゴリ | 説明 |
ソースデータベースの制限 | ソースデータベースがデプロイされているサーバーには、十分なアウトバウンド帯域幅が必要です。そうでない場合、データ移行速度が低下します。 移行するテーブルには、プライマリキーまたは一意の制約があり、すべてのフィールドが一意である必要があります。そうでない場合、ターゲットデータベースに重複したデータレコードが含まれる可能性があります。 移行対象としてテーブルを選択し、ターゲットデータベース内のテーブル（テーブル名や列名の変更など）を変更する場合、1 つのデータ移行タスクで最大 1,000 個のテーブルを移行できます。 1,000 個を超えるテーブルを移行するタスクを実行すると、リクエストエラーが発生します。この場合、複数のタスクを構成してテーブルを移行するか、データベース全体を移行するタスクを構成することをお勧めします。 増分データを移行する場合、バイナリログの次の要件を満たす必要があります。 バイナリロギング機能が有効になっています。 binlog_format パラメータは row に設定され、binlog_row_image パラメータは full に設定されています。そうでない場合、事前チェック中にエラーメッセージが返され、データ移行タスクが開始に失敗します。
重要 ソースデータベースがデュアルプライマリクラスタにデプロイされたセルフマネージド MySQL データベースの場合、log_slave_updates パラメータを ON に設定する必要があります。これにより、DTS がすべてのバイナリログを取得できるようになります。 ApsaraDB RDS for MySQL インスタンスのバイナリログは、少なくとも 3 日間保存する必要があります。バイナリログは 7 日間保存することをお勧めします。セルフマネージド MySQL データベースのバイナリログは、少なくとも 7 日間保存する必要があります。そうでない場合、DTS がバイナリログの取得に失敗し、タスクが失敗する可能性があります。例外的な状況では、データの不整合または損失が発生する可能性があります。上記の要件に基づいてバイナリログの保持期間を構成してください。そうでない場合、DTS のサービスレベル契約（SLA）に記載されているサービスの信頼性またはパフォーマンスが保証されない場合があります。
ソースデータベースで実行される操作の制限: スキーマ移行とフルデータ移行中は、DDL ステートメントを実行してデータベースまたはテーブルのスキーマを変更しないでください。そうしないと、データ移行タスクが失敗します。 フルデータ移行のみを実行する場合は、データ移行中にソースデータベースにデータを書き込まないでください。そうしないと、ソースデータベースとターゲットデータベース間でデータの不整合が発生します。データの整合性を確保するために、移行タイプとしてスキーマ移行、フルデータ移行、増分データ移行を選択することをお勧めします。
データ移行インスタンスの実行中は、物理バックアップから復元されたデータやカスケード操作からのデータなど、バイナリログの変更操作によって生成されたデータは記録されず、ターゲットデータベースに移行されません。
説明 変更データが記録されず、ターゲットデータベースに移行されない場合は、ビジネスに影響がないことを前提に、フルデータを再度移行できます。 ソースデータベースが MySQL データベース 8.0.23 以後のバージョンで、移行するデータに非表示の列が含まれている場合、列のデータを取得できず、データ損失が発生します。
|
その他の制限 | 互換性を確保するために、ソース MySQL データベースとターゲット MySQL データベースのバージョンが同じである必要があります。 インデックスとパーティションは移行できません。 DTS は、コメントを使用して定義されたパーサーが使用されているデータは移行しません。 ターゲットデータベースが MySQL データベース 8.0.23 以後のバージョンで、データを受信する列に非表示の列が含まれている場合、データが書き込まれるターゲット列が見つかりません。この場合、DTS インスタンスの実行に失敗し、データ損失が発生します。 データ移行シナリオで DTS のスキーマ移行機能を使用しない場合は、フィールドの互換性を確保する必要があります。たとえば、ソーステーブルのフィールドが text 型で、ターゲットテーブルのフィールドが varchar(255) 型の場合、ソーステーブルに大きなフィールドが含まれていると、データが切り捨てられる可能性があります。 移行するデータに、4 バイトを占める希少文字や絵文字などの情報が含まれている場合、データを受信するターゲットデータベースとテーブルは UTF8mb4 文字セットを使用する必要があります。
説明 DTS のスキーマ移行機能を使用する場合は、ターゲットデータベースのインスタンスパラメータ character_set_server を UTF8mb4 文字セットに設定します。 データを移行する前に、データ移行がソースデータベースとターゲットデータベースのパフォーマンスに及ぼす影響を評価してください。オフピーク時にデータを移行することをお勧めします。フルデータ移行中は、DTS はソースデータベースとターゲットデータベースの読み取りリソースと書き込みリソースを使用します。これにより、データベースサーバーの負荷が増加する可能性があります。 フルデータ移行中、同時 INSERT 操作により、ターゲットデータベースのテーブルで断片化が発生します。フルデータ移行が完了すると、ターゲットデータベースのテーブルスペースはソースデータベースのテーブルスペースよりも大きくなります。 FLOAT または DOUBLE データ型の列の精度設定がビジネス要件を満たしていることを確認する必要があります。DTS は、ROUND(COLUMN,PRECISION) 関数を使用して、FLOAT または DOUBLE データ型の列から値を取得します。精度を指定しない場合、DTS は FLOAT データ型の列の精度を 38 桁に設定し、DOUBLE データ型の列の精度を 308 桁に設定します。 DTS は、過去 7 日以内に失敗したデータ移行タスクの再開を試みます。ワークロードをターゲットデータベースに切り替える前に、失敗したタスクを停止または解放する必要があります。また、REVOKE ステートメントを実行して、DTS がターゲットデータベースにアクセスするために使用するアカウントから書き込み権限を取り消すこともできます。そうしないと、失敗したタスクが再開された後、ソースデータベースのデータによってターゲットデータベースのデータが上書きされます。 ターゲットデータベースで DDL ステートメントの実行に失敗した場合でも、DTS タスクは引き続き実行されます。実行に失敗した DDL ステートメントは、タスクログで確認できます。タスクログの表示方法の詳細については、「タスクログを表示する」をご参照ください。 大文字と小文字のみが異なる列名をターゲット MySQL データベースの同じテーブルに書き込むと、MySQL データベースの列名は大文字と小文字が区別されないため、データ移行の結果が期待どおりにならない可能性があります。 データ移行が完了した後、つまり、インスタンスの [ステータス] が [完了] に変更された後、analyze table <table name> コマンドを実行して、データがターゲットテーブルに書き込まれているかどうかを確認することをお勧めします。たとえば、ターゲット MySQL データベースで高可用性（HA）スイッチオーバーがトリガーされると、データはメモリにのみ書き込まれる可能性があります。その結果、データ損失が発生します。 ソースデータベースが EncDB 機能が有効になっている ApsaraDB RDS for MySQL インスタンスの場合、フルデータ移行を実行できません。
説明 透過的データ暗号化（TDE）機能が有効になっている ApsaraDB RDS for MySQL インスタンスは、スキーマ移行、フルデータ移行、増分データ移行をサポートしています。 ソースデータベースからターゲットデータベースにアカウントを移行する場合、前提条件と注意事項を理解する必要があります。詳細については、「データベースアカウントを移行する」をご参照ください。 DTS タスクの実行に失敗した場合、DTS テクニカルサポートは 8 時間以内にタスクの復元を試みます。復元中に、タスクが再起動され、タスクのパラメータが変更される場合があります。
説明 DTS タスクのパラメータのみが変更される可能性があります。データベースのパラメータは変更されません。 変更される可能性のあるパラメータには、「DTS インスタンスのパラメータを変更する」トピックの「インスタンスパラメータを変更する」セクションのパラメータが含まれますが、これらに限定されません。
|
特別なケース | ソースデータベースがセルフマネージド MySQL データベースの場合、次の制限事項に注意してください。 データ移行タスクの実行中にソースデータベースでプライマリ/セカンダリスイッチオーバーを実行すると、タスクは失敗します。 DTS は、ターゲットデータベースに最後に移行されたデータのタイムスタンプとソースデータベースの現在のタイムスタンプに基づいて移行レイテンシを計算します。ソースデータベースで DML 操作が長時間実行されない場合、移行レイテンシが不正確になる可能性があります。データ移行タスクのレイテンシが過度に高い場合は、ソースデータベースで DML 操作を実行してレイテンシを更新できます。
説明 データベース全体を移行対象として選択した場合は、ハートビートテーブルを作成できます。ハートビートテーブルは毎秒更新またはデータを受信します。 DTS は、バイナリログファイルの位置を進めるために、スケジュールどおりにソースデータベースで CREATE DATABASE IF NOT EXISTS `test` ステートメントを実行します。
ソースデータベースが Apsara RDS for MySQL インスタンスの場合、次の制限事項に注意してください。 増分データ移行では、読み取り専用の ApsaraDB RDS for MySQL V5.6 インスタンスなど、トランザクションログを記録しない ApsaraDB RDS for MySQL インスタンスをソースデータベースとして使用できません。 DTS は、バイナリログファイルの位置を進めるために、スケジュールどおりにソースデータベースで CREATE DATABASE IF NOT EXISTS `test` ステートメントを実行します。
ターゲットデータベースが ApsaraDB RDS for MySQL インスタンスの場合、次の制限事項に注意してください。 DTS は、ターゲット ApsaraDB RDS for MySQL インスタンスにデータベースを自動的に作成します。ただし、ソースデータベースの名前が ApsaraDB RDS for MySQL のデータベース命名規則に準拠していない場合は、データ移行タスクを構成する前に、ターゲット ApsaraDB RDS for MySQL インスタンスにデータベースを手動で作成する必要があります。詳細については、「データベースを管理する」をご参照ください。
|
MySQL データベースから PolarDB for MySQL クラスタにデータを移行する
次の表は、MySQL データベースから PolarDB for MySQL クラスタにデータを移行する際に注意すべき注意事項と制限事項を示しています。
カテゴリ | 説明 |
ソースデータベースの制限 | ソースデータベースがデプロイされているサーバーには、十分なアウトバウンド帯域幅が必要です。そうでない場合、データ移行速度が低下します。 移行するテーブルには、プライマリキーまたは一意の制約があり、すべてのフィールドが一意である必要があります。そうでない場合、ターゲットデータベースに重複したデータレコードが含まれる可能性があります。 移行対象としてテーブルを選択し、ターゲットデータベース内のテーブル（テーブル名や列名の変更など）を変更する場合、1 つのデータ移行タスクで最大 1,000 個のテーブルを移行できます。 1,000 個を超えるテーブルを移行するタスクを実行すると、リクエストエラーが発生します。この場合、複数のタスクを構成してテーブルを移行するか、データベース全体を移行するタスクを構成することをお勧めします。 増分データを移行する場合、バイナリログの次の要件を満たす必要があります。 バイナリロギング機能が有効になっています。 binlog_format パラメータは row に設定され、binlog_row_image パラメータは full に設定されています。そうでない場合、事前チェック中にエラーメッセージが返され、データ移行タスクが開始に失敗します。
重要 ソースデータベースがデュアルプライマリクラスタにデプロイされたセルフマネージド MySQL データベースの場合、log_slave_updates パラメータを ON に設定する必要があります。これにより、DTS がすべてのバイナリログを取得できるようになります。 ApsaraDB RDS for MySQL インスタンスのバイナリログは、少なくとも 3 日間保存する必要があります。バイナリログは 7 日間保存することをお勧めします。セルフマネージド MySQL データベースのバイナリログは、少なくとも 7 日間保存する必要があります。そうでない場合、DTS がバイナリログの取得に失敗し、タスクが失敗する可能性があります。例外的な状況では、データの不整合または損失が発生する可能性があります。上記の要件に基づいてバイナリログの保持期間を構成してください。そうでない場合、DTS のサービスレベル契約（SLA）に記載されているサービスの信頼性またはパフォーマンスが保証されない場合があります。
ソースデータベースで実行される操作の制限: スキーマ移行とフルデータ移行中は、DDL ステートメントを実行してデータベースまたはテーブルのスキーマを変更しないでください。そうしないと、データ移行タスクが失敗します。 フルデータ移行のみを実行する場合は、データ移行中にソースデータベースにデータを書き込まないでください。そうしないと、ソースデータベースとターゲットデータベース間でデータの不整合が発生します。データの整合性を確保するために、移行タイプとしてスキーマ移行、フルデータ移行、増分データ移行を選択することをお勧めします。
データ移行インスタンスの実行中は、物理バックアップから復元されたデータやカスケード操作からのデータなど、バイナリログの変更操作によって生成されたデータは記録されず、ターゲットデータベースに移行されません。
説明 変更データが記録されず、ターゲットデータベースに移行されない場合は、ビジネスに影響がないことを前提に、フルデータを再度移行できます。 ソースデータベースが MySQL データベース 8.0.23 以後のバージョンで、移行するデータに非表示の列が含まれている場合、列のデータを取得できず、データ損失が発生します。
|
その他の制限 | 互換性を確保するために、ソース MySQL データベースとターゲット MySQL データベースのバージョンが同じである必要があります。 インデックスとパーティションは移行できません。 DTS は、コメントを使用して定義されたパーサーが使用されているデータは移行しません。 データを移行する前に、データ移行がソースデータベースとターゲットデータベースのパフォーマンスに及ぼす影響を評価してください。オフピーク時にデータを移行することをお勧めします。フルデータ移行中は、DTS はソースデータベースとターゲットデータベースの読み取りリソースと書き込みリソースを使用します。これにより、データベースサーバーの負荷が増加する可能性があります。 フルデータ移行中、同時 INSERT 操作により、ターゲットデータベースのテーブルで断片化が発生します。フルデータ移行が完了すると、ターゲットデータベースのテーブルスペースはソースデータベースのテーブルスペースよりも大きくなります。 移行するデータに、4 バイトを占める希少文字や絵文字などの情報が含まれている場合、データを受信するターゲットデータベースとテーブルは UTF8mb4 文字セットを使用する必要があります。
説明 DTS のスキーマ移行機能を使用する場合は、ターゲットデータベースのインスタンスパラメータ character_set_server を UTF8mb4 文字セットに設定します。 FLOAT または DOUBLE データ型の列の精度設定がビジネス要件を満たしていることを確認する必要があります。DTS は、ROUND(COLUMN,PRECISION) 関数を使用して、FLOAT または DOUBLE データ型の列から値を取得します。精度を指定しない場合、DTS は FLOAT データ型の列の精度を 38 桁に設定し、DOUBLE データ型の列の精度を 308 桁に設定します。 DTS は、過去 7 日以内に失敗したデータ移行タスクの再開を試みます。ワークロードをターゲットデータベースに切り替える前に、失敗したタスクを停止または解放する必要があります。また、REVOKE ステートメントを実行して、DTS がターゲットデータベースにアクセスするために使用するアカウントから書き込み権限を取り消すこともできます。そうしないと、失敗したタスクが再開された後、ソースデータベースのデータによってターゲットデータベースのデータが上書きされます。 DATETIME 型から VARCHAR 型にデータを変換することはできません。 ターゲットデータベースで DDL ステートメントの実行に失敗した場合でも、DTS タスクは引き続き実行されます。実行に失敗した DDL ステートメントは、タスクログで確認できます。タスクログの表示方法の詳細については、「タスクログを表示する」をご参照ください。 ソースデータベースが EncDB 機能が有効になっている ApsaraDB RDS for MySQL インスタンスの場合、フルデータ移行を実行できません。
説明 透過的データ暗号化（TDE）機能が有効になっている ApsaraDB RDS for MySQL インスタンスは、スキーマ移行、フルデータ移行、増分データ移行をサポートしています。 ソースデータベースからターゲットデータベースにアカウントを移行する場合、前提条件と注意事項を理解する必要があります。詳細については、「データベースアカウントを移行する」をご参照ください。 DTS タスクの実行に失敗した場合、DTS テクニカルサポートは 8 時間以内にタスクの復元を試みます。復元中に、タスクが再起動され、タスクのパラメータが変更される場合があります。
説明 DTS タスクのパラメータのみが変更される可能性があります。データベースのパラメータは変更されません。 変更される可能性のあるパラメータには、「DTS インスタンスのパラメータを変更する」トピックの「インスタンスパラメータを変更する」セクションのパラメータが含まれますが、これらに限定されません。
|
特別なケース | |
MySQL データベースから PolarDB-X V2.0 インスタンスにデータを移行する
次の表は、MySQL データベースから PolarDB-X V2.0 インスタンスにデータを移行する際に注意すべき注意事項と制限事項を示しています。
カテゴリ | 説明 |
ソースデータベースの制限 | ソースデータベースがデプロイされているサーバーには、十分なアウトバウンド帯域幅が必要です。そうでない場合、データ移行速度が低下します。 移行するテーブルには、プライマリキーまたは一意の制約があり、すべてのフィールドが一意である必要があります。そうでない場合、ターゲットデータベースに重複したデータレコードが含まれる可能性があります。 移行対象としてテーブルを選択し、ターゲットデータベース内のテーブル（テーブル名や列名の変更など）を変更する場合、1 つのデータ移行タスクで最大 1,000 個のテーブルを移行できます。 1,000 個を超えるテーブルを移行するタスクを実行すると、リクエストエラーが発生します。この場合、複数のタスクを構成してテーブルを移行するか、データベース全体を移行するタスクを構成することをお勧めします。 増分データを移行する場合、バイナリログの次の要件を満たす必要があります。 バイナリロギング機能が有効になっています。 binlog_format パラメータは row に設定され、binlog_row_image パラメータは full に設定されています。そうでない場合、事前チェック中にエラーメッセージが返され、データ移行タスクが開始に失敗します。
重要 ソースデータベースがデュアルプライマリクラスタにデプロイされたセルフマネージド MySQL データベースの場合、log_slave_updates パラメータを ON に設定する必要があります。これにより、DTS がすべてのバイナリログを取得できるようになります。 ApsaraDB RDS for MySQL インスタンスのバイナリログは、少なくとも 3 日間保存する必要があります。バイナリログは 7 日間保存することをお勧めします。セルフマネージド MySQL データベースのバイナリログは、少なくとも 7 日間保存する必要があります。そうでない場合、DTS がバイナリログの取得に失敗し、タスクが失敗する可能性があります。例外的な状況では、データの不整合または損失が発生する可能性があります。上記の要件に基づいてバイナリログの保持期間を構成してください。そうでない場合、DTS のサービスレベル契約（SLA）に記載されているサービスの信頼性またはパフォーマンスが保証されない場合があります。
ソースデータベースで実行される操作の制限: フルデータ移行中は、DDL ステートメントを実行してデータベースまたはテーブルのスキーマを変更しないでください。そうしないと、データ移行タスクが失敗します。 フルデータ移行のみを実行する場合は、データ移行中にソースデータベースにデータを書き込まないでください。そうしないと、ソースデータベースとターゲットデータベース間でデータの不整合が発生します。データの整合性を確保するために、移行タイプとしてフルデータ移行と増分データ移行を選択することをお勧めします。
データ移行インスタンスの実行中は、物理バックアップから復元されたデータやカスケード操作からのデータなど、バイナリログの変更操作によって生成されたデータは記録されず、ターゲットデータベースに移行されません。
説明 変更データが記録されず、ターゲットデータベースに移行されない場合は、ビジネスに影響がないことを前提に、フルデータを再度移行できます。 ソースデータベースが MySQL データベース 8.0.23 以後のバージョンで、移行するデータに非表示の列が含まれている場合、列のデータを取得できず、データ損失が発生します。
|
その他の制限 | データを移行する前に、データ移行がソースデータベースとターゲットデータベースのパフォーマンスに及ぼす影響を評価してください。オフピーク時にデータを移行することをお勧めします。フルデータ移行中は、DTS はソースデータベースとターゲットデータベースの読み取りリソースと書き込みリソースを使用します。これにより、データベースサーバーの負荷が増加する可能性があります。 フルデータ移行中、同時 INSERT 操作により、ターゲットデータベースのテーブルで断片化が発生します。フルデータ移行が完了すると、ターゲットデータベースのテーブルスペースはソースデータベースのテーブルスペースよりも大きくなります。 FLOAT または DOUBLE データ型の列の精度設定がビジネス要件を満たしていることを確認する必要があります。DTS は、ROUND(COLUMN,PRECISION) 関数を使用して、FLOAT または DOUBLE データ型の列から値を取得します。精度を指定しない場合、DTS は FLOAT データ型の列の精度を 38 桁に設定し、DOUBLE データ型の列の精度を 308 桁に設定します。 DTS は、過去 7 日以内に失敗したデータ移行タスクの再開を試みます。ワークロードをターゲットデータベースに切り替える前に、失敗したタスクを停止または解放する必要があります。また、REVOKE ステートメントを実行して、DTS がターゲットデータベースにアクセスするために使用するアカウントから書き込み権限を取り消すこともできます。そうしないと、失敗したタスクが再開された後、ソースデータベースのデータによってターゲットデータベースのデータが上書きされます。 ソースデータベースが EncDB 機能が有効になっている ApsaraDB RDS for MySQL インスタンスの場合、フルデータ移行を実行できません。
説明 透過的データ暗号化（TDE）機能が有効になっている ApsaraDB RDS for MySQL インスタンスは、スキーマ移行、フルデータ移行、増分データ移行をサポートしています。 DTS タスクの実行に失敗した場合、DTS テクニカルサポートは 8 時間以内にタスクの復元を試みます。復元中に、タスクが再起動され、タスクのパラメータが変更される場合があります。
説明 DTS タスクのパラメータのみが変更される可能性があります。データベースのパラメータは変更されません。 変更される可能性のあるパラメータには、「DTS インスタンスのパラメータを変更する」トピックの「インスタンスパラメータを変更する」セクションのパラメータが含まれますが、これらに限定されません。
|
特別なケース | ソースデータベースがセルフマネージド MySQL データベースの場合、次の制限事項に注意してください。 データ移行タスクの実行中にソースデータベースでプライマリ/セカンダリスイッチオーバーを実行すると、タスクは失敗します。 DTS は、ターゲットデータベースに最後に移行されたデータのタイムスタンプとソースデータベースの現在のタイムスタンプに基づいて移行レイテンシを計算します。ソースデータベースで DML 操作が長時間実行されない場合、移行レイテンシが不正確になる可能性があります。データ移行タスクのレイテンシが過度に高い場合は、ソースデータベースで DML 操作を実行してレイテンシを更新できます。
説明 データベース全体を移行対象として選択した場合は、ハートビートテーブルを作成できます。ハートビートテーブルは毎秒更新またはデータを受信します。 DTS は、バイナリログファイルの位置を進めるために、スケジュールどおりにソースデータベースで CREATE DATABASE IF NOT EXISTS `test` ステートメントを実行します。
ソースデータベースが Apsara RDS for MySQL インスタンスの場合、次の制限事項に注意してください。 増分データ移行では、読み取り専用の ApsaraDB RDS for MySQL V5.6 インスタンスなど、トランザクションログを記録しない ApsaraDB RDS for MySQL インスタンスをソースデータベースとして使用できません。 DTS は、バイナリログファイルの位置を進めるために、スケジュールどおりにソースデータベースで CREATE DATABASE IF NOT EXISTS `test` ステートメントを実行します。
|
MySQL データベースから AnalyticDB for MySQL クラスタにデータを移行する
次の表は、MySQL データベースから AnalyticDB for MySQL クラスタにデータを移行する際に注意すべき注意事項と制限事項を示しています。
カテゴリ | 説明 |
ソースデータベースの制限 | ソースデータベースがデプロイされているサーバーには、十分なアウトバウンド帯域幅が必要です。そうでない場合、データ移行速度が低下します。 移行するテーブルには、プライマリキーまたは一意の制約があり、すべてのフィールドが一意である必要があります。そうでない場合、ターゲットデータベースに重複したデータレコードが含まれる可能性があります。 移行対象としてテーブルを選択し、ターゲットデータベース内のテーブル（テーブル名や列名の変更など）を変更する場合、1 つのデータ移行タスクで最大 1,000 個のテーブルを移行できます。 1,000 個を超えるテーブルを移行するタスクを実行すると、リクエストエラーが発生します。この場合、複数のタスクを構成してテーブルを移行するか、データベース全体を移行するタスクを構成することをお勧めします。 増分データを移行する場合、バイナリログの次の要件を満たす必要があります。 バイナリロギング機能が有効になっています。 binlog_format パラメータは row に設定され、binlog_row_image パラメータは full に設定されています。そうでない場合、事前チェック中にエラーメッセージが返され、データ移行タスクが開始に失敗します。
重要 ソースデータベースがデュアルプライマリクラスタにデプロイされたセルフマネージド MySQL データベースの場合、log_slave_updates パラメータを ON に設定する必要があります。これにより、DTS がすべてのバイナリログを取得できるようになります。 ApsaraDB RDS for MySQL インスタンスのバイナリログは、少なくとも 3 日間保存する必要があります。バイナリログは 7 日間保存することをお勧めします。セルフマネージド MySQL データベースのバイナリログは、少なくとも 7 日間保存する必要があります。そうでない場合、DTS がバイナリログの取得に失敗し、タスクが失敗する可能性があります。例外的な状況では、データの不整合または損失が発生する可能性があります。上記の要件に基づいてバイナリログの保持期間を構成してください。そうでない場合、DTS のサービスレベル契約（SLA）に記載されているサービスの信頼性またはパフォーマンスが保証されない場合があります。
ソースデータベースで実行される操作の制限: スキーマ移行とフルデータ移行中は、DDL ステートメントを実行してデータベースまたはテーブルのスキーマを変更しないでください。そうしないと、データ移行タスクが失敗します。 データ移行中に、DDL ステートメントを実行してコメントを追加しないでください。そうしないと、データ移行タスクが失敗します。たとえば、ALTER TABLE table_name COMMENT='Table comment'; ステートメントは実行しないでください。 フルデータ移行のみを実行する場合は、データ移行中にソースデータベースにデータを書き込まないでください。そうしないと、ソースデータベースとターゲットデータベース間でデータの不整合が発生します。データの整合性を確保するために、移行タイプとしてスキーマ移行、フルデータ移行、増分データ移行を選択することをお勧めします。 データ移行インスタンスの実行中は、物理バックアップから復元されたデータやカスケード操作からのデータなど、バイナリログの変更操作によって生成されたデータは記録されず、ターゲットデータベースに移行されません。
説明 変更データが記録されず、ターゲットデータベースに移行されない場合は、ビジネスに影響がないことを前提に、フルデータを再度移行できます。 ソースデータベースが MySQL データベース 8.0.23 以後のバージョンで、移行するデータに非表示の列が含まれている場合、列のデータを取得できず、データ損失が発生します。
|
その他の制限 | プレフィックスインデックスは移行できません。ソースデータベースにプレフィックスインデックスが含まれている場合、データの移行に失敗する可能性があります。 インデックス、パーティション、ビュー、プロシージャ、関数、トリガー、外部キーは移行できません。 ターゲットデータベースでカスタムプライマリキーを指定するか、[データベース、テーブル、および列の構成] で [プライマリキー列] を構成する必要があります。そうでない場合、データの移行に失敗する可能性があります。 AnalyticDB for MySQL クラスタの制限により、AnalyticDB for MySQL クラスタ内のノードのディスク容量の使用率が 80% を超えると、ターゲットデータベースへのデータ書き込みのパフォーマンスが低下し、DTS タスクが遅延します。移行するオブジェクトに基づいて必要なディスク容量を見積もることをお勧めします。ターゲットクラスタに十分なストレージ容量があることを確認してください。 データを移行する前に、データ移行がソースデータベースとターゲットデータベースのパフォーマンスに及ぼす影響を評価してください。オフピーク時にデータを移行することをお勧めします。フルデータ移行中は、DTS はソースデータベースとターゲットデータベースの読み取りリソースと書き込みリソースを使用します。これにより、データベースサーバーの負荷が増加する可能性があります。 フルデータ移行中、同時 INSERT 操作により、ターゲットデータベースのテーブルで断片化が発生します。フルデータ移行が完了すると、ターゲットデータベースのテーブルスペースはソースデータベースのテーブルスペースよりも大きくなります。 FLOAT または DOUBLE データ型の列の精度設定がビジネス要件を満たしていることを確認する必要があります。DTS は、ROUND(COLUMN,PRECISION) 関数を使用して、FLOAT または DOUBLE データ型の列から値を取得します。精度を指定しない場合、DTS は FLOAT データ型の列の精度を 38 桁に設定し、DOUBLE データ型の列の精度を 308 桁に設定します。 DTS は、過去 7 日以内に失敗したデータ移行タスクの再開を試みます。ワークロードをターゲットデータベースに切り替える前に、失敗したタスクを停止または解放する必要があります。また、REVOKE ステートメントを実行して、DTS がターゲットデータベースにアクセスするために使用するアカウントから書き込み権限を取り消すこともできます。そうしないと、失敗したタスクが再開された後、ソースデータベースのデータによってターゲットデータベースのデータが上書きされます。 ターゲットデータベースで DDL ステートメントの実行に失敗した場合でも、DTS タスクは引き続き実行されます。実行に失敗した DDL ステートメントは、タスクログで確認できます。タスクログの表示方法の詳細については、「タスクログを表示する」をご参照ください。 ソースデータベースが EncDB 機能が有効になっている ApsaraDB RDS for MySQL インスタンスの場合、フルデータ移行を実行できません。
説明 透過的データ暗号化（TDE）機能が有効になっている ApsaraDB RDS for MySQL インスタンスは、スキーマ移行、フルデータ移行、増分データ移行をサポートしています。 ソースデータベースが EncDB 機能が有効になっている ApsaraDB RDS for MySQL インスタンスの場合、フルデータ移行を実行できません。
説明 透過的データ暗号化（TDE）機能が有効になっている ApsaraDB RDS for MySQL インスタンスは、スキーマ移行、フルデータ移行、増分データ移行をサポートしています。 DTS タスクの実行に失敗した場合、DTS テクニカルサポートは 8 時間以内にタスクの復元を試みます。復元中に、タスクが再起動され、タスクのパラメータが変更される場合があります。
説明 DTS タスクのパラメータのみが変更される可能性があります。データベースのパラメータは変更されません。 変更される可能性のあるパラメータには、「DTS インスタンスのパラメータを変更する」トピックの「インスタンスパラメータを変更する」セクションのパラメータが含まれますが、これらに限定されません。
|
特別なケース | ソースデータベースがセルフマネージド MySQL データベースの場合、次の制限事項に注意してください。 データ移行タスクの実行中にソースデータベースでプライマリ/セカンダリスイッチオーバーを実行すると、タスクは失敗します。 DTS は、ターゲットデータベースに最後に移行されたデータのタイムスタンプとソースデータベースの現在のタイムスタンプに基づいて移行レイテンシを計算します。ソースデータベースで DML 操作が長時間実行されない場合、移行レイテンシが不正確になる可能性があります。データ移行タスクのレイテンシが過度に高い場合は、ソースデータベースで DML 操作を実行してレイテンシを更新できます。
説明 データベース全体を移行対象として選択した場合は、ハートビートテーブルを作成できます。ハートビートテーブルは毎秒更新またはデータを受信します。 DTS は、バイナリログファイルの位置を進めるために、スケジュールどおりにソースデータベースで CREATE DATABASE IF NOT EXISTS `test` ステートメントを実行します。
ソースデータベースが Apsara RDS for MySQL インスタンスの場合、次の制限事項に注意してください。 増分データ移行では、読み取り専用の ApsaraDB RDS for MySQL V5.6 インスタンスなど、トランザクションログを記録しない ApsaraDB RDS for MySQL インスタンスをソースデータベースとして使用できません。 DTS は、バイナリログファイルの位置を進めるために、スケジュールどおりにソースデータベースで CREATE DATABASE IF NOT EXISTS `test` ステートメントを実行します。
|
MySQL データベースからセルフマネージド Kafka クラスタにデータを移行する
次の表は、MySQL データベースからセルフマネージド Kafka クラスタにデータを移行する際に注意すべき注意事項と制限事項を示しています。
カテゴリ | 説明 |
ソースデータベースの制限 | ソースデータベースがデプロイされているサーバーには、十分なアウトバウンド帯域幅が必要です。そうでない場合、データ移行速度が低下します。 移行するテーブルには、プライマリキーまたは一意の制約があり、すべてのフィールドが一意である必要があります。そうでない場合、ターゲットデータベースに重複したデータレコードが含まれる可能性があります。 移行対象としてテーブルを選択し、ターゲットデータベース内のテーブル（テーブル名や列名の変更など）を変更する場合、1 つのデータ移行タスクで最大 1,000 個のテーブルを移行できます。 1,000 個を超えるテーブルを移行するタスクを実行すると、リクエストエラーが発生します。この場合、複数のタスクを構成してテーブルを移行するか、データベース全体を移行するタスクを構成することをお勧めします。 増分データを移行する場合、バイナリログの次の要件を満たす必要があります。 バイナリロギング機能が有効になっています。 binlog_format パラメータは row に設定され、binlog_row_image パラメータは full に設定されています。そうでない場合、事前チェック中にエラーメッセージが返され、データ移行タスクが開始に失敗します。
重要 ソースデータベースがデュアルプライマリクラスタにデプロイされたセルフマネージド MySQL データベースの場合、log_slave_updates パラメータを ON に設定する必要があります。これにより、DTS がすべてのバイナリログを取得できるようになります。 ApsaraDB RDS for MySQL インスタンスのバイナリログは、少なくとも 3 日間保存する必要があります。バイナリログは 7 日間保存することをお勧めします。セルフマネージド MySQL データベースのバイナリログは、少なくとも 7 日間保存する必要があります。そうでない場合、DTS がバイナリログの取得に失敗し、タスクが失敗する可能性があります。例外的な状況では、データの不整合または損失が発生する可能性があります。上記の要件に基づいてバイナリログの保持期間を構成してください。そうでない場合、DTS のサービスレベル契約（SLA）に記載されているサービスの信頼性またはパフォーマンスが保証されない場合があります。
ソースデータベースで実行される操作の制限: スキーマ移行とフルデータ移行中は、DDL ステートメントを実行してデータベースまたはテーブルのスキーマを変更しないでください。そうしないと、データ移行タスクが失敗します。 フルデータ移行のみを実行する場合は、データ移行中にソースデータベースにデータを書き込まないでください。そうしないと、ソースデータベースとターゲットデータベース間でデータの不整合が発生します。データの整合性を確保するために、移行タイプとしてスキーマ移行、フルデータ移行、増分データ移行を選択することをお勧めします。
データ移行インスタンスの実行中は、物理バックアップから復元されたデータやカスケード操作からのデータなど、バイナリログの変更操作によって生成されたデータは記録されず、ターゲットデータベースに移行されません。
説明 変更データが記録されず、ターゲットデータベースに移行されない場合は、ビジネスに影響がないことを前提に、フルデータを再度移行できます。 ソースデータベースが MySQL データベース 8.0.23 以後のバージョンで、移行するデータに非表示の列が含まれている場合、列のデータを取得できず、データ損失が発生します。
|
その他の制限 | 移行対象としてテーブルのみを選択できます。 インデックス、パーティション、ビュー、プロシージャ、関数、トリガー、および外部キーは移行できません。 データを移行する前に、データ移行がソースデータベースとターゲットデータベースのパフォーマンスに及ぼす影響を評価してください。オフピーク時にデータを移行することをお勧めします。フルデータ移行中は、DTS はソースデータベースとターゲットデータベースの読み取りリソースと書き込みリソースを使用します。これにより、データベースサーバーの負荷が増加する可能性があります。 フルデータ移行中、同時 INSERT 操作により、ターゲットデータベースのテーブルで断片化が発生します。フルデータ移行が完了すると、ターゲットデータベースのテーブルスペースはソースデータベースのテーブルスペースよりも大きくなります。 FLOAT または DOUBLE データ型の列の精度設定がビジネス要件を満たしていることを確認する必要があります。DTS は、ROUND(COLUMN,PRECISION) 関数を使用して、FLOAT または DOUBLE データ型の列から値を取得します。精度を指定しない場合、DTS は FLOAT データ型の列の精度を 38 桁に設定し、DOUBLE データ型の列の精度を 308 桁に設定します。 DTS は、過去 7 日以内に失敗したデータ移行タスクの再開を試みます。ワークロードをターゲットデータベースに切り替える前に、失敗したタスクを停止または解放する必要があります。また、REVOKE ステートメントを実行して、DTS がターゲットデータベースにアクセスするために使用するアカウントから書き込み権限を取り消すこともできます。そうしないと、失敗したタスクが再開された後、ソースデータベースのデータによってターゲットデータベースのデータが上書きされます。 データ同期中に他のソースからのデータがターゲットデータベースに書き込まれると、ソースデータベースとターゲットデータベース間でデータの不整合が発生します。 データ移行中にターゲット Kafka クラスタがアップグレードまたはダウングレードされた場合は、データ移行タスクを再起動する必要があります。 ソースデータベースが EncDB 機能が有効になっている ApsaraDB RDS for MySQL インスタンスの場合、フルデータ移行を実行できません。
説明 透過的データ暗号化（TDE）機能が有効になっている ApsaraDB RDS for MySQL インスタンスは、スキーマ移行、フルデータ移行、増分データ移行をサポートしています。 DTS タスクの実行に失敗した場合、DTS テクニカルサポートは 8 時間以内にタスクの復元を試みます。復元中に、タスクが再起動され、タスクのパラメータが変更される場合があります。
説明 DTS タスクのパラメータのみが変更される可能性があります。データベースのパラメータは変更されません。 変更される可能性のあるパラメータには、「DTS インスタンスのパラメータを変更する」トピックの「インスタンスパラメータを変更する」セクションのパラメータが含まれますが、これらに限定されません。
|
特別なケース | ソースデータベースがセルフマネージド MySQL データベースの場合、次の制限事項に注意してください。 データ移行タスクの実行中にソースデータベースでプライマリ/セカンダリスイッチオーバーを実行すると、タスクは失敗します。 DTS は、ターゲットデータベースに最後に移行されたデータのタイムスタンプとソースデータベースの現在のタイムスタンプに基づいて移行レイテンシを計算します。ソースデータベースで DML 操作が長時間実行されない場合、移行レイテンシが不正確になる可能性があります。データ移行タスクのレイテンシが過度に高い場合は、ソースデータベースで DML 操作を実行してレイテンシを更新できます。
説明 データベース全体を移行対象として選択した場合は、ハートビートテーブルを作成できます。ハートビートテーブルは毎秒更新またはデータを受信します。 DTS は、バイナリログファイルの位置を進めるために、スケジュールどおりにソースデータベースで CREATE DATABASE IF NOT EXISTS `test` ステートメントを実行します。
ソースデータベースが Apsara RDS for MySQL インスタンスの場合、次の制限事項に注意してください。 増分データ移行では、読み取り専用の ApsaraDB RDS for MySQL V5.6 インスタンスなど、トランザクションログを記録しない ApsaraDB RDS for MySQL インスタンスをソースデータベースとして使用できません。 DTS は、バイナリログファイルの位置を進めるために、スケジュールどおりにソースデータベースで CREATE DATABASE IF NOT EXISTS `test` ステートメントを実行します。
|
MySQL データベースから DataHub プロジェクトにデータを移行する
次の表は、MySQL データベースから DataHub プロジェクトにデータを移行する際に注意すべき注意事項と制限事項を示しています。
カテゴリ | 説明 |
ソースデータベースの制限 | ソースデータベースがデプロイされているサーバーには、十分なアウトバウンド帯域幅が必要です。そうでない場合、データ移行速度が低下します。 移行するテーブルには、プライマリキーまたは一意の制約があり、すべてのフィールドが一意である必要があります。そうでない場合、ターゲットデータベースに重複したデータレコードが含まれる可能性があります。 移行対象としてテーブルを選択し、ターゲットデータベース内のテーブル（テーブル名や列名の変更など）を変更する場合、1 つのデータ移行タスクで最大 1,000 個のテーブルを移行できます。 1,000 個を超えるテーブルを移行するタスクを実行すると、リクエストエラーが発生します。この場合、複数のタスクを構成してテーブルを移行するか、データベース全体を移行するタスクを構成することをお勧めします。 増分データを移行する場合、バイナリログの次の要件を満たす必要があります。 バイナリロギング機能が有効になっています。 binlog_format パラメータは row に設定され、binlog_row_image パラメータは full に設定されています。そうでない場合、事前チェック中にエラーメッセージが返され、データ移行タスクが開始に失敗します。
重要 ソースデータベースがデュアルプライマリクラスタにデプロイされたセルフマネージド MySQL データベースの場合、log_slave_updates パラメータを ON に設定する必要があります。これにより、DTS がすべてのバイナリログを取得できるようになります。 ApsaraDB RDS for MySQL インスタンスのバイナリログは、少なくとも 3 日間保存する必要があります。バイナリログは 7 日間保存することをお勧めします。セルフマネージド MySQL データベースのバイナリログは、少なくとも 7 日間保存する必要があります。そうでない場合、DTS がバイナリログの取得に失敗し、タスクが失敗する可能性があります。例外的な状況では、データの不整合または損失が発生する可能性があります。上記の要件に基づいてバイナリログの保持期間を構成してください。そうでない場合、DTS のサービスレベル契約（SLA）に記載されているサービスの信頼性またはパフォーマンスが保証されない場合があります。
ソースデータベースで実行される操作の制限: スキーマ移行中は、DDL ステートメントを実行してデータベースまたはテーブルのスキーマを変更しないでください。そうしないと、データ移行タスクが失敗します。 データ移行インスタンスの実行中は、物理バックアップから復元されたデータやカスケード操作からのデータなど、バイナリログの変更操作によって生成されたデータは記録されず、ターゲットデータベースに移行されません。
説明 変更データが記録されず、ターゲットデータベースに移行されない場合は、ビジネスに影響がないことを前提に、フルデータを再度移行できます。 ソースデータベースが MySQL データベース 8.0.23 以後のバージョンで、移行するデータに非表示の列が含まれている場合、列のデータを取得できず、データ損失が発生します。
|
その他の制限 | 移行対象としてテーブルのみを選択できます。 インデックス、パーティション、ビュー、プロシージャ、関数、トリガー、および外部キーは移行できません。 ターゲット DataHub プロジェクトの 1 つの文字列の長さは 2 MB を超えることはできません。 データ移行中に、pt-online-schema-change などのツールを使用して、移行対象のオブジェクトに対して DDL 操作を実行しないでください。そうしないと、データ移行が失敗する可能性があります。 DMS を使用してオンライン DDL 操作を実行できます。詳細については、「ロックフリーの DDL 操作を実行する」をご参照ください。
警告 他のソースからのデータがターゲットデータベースに書き込まれている間は、DMS を使用してオンライン DDL ステートメントを実行しないでください。そうしないと、ターゲットデータベースでデータ損失が発生する可能性があります。 FLOAT または DOUBLE データ型の列の精度設定がビジネス要件を満たしていることを確認する必要があります。DTS は、ROUND(COLUMN,PRECISION) 関数を使用して、FLOAT または DOUBLE データ型の列から値を取得します。精度を指定しない場合、DTS は FLOAT データ型の列の精度を 38 桁に設定し、DOUBLE データ型の列の精度を 308 桁に設定します。 DTS は、過去 7 日以内に失敗したデータ移行タスクの再開を試みます。ワークロードをターゲットデータベースに切り替える前に、失敗したタスクを停止または解放する必要があります。また、REVOKE ステートメントを実行して、DTS がターゲットデータベースにアクセスするために使用するアカウントから書き込み権限を取り消すこともできます。そうしないと、失敗したタスクが再開された後、ソースデータベースのデータによってターゲットデータベースのデータが上書きされます。 ソースデータベースが EncDB 機能が有効になっている ApsaraDB RDS for MySQL インスタンスの場合、フルデータ移行を実行できません。
説明 透過的データ暗号化（TDE）機能が有効になっている ApsaraDB RDS for MySQL インスタンスは、スキーマ移行、フルデータ移行、増分データ移行をサポートしています。 DTS タスクの実行に失敗した場合、DTS テクニカルサポートは 8 時間以内にタスクの復元を試みます。復元中に、タスクが再起動され、タスクのパラメータが変更される場合があります。
説明 DTS タスクのパラメータのみが変更される可能性があります。データベースのパラメータは変更されません。 変更される可能性のあるパラメータには、「DTS インスタンスのパラメータを変更する」トピックの「インスタンスパラメータを変更する」セクションのパラメータが含まれますが、これらに限定されません。
|
特別なケース | ソースデータベースがセルフマネージド MySQL データベースの場合、次の制限事項に注意してください。 データ移行タスクの実行中にソースデータベースでプライマリ/セカンダリスイッチオーバーを実行すると、タスクは失敗します。 DTS は、ターゲットデータベースに最後に移行されたデータのタイムスタンプとソースデータベースの現在のタイムスタンプに基づいて移行レイテンシを計算します。ソースデータベースで DML 操作が長時間実行されない場合、移行レイテンシが不正確になる可能性があります。データ移行タスクのレイテンシが過度に高い場合は、ソースデータベースで DML 操作を実行してレイテンシを更新できます。
説明 データベース全体を移行対象として選択した場合は、ハートビートテーブルを作成できます。ハートビートテーブルは毎秒更新またはデータを受信します。 DTS は、バイナリログファイルの位置を進めるために、スケジュールどおりにソースデータベースで CREATE DATABASE IF NOT EXISTS `test` ステートメントを実行します。
ソースデータベースが Apsara RDS for MySQL インスタンスの場合、次の制限事項に注意してください。 増分データ移行では、読み取り専用の ApsaraDB RDS for MySQL V5.6 インスタンスなど、トランザクションログを記録しない ApsaraDB RDS for MySQL インスタンスをソースデータベースとして使用できません。 DTS は、バイナリログファイルの位置を進めるために、スケジュールどおりにソースデータベースで CREATE DATABASE IF NOT EXISTS `test` ステートメントを実行します。
|