ソースデータベースが MySQL (自己管理 MySQL データベースや RDS for MySQL インスタンスなど) の場合、データ移行タスクを設定する前に、本トピックの注意事項と制限事項をご確認ください。これにより、データ移行タスクが期待どおりに実行されるようになります。
MySQL ソースの移行シナリオの概要
以下の移行シナリオに基づいて、ご利用のデータ移行タスクの注意事項と制限事項をご確認ください：
MySQL データベース間の移行
ターゲットデータベースが MySQL (RDS for MySQL インスタンスや自己管理 MySQL データベースなど) の場合、以下の制限事項にご注意ください：
タイプ | 説明 |
ソースデータベースの制限事項 | 帯域幅要件：ソースデータベースをホストするサーバーには、十分なアウトバウンド帯域幅が必要です。そうでない場合、移行速度に影響が出ます。 移行対象のテーブルには、プライマリキーまたは一意性制約が必要であり、フィールドは一意である必要があります。そうでない場合、ターゲットデータベースに重複データが存在する可能性があります。 テーブルレベルでデータを移行し、列名のマッピングなどテーブルの編集が必要な場合、1 つのデータ移行タスクでサポートされるテーブルは最大 1,000 です。この制限を超えると、タスクの送信後にエラーが報告されます。この場合、テーブルを複数の移行タスクに分割するか、データベース全体を移行するタスクを設定してください。 増分移行を実行する場合、バイナリログに関する以下の点にご注意ください： バイナリログを有効にする必要があります。`binlog_format` パラメーターは `row` に、`binlog_row_image` パラメーターは `full` に設定する必要があります。そうでない場合、事前チェックに失敗し、データ移行タスクを開始できません。
重要 ソースの自己管理 MySQL データベースが、各インスタンスがプライマリであり、もう一方のセカンダリでもあるデュアルプライマリクラスター内にある場合、`log_slave_updates` パラメーターを有効にする必要があります。これにより、Data Transmission Service (DTS) がすべてのバイナリログを取得できるようになります。 RDS for MySQL インスタンスのバイナリログは、少なくとも 3 日間保持する必要があります。7 日間の保持を推奨します。自己管理 MySQL データベースのバイナリログは、少なくとも 7 日間保持する必要があります。そうでない場合、DTS はバイナリログを取得できずに失敗する可能性があります。極端なケースでは、これによりデータの不整合やデータ損失が発生する可能性があります。必要な期間よりも短いバイナリログ保持期間に起因する問題は、DTS のサービスレベルアグリーメント (SLA) の対象外です。
説明 RDS for MySQL インスタンスのバイナリログの [保持期間] を設定する方法の詳細については、「バイナリログを自動的に削除する」をご参照ください。
ソースデータベースの操作に関する制限事項： スキーマ移行および完全データ移行中は、データベースやテーブルのスキーマを変更する DDL 操作を実行しないでください。そうでない場合、データ移行タスクは失敗します。
説明 完全データ移行中、DTS はソースデータベースにクエリを実行します。これによりメタデータロックが作成され、ソースデータベースでの DDL 操作がブロックされる可能性があります。 完全データ移行のみを実行する場合、ソースインスタンスに新しいデータを書き込まないでください。そうでない場合、ソースとターゲット間でデータの不整合が発生します。リアルタイムのデータ整合性を確保するには、スキーマ移行、完全データ移行、増分データ移行を選択してください。
移行中にバイナリログに記録されない操作によるデータ変更は、ターゲットデータベースに移行されません。このような操作の例として、物理バックアップを使用したデータ復旧やカスケード操作があります。
説明 これが発生した場合、ビジネス要件が許すならば、再度完全データ移行を実行できます。 ソースデータベースが MySQL 8.0.23 以降で、移行対象のデータに不可視列が含まれている場合、これらの列のデータは取得できないため、データ損失が発生する可能性があります。
説明 `ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;` コマンドを実行して、不可視列を可視にすることができます。詳細については、「Invisible Columns」をご参照ください。
|
その他の制限事項 | 互換性を確保するために、ソースデータベースとターゲットデータベースで同じ MySQL バージョンを使用することを推奨します。 複数テーブルのマージなど、一時テーブルを使用するオンライン DDL 操作がソースデータベースで実行されると、ターゲットデータベースでデータ損失が発生したり、移行インスタンスが失敗したりする可能性があります。 コメント構文で定義されたパーサーの移行はサポートされていません。 移行中にプライマリキーまたは一意キーの競合が発生した場合： ターゲットデータベースが MySQL 8.0.23 以降で、データを受け取るターゲット列に不可視列が含まれている場合、データ書き込み先のターゲット列が見つからないため、DTS インスタンスが失敗したり、データ損失が発生したりする可能性があります。
説明 `ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;` コマンドを実行して、不可視列を可視にすることができます。詳細については、「Invisible Columns」をご参照ください。 DTS のスキーマ移行機能を使用しない場合、フィールドの互換性を自身で確保する必要があります。そうでない場合、インスタンスが失敗したり、データ損失が発生したりする可能性があります。たとえば、ソーステーブルのフィールドが `text` 型で、ターゲットのフィールドが `varchar(255)` の場合、ソーステーブルにラージオブジェクトが含まれていると、データが切り捨てられる可能性があります。 移行対象のデータに、一般的でない文字や絵文字など、4 バイトストレージを必要とするコンテンツが含まれている場合、データを受け取るターゲットデータベースとテーブルは `utf8mb4` 文字セットを使用する必要があります。
説明 DTS を使用してスキーマ移行を行う場合、ターゲットデータベースのインスタンスレベルのパラメーター `character_set_server` を `utf8mb4` に設定する必要があります。 データ移行の前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。データ移行はオフピーク時に実行することを推奨します。完全データ移行中、DTS はソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースを一部消費するため、データベースの負荷が増加する可能性があります。 完全データ移行には同時 INSERT 操作が含まれるため、ターゲットデータベースでテーブルの断片化が発生します。完全移行が完了すると、ターゲットデータベースのテーブルストレージ領域はソースインスタンスよりも大きくなります。 FLOAT または DOUBLE データ型の列に対する DTS の移行精度がビジネス要件を満たしているか確認してください。DTS は、ROUND(COLUMN,PRECISION) を使用してこれらの列の値を読み取ります。精度が明示的に定義されていない場合、DTS は FLOAT 値を 38 桁の精度で、DOUBLE 値を 308 桁の精度で移行します。 DTS は、過去 7 日以内に失敗したデータ移行タスクの再開を試みます。したがって、ご利用のサービスをターゲットインスタンスに切り替える前に、タスクを終了またはリリースするか、revoke コマンドを使用してターゲットインスタンスに対する DTS アカウントの書き込み権限を取り消す必要があります。そうしないと、タスクが自動的に再開された後、ソースインスタンスのデータがターゲットインスタンスのデータを上書きしてしまいます。 DDL ステートメントがターゲットデータベースへの書き込みに失敗した場合でも、DTS タスクは実行を継続します。タスクログで失敗した DDL ステートメントを確認する必要があります。タスクログの表示方法の詳細については、「タスクログのクエリ」をご参照ください。 大文字と小文字のみが異なる列名を持つフィールドをターゲットの MySQL データベースの同じテーブルに書き込むと、期待どおりの移行結果にならない可能性があります。これは、MySQL データベースの列名が大文字と小文字を区別しないためです。 データ移行が完了し、インスタンスの ステータス が 完了 になったら、analyze table <table_name> コマンドを実行して、すべてのデータが移行先テーブルに書き込まれていることを確認することをお勧めします。たとえば、移行先の MySQL データベースで HA スイッチオーバーがトリガーされた場合、データがメモリにのみ書き込まれ、データ損失が発生する可能性があります。 RDS for MySQL インスタンスで常時暗号化 (EncDB) 機能が有効になっている場合、完全データ移行はサポートされません。
説明 透過的データ暗号化 (TDE) が有効になっている RDS for MySQL インスタンスは、スキーマ移行、完全データ移行、および増分データ移行をサポートします。 ソースデータベースからデータベースアカウントを移行するには、前提条件を満たし、関連する注意事項を理解する必要があります。詳細については、「データベースアカウントの移行」をご参照ください。 インスタンスが失敗した場合、DTS ヘルプデスクは 8 時間以内にインスタンスの復旧を試みます。復旧プロセス中に、インスタンスの再起動やパラメーターの調整などの操作が実行されることがあります。
説明 パラメーターが調整される際、変更されるのは DTS インスタンスのパラメーターのみです。データベース内のパラメーターは変更されません。変更される可能性のあるパラメーターには、「インスタンスパラメーターの変更」で説明されているものが含まれますが、これらに限定されません。
|
特殊なケース | ソースデータベースが自己管理 MySQL データベースの場合： 移行中にソースデータベースでプライマリ/セカンダリの切り替えが発生すると、移行タスクは失敗します。 DTS のレイテンシーは、最後に移行されたデータレコードのタイムスタンプと現在のタイムスタンプを比較して計算されます。ソースデータベースで長期間 DML 操作が実行されない場合、レイテンシー情報が不正確になることがあります。表示されるレイテンシーが高すぎる場合は、ソースデータベースで DML 操作を実行してレイテンシー情報を更新できます。
説明 データベース全体を移行することを選択した場合、ハートビートテーブルを作成することもできます。ハートビートテーブルは 1 秒ごとに更新または書き込みが行われます。 DTS は、ソースデータベースで定期的に `CREATE DATABASE IF NOT EXISTS `test`` コマンドを実行して、バイナリログのオフセットを進めます。 ソースデータベースが Amazon Aurora MySQL インスタンスまたは他のクラスター化された MySQL インスタンスである場合、タスクに設定されたドメイン名または IP アドレスとその解決結果が常に読み取り/書き込み (RW) ノードを指していることを確認してください。そうでない場合、移行タスクが期待どおりに実行されない可能性があります。
ソースデータベースが RDS for MySQL インスタンスの場合： ターゲットデータベースが RDS for MySQL インスタンスの場合： DTS は RDS for MySQL インスタンスにデータベースを自動的に作成します。移行対象のデータベースの名前が RDS for MySQL の命名規則に準拠していない場合は、移行タスクを設定する前に RDS for MySQL インスタンスにデータベースを作成する必要があります。詳細については、「データベースの管理」をご参照ください。
|
MySQL から PolarDB for MySQL への移行
ターゲットデータベースが PolarDB for MySQL の場合、以下の制限事項にご注意ください：
タイプ | 説明 |
ソースデータベースの制限事項 | 帯域幅要件：ソースデータベースをホストするサーバーには、十分なアウトバウンド帯域幅が必要です。そうでない場合、移行速度に影響が出ます。 移行対象のテーブルには、プライマリキーまたは一意性制約が必要であり、フィールドは一意である必要があります。そうでない場合、ターゲットデータベースに重複データが存在する可能性があります。 テーブルレベルでデータを移行し、列名のマッピングなどテーブルの編集が必要な場合、1 つのデータ移行タスクでサポートされるテーブルは最大 1,000 です。この制限を超えると、タスクの送信後にエラーが報告されます。この場合、テーブルを複数の移行タスクに分割するか、データベース全体を移行するタスクを設定してください。 増分移行を実行する場合、バイナリログに関する以下の点にご注意ください： バイナリログを有効にする必要があります。`binlog_format` パラメーターは `row` に、`binlog_row_image` パラメーターは `full` に設定する必要があります。そうでない場合、事前チェックに失敗し、データ移行タスクを開始できません。
重要 ソースの自己管理 MySQL データベースが、各インスタンスがプライマリであり、もう一方のセカンダリでもあるデュアルプライマリクラスター内にある場合、`log_slave_updates` パラメーターを有効にする必要があります。これにより、DTS がすべてのバイナリログを取得できるようになります。 RDS for MySQL インスタンスのバイナリログは、少なくとも 3 日間保持する必要があります。7 日間の保持を推奨します。自己管理 MySQL データベースのバイナリログは、少なくとも 7 日間保持する必要があります。そうでない場合、DTS はバイナリログを取得できずに失敗する可能性があります。極端なケースでは、これによりデータの不整合やデータ損失が発生する可能性があります。必要な期間よりも短いバイナリログ保持期間に起因する問題は、DTS のサービスレベルアグリーメント (SLA) の対象外です。
説明 RDS for MySQL インスタンスのバイナリログの [保持期間] を設定する方法の詳細については、「バイナリログを自動的に削除する」をご参照ください。
ソースデータベースの操作に関する制限事項： スキーマ移行および完全データ移行中は、データベースやテーブルのスキーマを変更する DDL 操作を実行しないでください。そうでない場合、データ移行タスクは失敗します。
説明 完全データ移行中、DTS はソースデータベースにクエリを実行します。これによりメタデータロックが作成され、ソースデータベースでの DDL 操作がブロックされる可能性があります。 完全データ移行のみを実行する場合、ソースインスタンスに新しいデータを書き込まないでください。そうでない場合、ソースとターゲット間でデータの不整合が発生します。リアルタイムのデータ整合性を確保するには、スキーマ移行、完全データ移行、増分データ移行を選択してください。
移行中にバイナリログに記録されない操作によるデータ変更は、ターゲットデータベースに移行されません。このような操作の例として、物理バックアップを使用したデータ復旧やカスケード操作があります。
説明 これが発生した場合、ビジネス要件が許すならば、再度完全データ移行を実行できます。 ソースデータベースが MySQL 8.0.23 以降で、移行対象のデータに不可視列が含まれている場合、これらの列のデータは取得できないため、データ損失が発生する可能性があります。
説明 `ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;` コマンドを実行して、不可視列を可視にすることができます。詳細については、「Invisible Columns」をご参照ください。
|
その他の制限事項 | 互換性を確保するために、ソースデータベースとターゲットデータベースで同じ MySQL バージョンを使用することを推奨します。 複数テーブルのマージなど、一時テーブルを使用するオンライン DDL 操作がソースデータベースで実行されると、ターゲットデータベースでデータ損失が発生したり、移行インスタンスが失敗したりする可能性があります。 コメント構文で定義されたパーサーの移行はサポートされていません。 移行中にプライマリキーまたは一意キーの競合が発生した場合： データ移行の前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。データ移行はオフピーク時に実行することを推奨します。完全データ移行中、DTS はソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースを一部消費するため、データベースの負荷が増加する可能性があります。 完全データ移行には同時 INSERT 操作が含まれるため、ターゲットデータベースでテーブルの断片化が発生します。完全移行が完了すると、ターゲットデータベースのテーブルストレージ領域はソースインスタンスよりも大きくなります。 移行対象のデータに、一般的でない文字や絵文字など、4 バイトストレージを必要とするコンテンツが含まれている場合、データを受け取るターゲットデータベースとテーブルは `utf8mb4` 文字セットを使用する必要があります。
説明 DTS を使用してスキーマ移行を行う場合、ターゲットデータベースのインスタンスレベルのパラメーター `character_set_server` を `utf8mb4` に設定する必要があります。 FLOAT または DOUBLE データ型の列に対する DTS の移行精度がビジネス要件を満たしているか確認してください。DTS は、ROUND(COLUMN,PRECISION) を使用してこれらの列の値を読み取ります。精度が明示的に定義されていない場合、DTS は FLOAT 値を 38 桁の精度で、DOUBLE 値を 308 桁の精度で移行します。 DTS は、過去 7 日以内に失敗したデータ移行タスクの再開を試みます。したがって、ご利用のサービスをターゲットインスタンスに切り替える前に、タスクを終了またはリリースするか、revoke コマンドを使用してターゲットインスタンスに対する DTS アカウントの書き込み権限を取り消す必要があります。そうしないと、タスクが自動的に再開された後、ソースインスタンスのデータがターゲットインスタンスのデータを上書きしてしまいます。 datetime 型のデータを varchar に変換することはサポートされていません。 DDL ステートメントがターゲットデータベースへの書き込みに失敗した場合でも、DTS タスクは実行を継続します。タスクログで失敗した DDL ステートメントを確認する必要があります。タスクログの表示方法の詳細については、「タスクログのクエリ」をご参照ください。 RDS for MySQL インスタンスで常時暗号化 (EncDB) 機能が有効になっている場合、完全データ移行はサポートされません。
説明 透過的データ暗号化 (TDE) が有効になっている RDS for MySQL インスタンスは、スキーマ移行、完全データ移行、および増分データ移行をサポートします。 ソースデータベースからデータベースアカウントを移行するには、前提条件を満たし、関連する注意事項を理解する必要があります。詳細については、「データベースアカウントの移行」をご参照ください。 インスタンスが失敗した場合、DTS ヘルプデスクは 8 時間以内にインスタンスの復旧を試みます。復旧プロセス中に、インスタンスの再起動やパラメーターの調整などの操作が実行されることがあります。
説明 パラメーターが調整される際、変更されるのは DTS インスタンスのパラメーターのみです。データベース内のパラメーターは変更されません。変更される可能性のあるパラメーターには、「インスタンスパラメーターの変更」で説明されているものが含まれますが、これらに限定されません。
|
特殊なケース | |
MySQL から PolarDB-X 2.0 への移行
以下の制限事項にご注意ください：
タイプ | 説明 |
ソースデータベースの制限事項 | 帯域幅要件：ソースデータベースをホストするサーバーには、十分なアウトバウンド帯域幅が必要です。そうでない場合、移行速度に影響が出ます。 移行対象のテーブルには、プライマリキーまたは一意性制約が必要であり、フィールドは一意である必要があります。そうでない場合、ターゲットデータベースに重複データが存在する可能性があります。 テーブルレベルでデータを移行し、列名のマッピングなどテーブルの編集が必要な場合、1 つのデータ移行タスクでサポートされるテーブルは最大 1,000 です。この制限を超えると、タスクの送信後にエラーが報告されます。この場合、テーブルを複数の移行タスクに分割するか、データベース全体を移行するタスクを設定してください。 増分移行を実行する場合、バイナリログに関する以下の点にご注意ください： バイナリログを有効にする必要があります。`binlog_format` パラメーターは `row` に、`binlog_row_image` パラメーターは `full` に設定する必要があります。そうでない場合、事前チェックに失敗し、データ移行タスクを開始できません。
重要 ソースの自己管理 MySQL データベースが、各インスタンスがプライマリであり、もう一方のセカンダリでもあるデュアルプライマリクラスター内にある場合、`log_slave_updates` パラメーターを有効にする必要があります。これにより、DTS がすべてのバイナリログを取得できるようになります。 RDS for MySQL インスタンスのバイナリログは、少なくとも 3 日間保持する必要があります。7 日間の保持を推奨します。自己管理 MySQL データベースのバイナリログは、少なくとも 7 日間保持する必要があります。そうでない場合、DTS はバイナリログを取得できずに失敗する可能性があります。極端なケースでは、これによりデータの不整合やデータ損失が発生する可能性があります。必要な期間よりも短いバイナリログ保持期間に起因する問題は、DTS のサービスレベルアグリーメント (SLA) の対象外です。
説明 RDS for MySQL インスタンスのバイナリログの [保持期間] を設定する方法の詳細については、「バイナリログを自動的に削除する」をご参照ください。
ソースデータベースの操作に関する制限事項： 移行中にバイナリログに記録されない操作によるデータ変更は、ターゲットデータベースに移行されません。このような操作の例として、物理バックアップを使用したデータ復旧やカスケード操作があります。
説明 これが発生した場合、ビジネス要件が許すならば、再度完全データ移行を実行できます。 ソースデータベースが MySQL 8.0.23 以降で、移行対象のデータに不可視列が含まれている場合、これらの列のデータは取得できないため、データ損失が発生する可能性があります。
説明 `ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;` コマンドを実行して、不可視列を可視にすることができます。詳細については、「Invisible Columns」をご参照ください。
|
その他の制限事項 | 移行中にプライマリキーまたは一意キーの競合が発生した場合： 複数テーブルのマージなど、一時テーブルを使用するオンライン DDL 操作がソースデータベースで実行されると、ターゲットデータベースでデータ損失が発生したり、移行インスタンスが失敗したりする可能性があります。 データ移行の前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。データ移行はオフピーク時に実行することを推奨します。完全データ移行中、DTS はソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースを一部消費するため、データベースの負荷が増加する可能性があります。 完全データ移行には同時 INSERT 操作が含まれるため、ターゲットデータベースでテーブルの断片化が発生します。完全移行が完了すると、ターゲットデータベースのテーブルストレージ領域はソースインスタンスよりも大きくなります。 FLOAT または DOUBLE データ型の列に対する DTS の移行精度がビジネス要件を満たしているか確認してください。DTS は、ROUND(COLUMN,PRECISION) を使用してこれらの列の値を読み取ります。精度が明示的に定義されていない場合、DTS は FLOAT 値を 38 桁の精度で、DOUBLE 値を 308 桁の精度で移行します。 DTS は、過去 7 日以内に失敗したデータ移行タスクの再開を試みます。したがって、ご利用のサービスをターゲットインスタンスに切り替える前に、タスクを終了またはリリースするか、revoke コマンドを使用してターゲットインスタンスに対する DTS アカウントの書き込み権限を取り消す必要があります。そうしないと、タスクが自動的に再開された後、ソースインスタンスのデータがターゲットインスタンスのデータを上書きしてしまいます。 RDS for MySQL インスタンスで常時暗号化 (EncDB) 機能が有効になっている場合、完全データ移行はサポートされません。
説明 透過的データ暗号化 (TDE) が有効になっている RDS for MySQL インスタンスは、スキーマ移行、完全データ移行、および増分データ移行をサポートします。 インスタンスが失敗した場合、DTS ヘルプデスクは 8 時間以内にインスタンスの復旧を試みます。復旧プロセス中に、インスタンスの再起動やパラメーターの調整などの操作が実行されることがあります。
説明 パラメーターが調整される際、変更されるのは DTS インスタンスのパラメーターのみです。データベース内のパラメーターは変更されません。変更される可能性のあるパラメーターには、「インスタンスパラメーターの変更」で説明されているものが含まれますが、これらに限定されません。
|
特殊なケース | ソースデータベースが自己管理 MySQL データベースの場合： 移行中にソースデータベースでプライマリ/セカンダリの切り替えが発生すると、移行タスクは失敗します。 DTS のレイテンシーは、最後に移行されたデータレコードのタイムスタンプと現在のタイムスタンプを比較して計算されます。ソースデータベースで長期間 DML 操作が実行されない場合、レイテンシー情報が不正確になることがあります。表示されるレイテンシーが高すぎる場合は、ソースデータベースで DML 操作を実行してレイテンシー情報を更新できます。
説明 データベース全体を移行することを選択した場合、ハートビートテーブルを作成することもできます。ハートビートテーブルは 1 秒ごとに更新または書き込みが行われます。 DTS は、ソースデータベースで定期的に `CREATE DATABASE IF NOT EXISTS `test`` コマンドを実行して、バイナリログのオフセットを進めます。 ソースデータベースが Amazon Aurora MySQL インスタンスまたは他のクラスター化された MySQL インスタンスである場合、タスクに設定されたドメイン名または IP アドレスとその解決結果が常に読み取り/書き込み (RW) ノードを指していることを確認してください。そうでない場合、移行タスクが期待どおりに実行されない可能性があります。
ソースデータベースが RDS for MySQL インスタンスの場合：
|
MySQL から AnalyticDB for MySQL への移行
以下の制限事項にご注意ください：
タイプ | 説明 |
ソースデータベースの制限事項 | 帯域幅要件：ソースデータベースをホストするサーバーには、十分なアウトバウンド帯域幅が必要です。そうでない場合、移行速度に影響が出ます。 移行対象のテーブルには、プライマリキーまたは一意性制約が必要であり、フィールドは一意である必要があります。そうでない場合、ターゲットデータベースに重複データが存在する可能性があります。 テーブルレベルでデータを移行し、列名のマッピングなどテーブルの編集が必要な場合、1 つのデータ移行タスクでサポートされるテーブルは最大 1,000 です。この制限を超えると、タスクの送信後にエラーが報告されます。この場合、テーブルを複数の移行タスクに分割するか、データベース全体を移行するタスクを設定してください。 増分移行を実行する場合、バイナリログに関する以下の点にご注意ください： バイナリログを有効にする必要があります。`binlog_format` パラメーターは `row` に、`binlog_row_image` パラメーターは `full` に設定する必要があります。そうでない場合、事前チェックに失敗し、データ移行タスクを開始できません。
重要 ソースの自己管理 MySQL データベースが、各インスタンスがプライマリであり、もう一方のセカンダリでもあるデュアルプライマリクラスター内にある場合、`log_slave_updates` パラメーターを有効にする必要があります。これにより、DTS がすべてのバイナリログを取得できるようになります。 RDS for MySQL インスタンスのバイナリログは、少なくとも 3 日間保持する必要があります。7 日間の保持を推奨します。自己管理 MySQL データベースのバイナリログは、少なくとも 7 日間保持する必要があります。そうでない場合、DTS はバイナリログを取得できずに失敗する可能性があります。極端なケースでは、これによりデータの不整合やデータ損失が発生する可能性があります。必要な期間よりも短いバイナリログ保持期間に起因する問題は、DTS のサービスレベルアグリーメント (SLA) の対象外です。
説明 RDS for MySQL インスタンスのバイナリログの [保持期間] を設定する方法の詳細については、「バイナリログを自動的に削除する」をご参照ください。
ソースデータベースの操作に関する制限事項： スキーマ移行および完全データ移行中は、データベースやテーブルのスキーマを変更する DDL 操作を実行しないでください。そうでない場合、データ移行タスクは失敗します。
説明 完全データ移行中、DTS はソースデータベースにクエリを実行します。これによりメタデータロックが作成され、ソースデータベースでの DDL 操作がブロックされる可能性があります。 移行中に、ALTER TABLE table_name COMMENT='Table comment'; のようなコメントを追加する DDL 操作を実行しないでください。そうでない場合、データ移行タスクは失敗します。 完全データ移行のみを実行する場合、ソースインスタンスに新しいデータを書き込まないでください。そうでない場合、ソースとターゲット間でデータの不整合が発生します。リアルタイムのデータ整合性を確保するには、スキーマ移行、完全データ移行、増分データ移行を選択してください。
移行中にバイナリログに記録されない操作によるデータ変更は、ターゲットデータベースに移行されません。このような操作の例として、物理バックアップを使用したデータ復旧やカスケード操作があります。
説明 これが発生した場合、ビジネス要件が許すならば、再度完全データ移行を実行できます。 ソースデータベースが MySQL 8.0.23 以降で、移行対象のデータに不可視列が含まれている場合、これらの列のデータは取得できないため、データ損失が発生する可能性があります。
説明 `ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;` コマンドを実行して、不可視列を可視にすることができます。詳細については、「Invisible Columns」をご参照ください。
|
その他の制限事項 | プレフィックスインデックスの移行はサポートされていません。ソースデータベースにプレフィックスインデックスがある場合、データ移行が失敗する可能性があります。 INDEX、PARTITION、VIEW、PROCEDURE、FUNCTION、TRIGGER、FK の移行はサポートされていません。 複数テーブルのマージなど、一時テーブルを使用するオンライン DDL 操作がソースデータベースで実行されると、ターゲットデータベースでデータ損失が発生したり、移行インスタンスが失敗したりする可能性があります。 移行中にプライマリキーまたは一意キーの競合が発生した場合： ターゲットデータベースにカスタムプライマリキーがあるか、またはテーブル・列設定 ステップでプライマリキー列の追加を設定する必要があります。そうでない場合、データ移行が失敗する可能性があります。 AnalyticDB for MySQL の制限により、AnalyticDB for MySQL クラスター内のノードのディスク領域使用率が 80% を超えると、DTS タスクは異常になり、レイテンシーが発生します。移行オブジェクトに必要な領域を事前に見積もり、ターゲットクラスターに十分なストレージ領域があることを確認してください。 DTS タスクの実行中にターゲットの AnalyticDB for MySQL 3.0 クラスターがバックアップされている場合、タスクは失敗します。 データ移行の前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。データ移行はオフピーク時に実行することを推奨します。完全データ移行中、DTS はソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースを一部消費するため、データベースの負荷が増加する可能性があります。 完全データ移行には同時 INSERT 操作が含まれるため、ターゲットデータベースでテーブルの断片化が発生します。完全移行が完了すると、ターゲットデータベースのテーブルストレージ領域はソースインスタンスよりも大きくなります。 FLOAT または DOUBLE データ型の列に対する DTS の移行精度がビジネス要件を満たしているか確認してください。DTS は、ROUND(COLUMN,PRECISION) を使用してこれらの列の値を読み取ります。精度が明示的に定義されていない場合、DTS は FLOAT 値を 38 桁の精度で、DOUBLE 値を 308 桁の精度で移行します。 DTS は、過去 7 日以内に失敗したデータ移行タスクの再開を試みます。したがって、ご利用のサービスをターゲットインスタンスに切り替える前に、タスクを終了またはリリースするか、revoke コマンドを使用してターゲットインスタンスに対する DTS アカウントの書き込み権限を取り消す必要があります。そうしないと、タスクが自動的に再開された後、ソースインスタンスのデータがターゲットインスタンスのデータを上書きしてしまいます。 DDL ステートメントがターゲットデータベースへの書き込みに失敗した場合でも、DTS タスクは実行を継続します。タスクログで失敗した DDL ステートメントを確認する必要があります。タスクログの表示方法の詳細については、「タスクログのクエリ」をご参照ください。 RDS for MySQL インスタンスで常時暗号化 (EncDB) 機能が有効になっている場合、完全データ移行はサポートされません。
説明 透過的データ暗号化 (TDE) が有効になっている RDS for MySQL インスタンスは、スキーマ移行、完全データ移行、および増分データ移行をサポートします。 インスタンスが失敗した場合、DTS ヘルプデスクは 8 時間以内にインスタンスの復旧を試みます。復旧プロセス中に、インスタンスの再起動やパラメーターの調整などの操作が実行されることがあります。
説明 パラメーターが調整される際、変更されるのは DTS インスタンスのパラメーターのみです。データベース内のパラメーターは変更されません。変更される可能性のあるパラメーターには、「インスタンスパラメーターの変更」で説明されているものが含まれますが、これらに限定されません。
|
特殊なケース | ソースデータベースが自己管理 MySQL データベースの場合： 移行中にソースデータベースでプライマリ/セカンダリの切り替えが発生すると、移行タスクは失敗します。 DTS のレイテンシーは、最後に移行されたデータレコードのタイムスタンプと現在のタイムスタンプを比較して計算されます。ソースデータベースで長期間 DML 操作が実行されない場合、レイテンシー情報が不正確になることがあります。表示されるレイテンシーが高すぎる場合は、ソースデータベースで DML 操作を実行してレイテンシー情報を更新できます。
説明 データベース全体を移行することを選択した場合、ハートビートテーブルを作成することもできます。ハートビートテーブルは 1 秒ごとに更新または書き込みが行われます。 DTS は、ソースデータベースで定期的に `CREATE DATABASE IF NOT EXISTS `test`` コマンドを実行して、バイナリログのオフセットを進めます。 ソースデータベースが Amazon Aurora MySQL インスタンスまたは他のクラスター化された MySQL インスタンスである場合、タスクに設定されたドメイン名または IP アドレスとその解決結果が常に読み取り/書き込み (RW) ノードを指していることを確認してください。そうでない場合、移行タスクが期待どおりに実行されない可能性があります。
ソースデータベースが RDS for MySQL インスタンスの場合：
|
MySQL から自己管理型 Kafka クラスターへの移行
以下の制限事項にご注意ください：
タイプ | 説明 |
ソースデータベースの制限事項 | 帯域幅要件：ソースデータベースをホストするサーバーには、十分なアウトバウンド帯域幅が必要です。そうでない場合、移行速度に影響が出ます。 移行対象のテーブルには、プライマリキーまたは一意性制約が必要であり、フィールドは一意である必要があります。そうでない場合、ターゲットデータベースに重複データが存在する可能性があります。 テーブルレベルでデータを移行し、列名のマッピングなどテーブルの編集が必要な場合、1 つのデータ移行タスクでサポートされるテーブルは最大 1,000 です。この制限を超えると、タスクの送信後にエラーが報告されます。この場合、テーブルを複数の移行タスクに分割するか、データベース全体を移行するタスクを設定してください。 増分移行を実行する場合、バイナリログに関する以下の点にご注意ください： バイナリログを有効にする必要があります。`binlog_format` パラメーターは `row` に、`binlog_row_image` パラメーターは `full` に設定する必要があります。そうでない場合、事前チェックに失敗し、データ移行タスクを開始できません。
重要 ソースの自己管理 MySQL データベースが、各インスタンスがプライマリであり、もう一方のセカンダリでもあるデュアルプライマリクラスター内にある場合、`log_slave_updates` パラメーターを有効にする必要があります。これにより、DTS がすべてのバイナリログを取得できるようになります。 RDS for MySQL インスタンスのバイナリログは、少なくとも 3 日間保持する必要があります。7 日間の保持を推奨します。自己管理 MySQL データベースのバイナリログは、少なくとも 7 日間保持する必要があります。そうでない場合、DTS はバイナリログを取得できずに失敗する可能性があります。極端なケースでは、これによりデータの不整合やデータ損失が発生する可能性があります。必要な期間よりも短いバイナリログ保持期間に起因する問題は、DTS のサービスレベルアグリーメント (SLA) の対象外です。
説明 RDS for MySQL インスタンスのバイナリログの [保持期間] を設定する方法の詳細については、「バイナリログを自動的に削除する」をご参照ください。
ソースデータベースの操作に関する制限事項： スキーマ移行および完全データ移行中は、データベースやテーブルのスキーマを変更する DDL 操作を実行しないでください。そうでない場合、データ移行タスクは失敗します。
説明 完全データ移行中、DTS はソースデータベースにクエリを実行します。これによりメタデータロックが作成され、ソースデータベースでの DDL 操作がブロックされる可能性があります。 完全データ移行のみを実行する場合、ソースインスタンスに新しいデータを書き込まないでください。そうでない場合、ソースとターゲット間でデータの不整合が発生します。リアルタイムのデータ整合性を確保するには、スキーマ移行、完全データ移行、増分データ移行を選択してください。
移行中にバイナリログに記録されない操作によるデータ変更は、ターゲットデータベースに移行されません。このような操作の例として、物理バックアップを使用したデータ復旧やカスケード操作があります。
説明 これが発生した場合、ビジネス要件が許すならば、再度完全データ移行を実行できます。 ソースデータベースが MySQL 8.0.23 以降で、移行対象のデータに不可視列が含まれている場合、これらの列のデータは取得できないため、データ損失が発生する可能性があります。
説明 `ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;` コマンドを実行して、不可視列を可視にすることができます。詳細については、「Invisible Columns」をご参照ください。
|
その他の制限事項 | データテーブルのみ移行できます。 INDEX、PARTITION、VIEW、PROCEDURE、FUNCTION、TRIGGER、FK の移行はサポートされていません。 データ移行の前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。データ移行はオフピーク時に実行することを推奨します。完全データ移行中、DTS はソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースを一部消費するため、データベースの負荷が増加する可能性があります。 完全データ移行には同時 INSERT 操作が含まれるため、ターゲットデータベースでテーブルの断片化が発生します。完全移行が完了すると、ターゲットデータベースのテーブルストレージ領域はソースインスタンスよりも大きくなります。 FLOAT または DOUBLE データ型の列に対する DTS の移行精度がビジネス要件を満たしているか確認してください。DTS は、ROUND(COLUMN,PRECISION) を使用してこれらの列の値を読み取ります。精度が明示的に定義されていない場合、DTS は FLOAT 値を 38 桁の精度で、DOUBLE 値を 308 桁の精度で移行します。 DTS は、過去 7 日以内に失敗したデータ移行タスクの再開を試みます。したがって、ご利用のサービスをターゲットインスタンスに切り替える前に、タスクを終了またはリリースするか、revoke コマンドを使用してターゲットインスタンスに対する DTS アカウントの書き込み権限を取り消す必要があります。そうしないと、タスクが自動的に再開された後、ソースインスタンスのデータがターゲットインスタンスのデータを上書きしてしまいます。 DTS 以外のソースからターゲットデータベースにデータを書き込まないでください。そうしないと、ソースデータベースとターゲットデータベースの間でデータの不整合が発生します。 移行中に、ターゲットの Kafka クラスターがスケールアウトまたはスケールインされた場合、インスタンスを再起動する必要があります。 RDS for MySQL インスタンスで常時暗号化 (EncDB) 機能が有効になっている場合、完全データ移行はサポートされません。
説明 透過的データ暗号化 (TDE) が有効になっている RDS for MySQL インスタンスは、スキーマ移行、完全データ移行、および増分データ移行をサポートします。 インスタンスが失敗した場合、DTS ヘルプデスクは 8 時間以内にインスタンスの復旧を試みます。復旧プロセス中に、インスタンスの再起動やパラメーターの調整などの操作が実行されることがあります。
説明 パラメーターが調整される際、変更されるのは DTS インスタンスのパラメーターのみです。データベース内のパラメーターは変更されません。変更される可能性のあるパラメーターには、「インスタンスパラメーターの変更」で説明されているものが含まれますが、これらに限定されません。
|
特殊なケース | ソースデータベースが自己管理 MySQL データベースの場合： 移行中にソースデータベースでプライマリ/セカンダリの切り替えが発生すると、移行タスクは失敗します。 DTS のレイテンシーは、最後に移行されたデータレコードのタイムスタンプと現在のタイムスタンプを比較して計算されます。ソースデータベースで長期間 DML 操作が実行されない場合、レイテンシー情報が不正確になることがあります。表示されるレイテンシーが高すぎる場合は、ソースデータベースで DML 操作を実行してレイテンシー情報を更新できます。
説明 データベース全体を移行することを選択した場合、ハートビートテーブルを作成することもできます。ハートビートテーブルは 1 秒ごとに更新または書き込みが行われます。 DTS は、ソースデータベースで定期的に `CREATE DATABASE IF NOT EXISTS `test`` コマンドを実行して、バイナリログのオフセットを進めます。 ソースデータベースが Amazon Aurora MySQL インスタンスまたは他のクラスター化された MySQL インスタンスである場合、タスクに設定されたドメイン名または IP アドレスとその解決結果が常に読み取り/書き込み (RW) ノードを指していることを確認してください。そうでない場合、移行タスクが期待どおりに実行されない可能性があります。
ソースデータベースが RDS for MySQL インスタンスの場合：
|
MySQL から DataHub への移行
以下の制限事項にご注意ください：
タイプ | 説明 |
ソースデータベースの制限事項 | 帯域幅要件：ソースデータベースをホストするサーバーには、十分なアウトバウンド帯域幅が必要です。そうでない場合、移行速度に影響が出ます。 移行対象のテーブルには、プライマリキーまたは一意性制約が必要であり、フィールドは一意である必要があります。そうでない場合、ターゲットデータベースに重複データが存在する可能性があります。 テーブルレベルでデータを移行し、列名のマッピングなどテーブルの編集が必要な場合、1 つのデータ移行タスクでサポートされるテーブルは最大 1,000 です。この制限を超えると、タスクの送信後にエラーが報告されます。この場合、テーブルを複数の移行タスクに分割するか、データベース全体を移行するタスクを設定してください。 増分移行を実行する場合、バイナリログに関する以下の点にご注意ください： バイナリログを有効にする必要があります。`binlog_format` パラメーターは `row` に、`binlog_row_image` パラメーターは `full` に設定する必要があります。そうでない場合、事前チェックに失敗し、データ移行タスクを開始できません。
重要 ソースの自己管理 MySQL データベースが、各インスタンスがプライマリであり、もう一方のセカンダリでもあるデュアルプライマリクラスター内にある場合、`log_slave_updates` パラメーターを有効にする必要があります。これにより、DTS がすべてのバイナリログを取得できるようになります。 RDS for MySQL インスタンスのバイナリログは、少なくとも 3 日間保持する必要があります。7 日間の保持を推奨します。自己管理 MySQL データベースのバイナリログは、少なくとも 7 日間保持する必要があります。そうでない場合、DTS はバイナリログを取得できずに失敗する可能性があります。極端なケースでは、これによりデータの不整合やデータ損失が発生する可能性があります。必要な期間よりも短いバイナリログ保持期間に起因する問題は、DTS のサービスレベルアグリーメント (SLA) の対象外です。
説明 RDS for MySQL インスタンスのバイナリログの [保持期間] を設定する方法の詳細については、「バイナリログを自動的に削除する」をご参照ください。
スキーマ移行フェーズ中にデータベースまたはテーブルのスキーマを変更する DDL 操作を実行すると、データ移行タスクは失敗します。 移行中にバイナリログに記録されない操作によるデータ変更は、ターゲットデータベースに移行されません。このような操作の例として、物理バックアップを使用したデータ復旧やカスケード操作があります。
説明 これが発生した場合、ビジネス要件が許すならば、再度完全データ移行を実行できます。 ソースデータベースが MySQL 8.0.23 以降で、移行対象のデータに不可視列が含まれている場合、これらの列のデータは取得できないため、データ損失が発生する可能性があります。
説明 `ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;` コマンドを実行して、不可視列を可視にすることができます。詳細については、「Invisible Columns」をご参照ください。
|
その他の制限事項 | テーブルレベルの移行のみがサポートされています。 INDEX、PARTITION、VIEW、PROCEDURE、FUNCTION、TRIGGER、FK の移行はサポートされていません。 ターゲットの DataHub の単一の String フィールドの最大長は 2 MB です。 pt-online-schema-change などのツールを使用して、ソースデータベースの移行オブジェクトに対してオンライン DDL 操作を実行しないでください。そうしないと、移行は失敗します。 Data Management (DMS) を使用してオンライン DDL 操作を実行できます。詳細については、「テーブルをロックせずにスキーマ変更を実行する」をご参照ください。
警告 DTS 以外のソースからターゲットデータベースにデータが書き込まれる場合、DMS を使用してオンライン DDL 操作を実行しないでください。そうしないと、ターゲットデータベースでデータ損失が発生する可能性があります。 FLOAT または DOUBLE データ型の列に対する DTS の移行精度がビジネス要件を満たしているか確認してください。DTS は、ROUND(COLUMN,PRECISION) を使用してこれらの列の値を読み取ります。精度が明示的に定義されていない場合、DTS は FLOAT 値を 38 桁の精度で、DOUBLE 値を 308 桁の精度で移行します。 DTS は、過去 7 日以内に失敗したデータ移行タスクの再開を試みます。したがって、ご利用のサービスをターゲットインスタンスに切り替える前に、タスクを終了またはリリースするか、revoke コマンドを使用してターゲットインスタンスに対する DTS アカウントの書き込み権限を取り消す必要があります。そうしないと、タスクが自動的に再開された後、ソースインスタンスのデータがターゲットインスタンスのデータを上書きしてしまいます。 RDS for MySQL インスタンスで常時暗号化 (EncDB) 機能が有効になっている場合、完全データ移行はサポートされません。
説明 透過的データ暗号化 (TDE) が有効になっている RDS for MySQL インスタンスは、スキーマ移行、完全データ移行、および増分データ移行をサポートします。 インスタンスが失敗した場合、DTS ヘルプデスクは 8 時間以内にインスタンスの復旧を試みます。復旧プロセス中に、インスタンスの再起動やパラメーターの調整などの操作が実行されることがあります。
説明 パラメーターが調整される際、変更されるのは DTS インスタンスのパラメーターのみです。データベース内のパラメーターは変更されません。変更される可能性のあるパラメーターには、「インスタンスパラメーターの変更」で説明されているものが含まれますが、これらに限定されません。
|
特殊なケース | ソースデータベースが自己管理 MySQL データベースの場合： 移行中にソースデータベースでプライマリ/セカンダリの切り替えが発生すると、移行タスクは失敗します。 DTS のレイテンシーは、最後に移行されたデータレコードのタイムスタンプと現在のタイムスタンプを比較して計算されます。ソースデータベースで長期間 DML 操作が実行されない場合、レイテンシー情報が不正確になることがあります。表示されるレイテンシーが高すぎる場合は、ソースデータベースで DML 操作を実行してレイテンシー情報を更新できます。
説明 データベース全体を移行することを選択した場合、ハートビートテーブルを作成することもできます。ハートビートテーブルは 1 秒ごとに更新または書き込みが行われます。 DTS は、ソースデータベースで定期的に `CREATE DATABASE IF NOT EXISTS `test`` コマンドを実行して、バイナリログのオフセットを進めます。 ソースデータベースが Amazon Aurora MySQL インスタンスまたは他のクラスター化された MySQL インスタンスである場合、タスクに設定されたドメイン名または IP アドレスとその解決結果が常に読み取り/書き込み (RW) ノードを指していることを確認してください。そうでない場合、移行タスクが期待どおりに実行されない可能性があります。
ソースデータベースが RDS for MySQL インスタンスの場合：
|