ソースデータベースが MySQL（例：自己管理 MySQL データベースまたは ApsaraDB RDS for MySQL）の場合、データ移行タスクを設定する前に、これらの考慮事項および制限事項を確認してください。これにより、タスクの正常な実行を確保できます。
MySQL ソース向けの移行ソリューション
各移行ソリューションの考慮事項および制限事項をご確認ください。
MySQL データベース間の移行
ターゲットデータベースが MySQL（例：ApsaraDB RDS for MySQL または自己管理 MySQL データベース）の場合、以下の考慮事項および制限事項をご確認ください。
|
種別
|
説明
|
|
ソースデータベースの制限事項
|
-
帯域幅要件：ソースデータベースをホストするサーバーは、十分なアウトバウンド帯域幅を備えている必要があります。そうでない場合、移行速度が低下します。
-
移行対象となる各テーブルには、プライマリキーまたは一意制約が必要であり、キー列には一意の値が含まれている必要があります。そうでない場合、ターゲットデータベースに重複レコードが発生する可能性があります。
-
テーブルを移行対象として選択し、列名のマッピングなどの編集を行う場合、単一の移行タスクでは最大 1,000 個のテーブルをサポートします。この上限を超えると、タスクの送信時にエラーが発生して失敗します。この問題を解決するには、テーブルを複数のタスクに分割するか、完全データベース移行タスクを設定してください。
-
増分移行を実行する場合は、バイナリログを有効化してください。
-
binlog_format を ROW に、binlog_row_image を FULL に設定してください。設定されていない場合、事前チェックに失敗し、タスクを開始できません。
重要
自己管理 MySQL ソースがデュアルマスターコンフィグレーション（各インスタンスがマスターおよびスレーブの両方として機能）である場合、log_slave_updates パラメーターを有効化してください。これにより、DTS がすべてのバイナリログを読み取れるようになります。
-
RDS for MySQL インスタンスの場合、ローカルバイナリログの保存期間は最低 3 日間（推奨：7 日間）にしてください。自己管理 MySQL データベースの場合、ローカルバイナリログの保存期間は最低 7 日間にしてください。DTS がバイナリログにアクセスできない場合、タスクは失敗します。最悪の場合、データの不整合やデータ損失が発生する可能性があります。DTS の要件よりも短いバイナリログ保存期間が原因で発生した問題は、DTS の SLA の対象外となります。
説明
RDS for MySQL インスタンスにおけるローカルバイナリログの 保存期間 を設定する方法については、「ローカルログの自動削除」をご参照ください。
-
ソースデータベースで実行できない操作：
-
スキーマ移行または完全移行中に、データベースまたはテーブルのスキーマを変更する DDL 操作を実行しないでください。実行した場合、移行タスクが失敗します。
説明
完全移行中、DTS はソースデータベースに対してクエリを実行します。これによりメタデータロックが発生し、ソースデータベースでの DDL 操作がブロックされる可能性があります。
-
完全移行のみを実行する場合、ソースインスタンスに新しいデータを書き込まないでください。書き込んだ場合、ソースとターゲットのデータが不整合になります。リアルタイムでデータの一貫性を保つには、スキーマ移行、完全移行、および増分移行を選択してください。
-
DTS は、バイナリログに書き込まれない変更によって生成されたデータ（例：物理バックアップから復元されたデータ、カスケード操作によって作成されたデータなど）を移行しません。
説明
このような状況が発生した場合、業務許容範囲内で完全移行を再実行してください。
-
ソース MySQL データベースのバージョンが 8.0.23 以降であり、非表示の隠し列が含まれている場合、DTS はその列を読み取れません。これにより、データ損失が発生する可能性があります。
説明
隠し列を可視化するには、ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; を実行してください。詳細については、「Invisible Columns」をご参照ください。
|
|
その他の制限事項
|
-
互換性を確保するため、ソースおよびターゲットのデータベースで同じ MySQL バージョンを使用することを推奨します。
-
ソースデータベースで、オンライン DDL 操作（マルチテーブルマージなどのシナリオを含む）のテンポラリテーブルモードを使用している場合、または一意キー列に機能ベースのインデックスを追加している場合、ターゲットデータベースでデータ損失またはタスク失敗が発生する可能性があります。
-
DTS は、コメント構文を使用して定義されたパーサの移行をサポートしていません。
-
移行中にプライマリキーまたは一意キーの競合が発生した場合：
-
ターゲット 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 に設定してください。
-
移行を実行する前に、ソースおよびターゲットのデータベースのパフォーマンスを評価してください。移行は業務の閑散時間帯に実行してください。そうでない場合、完全移行が両方のデータベースの読み取りおよび書き込みリソースを消費し、データベース負荷が増加します。
-
完全移行では INSERT 操作が同時実行されます。これにより、ターゲットテーブルが断片化されます。完全移行後、ターゲットテーブルはソーステーブルよりも多くのストレージ領域を必要とします。
-
FLOAT または DOUBLE 列に対する DTS の移行精度が、お客様のビジネス要件を満たすことを確認してください。DTS はこれらの列を ROUND(COLUMN,PRECISION) を使用して読み取ります。精度が指定されていない場合、FLOAT には 38 桁、DOUBLE には 308 桁が使用されます。
-
DTS は、失敗したタスクを 7 日間以内に回復しようと試みます。トラフィックをターゲットインスタンスに切り替える前に、タスクを終了またはリリースしてください。または、revoke コマンドを実行して、DTS のターゲットインスタンスアカウントに対する書き込み権限を削除してください。これにより、自動回復によるターゲットデータへのソースデータの上書きを防止できます。
-
DDL 書き込みがターゲットデータベースで失敗した場合、DTS タスクは継続して実行されます。失敗した DDL 文はタスクログで確認できます。手順については、「タスクログの表示」をご参照ください。
-
ターゲット MySQL データベースの同一テーブルに、大文字小文字が異なる同名の列を書き込むと、予期しない結果が発生する可能性があります。MySQL の列名は大文字小文字を区別しません。
-
移行が完了した後（タスクステータスが ステータス から 完了 に変更された後）、analyze table <table_name> を実行して、すべてのデータがターゲットテーブルに書き込まれたことを確認してください。たとえば、ターゲット MySQL データベースで高可用性（HA）スイッチオーバーが発生した場合、データがメモリ内に留まり、ディスクに書き込まれないままになることがあり、データ損失を引き起こす可能性があります。
-
RDS for MySQL インスタンスで Always-Encrypted が有効になっている場合、完全移行はサポートされていません。
説明
透過的データ暗号化（TDE）が有効になっている RDS for MySQL インスタンスは、スキーマ移行、完全移行、および増分移行をサポートしています。
-
データベースアカウントをソースから移行するには、必要な前提条件を満たし、関連する考慮事項を確認してください。詳細については、「データベースアカウントの移行」をご参照ください。
-
タスクが失敗した場合、DTS サポートスタッフが 8 時間以内に復旧を試みます。復旧中、タスクを再起動したり、パラメーターを調整したりすることがあります。
説明
データベースパラメーターではなく、DTS タスクパラメーターのみが変更されます。 調整可能なパラメーターについては、「インスタンスパラメーターの変更」をご参照ください。
|
|
特殊ケース
|
|
MySQL から PolarDB for MySQL への移行
ターゲットデータベースが PolarDB for MySQL の場合、以下の考慮事項および制限事項をご確認ください。
|
種別
|
説明
|
|
ソースデータベースの制限事項
|
-
帯域幅要件：ソースデータベースをホストするサーバーは、十分なアウトバウンド帯域幅を備えている必要があります。そうでない場合、移行速度が低下します。
-
移行対象となる各テーブルには、プライマリキーまたは一意制約が必要であり、キー列には一意の値が含まれている必要があります。そうでない場合、ターゲットデータベースに重複レコードが発生する可能性があります。
-
テーブルを移行対象として選択し、列名のマッピングなどの編集を行う場合、単一の移行タスクでは最大 1,000 個のテーブルをサポートします。この上限を超えると、タスクの送信時にエラーが発生して失敗します。この問題を解決するには、テーブルを複数のタスクに分割するか、完全データベース移行タスクを設定してください。
-
増分移行を実行する場合は、バイナリログを有効化してください。
-
binlog_format を ROW に、binlog_row_image を FULL に設定してください。設定されていない場合、事前チェックに失敗し、タスクを開始できません。
重要
自己管理 MySQL ソースがデュアルマスターコンフィグレーション（各インスタンスがマスターおよびスレーブの両方として機能）である場合、log_slave_updates パラメーターを有効化してください。これにより、DTS がすべてのバイナリログを読み取れるようになります。
-
RDS for MySQL インスタンスの場合、ローカルバイナリログの保存期間は最低 3 日間（推奨：7 日間）にしてください。自己管理 MySQL データベースの場合、ローカルバイナリログの保存期間は最低 7 日間にしてください。DTS がバイナリログにアクセスできない場合、タスクは失敗します。最悪の場合、データの不整合やデータ損失が発生する可能性があります。DTS の要件よりも短いバイナリログ保存期間が原因で発生した問題は、DTS の SLA の対象外となります。
説明
RDS for MySQL インスタンスにおけるローカルバイナリログの 保存期間 を設定する方法については、「ローカルログの自動削除」をご参照ください。
-
ソースデータベースで実行できない操作：
-
スキーマ移行または完全移行中に、データベースまたはテーブルのスキーマを変更する DDL 操作を実行しないでください。実行した場合、移行タスクが失敗します。
説明
完全移行中、DTS はソースデータベースに対してクエリを実行します。これによりメタデータロックが発生し、ソースデータベースでの DDL 操作がブロックされる可能性があります。
-
完全移行のみを実行する場合、ソースインスタンスに新しいデータを書き込まないでください。書き込んだ場合、ソースとターゲットのデータが不整合になります。リアルタイムでデータの一貫性を保つには、スキーマ移行、完全移行、および増分移行を選択してください。
-
DTS は、バイナリログに書き込まれない変更によって生成されたデータ（例：物理バックアップから復元されたデータ、カスケード操作によって作成されたデータなど）を移行しません。
説明
このような状況が発生した場合、業務許容範囲内で完全移行を再実行してください。
-
ソース MySQL データベースのバージョンが 8.0.23 以降であり、非表示の隠し列が含まれている場合、DTS はその列を読み取れません。これにより、データ損失が発生する可能性があります。
説明
隠し列を可視化するには、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) を使用して読み取ります。精度が指定されていない場合、FLOAT には 38 桁、DOUBLE には 308 桁が使用されます。
-
DTS は、失敗したタスクを 7 日間以内に回復しようと試みます。トラフィックをターゲットインスタンスに切り替える前に、タスクを終了またはリリースしてください。または、revoke コマンドを実行して、DTS のターゲットインスタンスアカウントに対する書き込み権限を削除してください。これにより、自動回復によるターゲットデータへのソースデータの上書きを防止できます。
-
DTS は、datetime データを varchar に変換することをサポートしていません。
-
DDL 書き込みがターゲットデータベースで失敗した場合、DTS タスクは継続して実行されます。失敗した DDL 文はタスクログで確認できます。手順については、「タスクログの表示」をご参照ください。
-
RDS for MySQL インスタンスで Always-Encrypted が有効になっている場合、完全移行はサポートされていません。
説明
透過的データ暗号化（TDE）が有効になっている RDS for MySQL インスタンスは、スキーマ移行、完全移行、および増分移行をサポートしています。
-
データベースアカウントをソースから移行するには、必要な前提条件を満たし、関連する考慮事項を確認してください。詳細については、「データベースアカウントの移行」をご参照ください。
-
タスクが失敗した場合、DTS サポートスタッフが 8 時間以内に復旧を試みます。復旧中、タスクを再起動したり、パラメーターを調整したりすることがあります。
説明
データベースパラメーターではなく、DTS タスクパラメーターのみが変更されます。 調整可能なパラメーターについては、「インスタンスパラメーターの変更」をご参照ください。
|
|
特殊ケース
|
|
MySQL から PolarDB-X 2.0 への移行
以下の考慮事項および制限事項をご確認ください。
|
種別
|
説明
|
|
ソースデータベースの制限事項
|
-
帯域幅要件：ソースデータベースをホストするサーバーは、十分なアウトバウンド帯域幅を備えている必要があります。そうでない場合、移行速度が低下します。
-
移行対象となる各テーブルには、プライマリキーまたは一意制約が必要であり、キー列には一意の値が含まれている必要があります。そうでない場合、ターゲットデータベースに重複レコードが発生する可能性があります。
-
テーブルを移行対象として選択し、列名のマッピングなどの編集を行う場合、単一の移行タスクでは最大 1,000 個のテーブルをサポートします。この上限を超えると、タスクの送信時にエラーが発生して失敗します。この問題を解決するには、テーブルを複数のタスクに分割するか、完全データベース移行タスクを設定してください。
-
増分移行を実行する場合は、バイナリログを有効化してください。
-
binlog_format を ROW に、binlog_row_image を FULL に設定してください。設定されていない場合、事前チェックに失敗し、タスクを開始できません。
重要
自己管理 MySQL ソースがデュアルマスターコンフィグレーション（各インスタンスがマスターおよびスレーブの両方として機能）である場合、log_slave_updates パラメーターを有効化してください。これにより、DTS がすべてのバイナリログを読み取れるようになります。
-
RDS for MySQL インスタンスの場合、ローカルバイナリログの保存期間は最低 3 日間（推奨：7 日間）にしてください。自己管理 MySQL データベースの場合、ローカルバイナリログの保存期間は最低 7 日間にしてください。DTS がバイナリログにアクセスできない場合、タスクは失敗します。最悪の場合、データの不整合やデータ損失が発生する可能性があります。DTS の要件よりも短いバイナリログ保存期間が原因で発生した問題は、DTS の SLA の対象外となります。
説明
RDS for MySQL インスタンスにおけるローカルバイナリログの 保存期間 を設定する方法については、「ローカルログの自動削除」をご参照ください。
-
ソースデータベースで実行できない操作：
-
DTS は、バイナリログに書き込まれない変更によって生成されたデータ（例：物理バックアップから復元されたデータ、カスケード操作によって作成されたデータなど）を移行しません。
説明
このような状況が発生した場合、業務許容範囲内で完全移行を再実行してください。
-
ソース MySQL データベースのバージョンが 8.0.23 以降であり、非表示の隠し列が含まれている場合、DTS はその列を読み取れません。これにより、データ損失が発生する可能性があります。
説明
隠し列を可視化するには、ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; を実行してください。詳細については、「Invisible Columns」をご参照ください。
|
|
その他の制限事項
|
-
移行中にプライマリキーまたは一意キーの競合が発生した場合：
-
ソースデータベースで、オンライン DDL 操作（マルチテーブルマージなどのシナリオを含む）のテンポラリテーブルモードを使用している場合、または一意キー列に機能ベースのインデックスを追加している場合、ターゲットデータベースでデータ損失またはタスク失敗が発生する可能性があります。
-
移行を実行する前に、ソースおよびターゲットのデータベースのパフォーマンスを評価してください。移行は業務の閑散時間帯に実行してください。そうでない場合、完全移行が両方のデータベースの読み取りおよび書き込みリソースを消費し、データベース負荷が増加します。
-
完全移行では INSERT 操作が同時実行されます。これにより、ターゲットテーブルが断片化されます。完全移行後、ターゲットテーブルはソーステーブルよりも多くのストレージ領域を必要とします。
-
FLOAT または DOUBLE 列に対する DTS の移行精度が、お客様のビジネス要件を満たすことを確認してください。DTS はこれらの列を ROUND(COLUMN,PRECISION) を使用して読み取ります。精度が指定されていない場合、FLOAT には 38 桁、DOUBLE には 308 桁が使用されます。
-
DTS は、失敗したタスクを 7 日間以内に回復しようと試みます。トラフィックをターゲットインスタンスに切り替える前に、タスクを終了またはリリースしてください。または、revoke コマンドを実行して、DTS のターゲットインスタンスアカウントに対する書き込み権限を削除してください。これにより、自動回復によるターゲットデータへのソースデータの上書きを防止できます。
-
RDS for MySQL インスタンスで Always-Encrypted が有効になっている場合、完全移行はサポートされていません。
説明
透過的データ暗号化（TDE）が有効になっている RDS for MySQL インスタンスは、スキーマ移行、完全移行、および増分移行をサポートしています。
-
タスクが失敗した場合、DTS サポートスタッフが 8 時間以内に復旧を試みます。復旧中、タスクを再起動したり、パラメーターを調整したりすることがあります。
説明
データベースパラメーターではなく、DTS タスクパラメーターのみが変更されます。 調整可能なパラメーターについては、「インスタンスパラメーターの変更」をご参照ください。
|
|
特殊ケース
|
-
自己管理 MySQL ソースの場合：
-
ソースデータベースでのマスタースタンバイスイッチオーバーにより、移行タスクが失敗します。
-
DTS は、ターゲットデータベースに移行された最終レコードのタイムスタンプと現在時刻を比較することでレイテンシーを算出します。ソースで長期間 DML 操作が実行されない場合、レイテンシー報告が不正確になります。レイテンシーが過大に表示された場合は、ソースで DML 操作を実行してレイテンシー値を更新してください。
説明
完全データベース移行を選択する場合、ハートビートテーブルを作成し、毎秒更新または書き込みを行ってください。
-
DTS は、バイナリログオフセットを進めるために、ソースデータベースで定期的に CREATE DATABASE IF NOT EXISTS `test` を実行します。
-
ソースが Amazon Aurora MySQL またはその他のクラスタード MySQL インスタンスである場合、タスクで設定されたドメイン名または IP アドレス、およびその DNS 解決が常に読み書き可能（RW）ノードを指すようにしてください。そうでない場合、移行タスクが失敗する可能性があります。
-
|
MySQL から AnalyticDB for MySQL への移行
以下の考慮事項および制限事項をご確認ください。
|
種別
|
説明
|
|
ソースデータベースの制限事項
|
-
帯域幅要件：ソースデータベースをホストするサーバーは、十分なアウトバウンド帯域幅を備えている必要があります。そうでない場合、移行速度が低下します。
-
移行対象となる各テーブルには、プライマリキーまたは一意制約が必要であり、キー列には一意の値が含まれている必要があります。そうでない場合、ターゲットデータベースに重複レコードが発生する可能性があります。
-
テーブルを移行対象として選択し、列名のマッピングなどの編集を行う場合、単一の移行タスクでは最大 1,000 個のテーブルをサポートします。この上限を超えると、タスクの送信時にエラーが発生して失敗します。この問題を解決するには、テーブルを複数のタスクに分割するか、完全データベース移行タスクを設定してください。
-
増分移行を実行する場合は、バイナリログを有効化してください。
-
binlog_format を ROW に、binlog_row_image を FULL に設定してください。設定されていない場合、事前チェックに失敗し、タスクを開始できません。
重要
自己管理 MySQL ソースがデュアルマスターコンフィグレーション（各インスタンスがマスターおよびスレーブの両方として機能）である場合、log_slave_updates パラメーターを有効化してください。これにより、DTS がすべてのバイナリログを読み取れるようになります。
-
RDS for MySQL インスタンスの場合、ローカルバイナリログの保存期間は最低 3 日間（推奨：7 日間）にしてください。自己管理 MySQL データベースの場合、ローカルバイナリログの保存期間は最低 7 日間にしてください。DTS がバイナリログにアクセスできない場合、タスクは失敗します。最悪の場合、データの不整合やデータ損失が発生する可能性があります。DTS の要件よりも短いバイナリログ保存期間が原因で発生した問題は、DTS の SLA の対象外となります。
説明
RDS for MySQL インスタンスにおけるローカルバイナリログの 保存期間 を設定する方法については、「ローカルログの自動削除」をご参照ください。
-
ソースデータベースで実行できない操作：
-
スキーマ移行または完全移行中に、データベースまたはテーブルのスキーマを変更する DDL 操作を実行しないでください。実行した場合、移行タスクが失敗します。
説明
完全移行中、DTS はソースデータベースに対してクエリを実行します。これによりメタデータロックが発生し、ソースデータベースでの DDL 操作がブロックされる可能性があります。
-
コメントを追加する DDL 操作（例：ALTER TABLE table_name COMMENT='Table comment';）を実行しないでください。実行した場合、移行タスクが失敗します。
-
完全移行のみを実行する場合、ソースインスタンスに新しいデータを書き込まないでください。書き込んだ場合、ソースとターゲットのデータが不整合になります。リアルタイムでデータの一貫性を保つには、スキーマ移行、完全移行、および増分移行を選択してください。
-
DTS は、バイナリログに書き込まれない変更によって生成されたデータ（例：物理バックアップから復元されたデータ、カスケード操作によって作成されたデータなど）を移行しません。
説明
このような状況が発生した場合、業務許容範囲内で完全移行を再実行してください。
-
ソース MySQL データベースのバージョンが 8.0.23 以降であり、非表示の隠し列が含まれている場合、DTS はその列を読み取れません。これにより、データ損失が発生する可能性があります。
説明
隠し列を可視化するには、ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; を実行してください。詳細については、「Invisible Columns」をご参照ください。
|
|
その他の制限事項
|
-
プレフィックスインデックスはサポートされていません。ソースデータベースにプレフィックスインデックスが含まれている場合、移行が失敗する可能性があります。
-
DTS は、INDEX、PARTITION、VIEW、PROCEDURE、FUNCTION、TRIGGER、FK オブジェクトの移行をサポートしていません。
-
ソースデータベースで、オンライン DDL 操作（マルチテーブルマージなどのシナリオを含む）のテンポラリテーブルモードを使用している場合、または一意キー列に機能ベースのインデックスを追加している場合、ターゲットデータベースでデータ損失またはタスク失敗が発生する可能性があります。
-
移行中にプライマリキーまたは一意キーの競合が発生した場合：
-
ターゲットデータベースにはカスタムプライマリキーが必要です。または、「テーブル・列設定」ステップで「プライマリキー列の追加」を設定してください。設定されていない場合、移行が失敗する可能性があります。
-
AnalyticDB for MySQL の組み込み制限により、ノードのディスク領域使用率が 80 % を超えると、DTS タスクが異常になり、遅延が発生します。移行対象のオブジェクトに基づいて必要な領域を見積もり、ターゲットクラスターに十分なストレージ領域があることを確認してください。
-
DTS タスク実行中に、ターゲットの AnalyticDB for MySQL 3.0 クラスターがバックアップ中の場合、タスクが失敗します。
-
移行を実行する前に、ソースおよびターゲットのデータベースのパフォーマンスを評価してください。移行は業務の閑散時間帯に実行してください。そうでない場合、完全移行が両方のデータベースの読み取りおよび書き込みリソースを消費し、データベース負荷が増加します。
-
完全移行では INSERT 操作が同時実行されます。これにより、ターゲットテーブルが断片化されます。完全移行後、ターゲットテーブルはソーステーブルよりも多くのストレージ領域を必要とします。
-
FLOAT または DOUBLE 列に対する DTS の移行精度が、お客様のビジネス要件を満たすことを確認してください。DTS はこれらの列を ROUND(COLUMN,PRECISION) を使用して読み取ります。精度が指定されていない場合、FLOAT には 38 桁、DOUBLE には 308 桁が使用されます。
-
DTS は、失敗したタスクを 7 日間以内に回復しようと試みます。トラフィックをターゲットインスタンスに切り替える前に、タスクを終了またはリリースしてください。または、revoke コマンドを実行して、DTS のターゲットインスタンスアカウントに対する書き込み権限を削除してください。これにより、自動回復によるターゲットデータへのソースデータの上書きを防止できます。
-
DDL 書き込みがターゲットデータベースで失敗した場合、DTS タスクは継続して実行されます。失敗した DDL 文はタスクログで確認できます。手順については、「タスクログの表示」をご参照ください。
-
RDS for MySQL インスタンスで Always-Encrypted が有効になっている場合、完全移行はサポートされていません。
説明
透過的データ暗号化（TDE）が有効になっている RDS for MySQL インスタンスは、スキーマ移行、完全移行、および増分移行をサポートしています。
-
タスクが失敗した場合、DTS サポートスタッフが 8 時間以内に復旧を試みます。復旧中、タスクを再起動したり、パラメーターを調整したりすることがあります。
説明
データベースパラメーターではなく、DTS タスクパラメーターのみが変更されます。 調整可能なパラメーターについては、「インスタンスパラメーターの変更」をご参照ください。
|
|
特殊ケース
|
-
自己管理 MySQL ソースの場合：
-
ソースデータベースでのマスタースタンバイスイッチオーバーにより、移行タスクが失敗します。
-
DTS は、ターゲットデータベースに移行された最終レコードのタイムスタンプと現在時刻を比較することでレイテンシーを算出します。ソースで長期間 DML 操作が実行されない場合、レイテンシー報告が不正確になります。レイテンシーが過大に表示された場合は、ソースで DML 操作を実行してレイテンシー値を更新してください。
説明
完全データベース移行を選択する場合、ハートビートテーブルを作成し、毎秒更新または書き込みを行ってください。
-
DTS は、バイナリログオフセットを進めるために、ソースデータベースで定期的に CREATE DATABASE IF NOT EXISTS `test` を実行します。
-
ソースが Amazon Aurora MySQL またはその他のクラスタード MySQL インスタンスである場合、タスクで設定されたドメイン名または IP アドレス、およびその DNS 解決が常に読み書き可能（RW）ノードを指すようにしてください。そうでない場合、移行タスクが失敗する可能性があります。
-
|
MySQL から自己管理 Kafka クラスターへの移行
以下の考慮事項および制限事項をご確認ください。
|
種別
|
説明
|
|
ソースデータベースの制限事項
|
-
帯域幅要件：ソースデータベースをホストするサーバーは、十分なアウトバウンド帯域幅を備えている必要があります。そうでない場合、移行速度が低下します。
-
移行対象となる各テーブルには、プライマリキーまたは一意制約が必要であり、キー列には一意の値が含まれている必要があります。そうでない場合、ターゲットデータベースに重複レコードが発生する可能性があります。
-
テーブルを移行対象として選択し、列名のマッピングなどの編集を行う場合、単一の移行タスクでは最大 1,000 個のテーブルをサポートします。この上限を超えると、タスクの送信時にエラーが発生して失敗します。この問題を解決するには、テーブルを複数のタスクに分割するか、完全データベース移行タスクを設定してください。
-
増分移行を実行する場合は、バイナリログを有効化してください。
-
binlog_format を ROW に、binlog_row_image を FULL に設定してください。設定されていない場合、事前チェックに失敗し、タスクを開始できません。
重要
自己管理 MySQL ソースがデュアルマスターコンフィグレーション（各インスタンスがマスターおよびスレーブの両方として機能）である場合、log_slave_updates パラメーターを有効化してください。これにより、DTS がすべてのバイナリログを読み取れるようになります。
-
RDS for MySQL インスタンスの場合、ローカルバイナリログの保存期間は最低 3 日間（推奨：7 日間）にしてください。自己管理 MySQL データベースの場合、ローカルバイナリログの保存期間は最低 7 日間にしてください。DTS がバイナリログにアクセスできない場合、タスクは失敗します。最悪の場合、データの不整合やデータ損失が発生する可能性があります。DTS の要件よりも短いバイナリログ保存期間が原因で発生した問題は、DTS の SLA の対象外となります。
説明
RDS for MySQL インスタンスにおけるローカルバイナリログの 保存期間 を設定する方法については、「ローカルログの自動削除」をご参照ください。
-
ソースデータベースで実行できない操作：
-
スキーマ移行または完全移行中に、データベースまたはテーブルのスキーマを変更する DDL 操作を実行しないでください。実行した場合、移行タスクが失敗します。
説明
完全移行中、DTS はソースデータベースに対してクエリを実行します。これによりメタデータロックが発生し、ソースデータベースでの DDL 操作がブロックされる可能性があります。
-
完全移行のみを実行する場合、ソースインスタンスに新しいデータを書き込まないでください。書き込んだ場合、ソースとターゲットのデータが不整合になります。リアルタイムでデータの一貫性を保つには、スキーマ移行、完全移行、および増分移行を選択してください。
-
DTS は、バイナリログに書き込まれない変更によって生成されたデータ（例：物理バックアップから復元されたデータ、カスケード操作によって作成されたデータなど）を移行しません。
説明
このような状況が発生した場合、業務許容範囲内で完全移行を再実行してください。
-
ソース MySQL データベースのバージョンが 8.0.23 以降であり、非表示の隠し列が含まれている場合、DTS はその列を読み取れません。これにより、データ損失が発生する可能性があります。
説明
隠し列を可視化するには、ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; を実行してください。詳細については、「Invisible Columns」をご参照ください。
|
|
その他の制限事項
|
-
移行対象としてサポートされるのはデータテーブルのみです。
-
DTS は、INDEX、PARTITION、VIEW、PROCEDURE、FUNCTION、TRIGGER、FK オブジェクトの移行をサポートしていません。
-
移行を実行する前に、ソースおよびターゲットのデータベースのパフォーマンスを評価してください。移行は業務の閑散時間帯に実行してください。そうでない場合、完全移行が両方のデータベースの読み取りおよび書き込みリソースを消費し、データベース負荷が増加します。
-
完全移行では INSERT 操作が同時実行されます。これにより、ターゲットテーブルが断片化されます。完全移行後、ターゲットテーブルはソーステーブルよりも多くのストレージ領域を必要とします。
-
FLOAT または DOUBLE 列に対する DTS の移行精度が、お客様のビジネス要件を満たすことを確認してください。DTS はこれらの列を ROUND(COLUMN,PRECISION) を使用して読み取ります。精度が指定されていない場合、FLOAT には 38 桁、DOUBLE には 308 桁が使用されます。
-
DTS は、失敗したタスクを 7 日間以内に回復しようと試みます。トラフィックをターゲットインスタンスに切り替える前に、タスクを終了またはリリースしてください。または、revoke コマンドを実行して、DTS のターゲットインスタンスアカウントに対する書き込み権限を削除してください。これにより、自動回復によるターゲットデータへのソースデータの上書きを防止できます。
-
データをターゲットデータベースに DTS を介さず書き込まないでください。これにより、ソースおよびターゲットデータベース間でデータの不整合が発生する可能性があります。
-
移行中にターゲット Kafka クラスターがスケールアウトまたはスケールインする場合、DTS タスクを再起動してください。
-
RDS for MySQL インスタンスで Always-Encrypted が有効になっている場合、完全移行はサポートされていません。
説明
透過的データ暗号化（TDE）が有効になっている RDS for MySQL インスタンスは、スキーマ移行、完全移行、および増分移行をサポートしています。
-
タスクが失敗した場合、DTS サポートスタッフが 8 時間以内に復旧を試みます。復旧中、タスクを再起動したり、パラメーターを調整したりすることがあります。
説明
データベースパラメーターではなく、DTS タスクパラメーターのみが変更されます。 調整可能なパラメーターについては、「インスタンスパラメーターの変更」をご参照ください。
|
|
特殊ケース
|
-
自己管理 MySQL ソースの場合：
-
ソースデータベースでのマスタースタンバイスイッチオーバーにより、移行タスクが失敗します。
-
DTS は、ターゲットデータベースに移行された最終レコードのタイムスタンプと現在時刻を比較することでレイテンシーを算出します。ソースで長期間 DML 操作が実行されない場合、レイテンシー報告が不正確になります。レイテンシーが過大に表示された場合は、ソースで DML 操作を実行してレイテンシー値を更新してください。
説明
完全データベース移行を選択する場合、ハートビートテーブルを作成し、毎秒更新または書き込みを行ってください。
-
DTS は、バイナリログオフセットを進めるために、ソースデータベースで定期的に CREATE DATABASE IF NOT EXISTS `test` を実行します。
-
ソースが Amazon Aurora MySQL またはその他のクラスタード MySQL インスタンスである場合、タスクで設定されたドメイン名または IP アドレス、およびその DNS 解決が常に読み書き可能（RW）ノードを指すようにしてください。そうでない場合、移行タスクが失敗する可能性があります。
-
|
MySQL から DataHub への移行
以下の考慮事項および制限事項をご確認ください。
|
種別
|
説明
|
|
ソースデータベースの制限事項
|
-
帯域幅要件：ソースデータベースをホストするサーバーは、十分なアウトバウンド帯域幅を備えている必要があります。そうでない場合、移行速度が低下します。
-
移行対象となる各テーブルには、プライマリキーまたは一意制約が必要であり、キー列には一意の値が含まれている必要があります。そうでない場合、ターゲットデータベースに重複レコードが発生する可能性があります。
-
テーブルを移行対象として選択し、列名のマッピングなどの編集を行う場合、単一の移行タスクでは最大 1,000 個のテーブルをサポートします。この上限を超えると、タスクの送信時にエラーが発生して失敗します。この問題を解決するには、テーブルを複数のタスクに分割するか、完全データベース移行タスクを設定してください。
-
増分移行を実行する場合は、バイナリログを有効化してください。
-
binlog_format を ROW に、binlog_row_image を FULL に設定してください。設定されていない場合、事前チェックに失敗し、タスクを開始できません。
重要
自己管理 MySQL ソースがデュアルマスターコンフィグレーション（各インスタンスがマスターおよびスレーブの両方として機能）である場合、log_slave_updates パラメーターを有効化してください。これにより、DTS がすべてのバイナリログを読み取れるようになります。
-
RDS for MySQL インスタンスの場合、ローカルバイナリログの保存期間は最低 3 日間（推奨：7 日間）にしてください。自己管理 MySQL データベースの場合、ローカルバイナリログの保存期間は最低 7 日間にしてください。DTS がバイナリログにアクセスできない場合、タスクは失敗します。最悪の場合、データの不整合やデータ損失が発生する可能性があります。DTS の要件よりも短いバイナリログ保存期間が原因で発生した問題は、DTS の SLA の対象外となります。
説明
RDS for MySQL インスタンスにおけるローカルバイナリログの 保存期間 を設定する方法については、「ローカルログの自動削除」をご参照ください。
スキーマ移行フェーズ中に、データベースまたはテーブルのスキーマを変更する DDL 操作を実行すると、データ移行タスクが失敗します。 -
DTS は、バイナリログに書き込まれない変更によって生成されたデータ（例：物理バックアップから復元されたデータ、カスケード操作によって作成されたデータなど）を移行しません。
説明
このような状況が発生した場合、業務許容範囲内で完全移行を再実行してください。
-
ソース MySQL データベースのバージョンが 8.0.23 以降であり、非表示の隠し列が含まれている場合、DTS はその列を読み取れません。これにより、データ損失が発生する可能性があります。
説明
隠し列を可視化するには、ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; を実行してください。詳細については、「Invisible Columns」をご参照ください。
|
|
その他の制限事項
|
-
テーブルレベルの移行のみがサポートされています。
-
DTS は、INDEX、PARTITION、VIEW、PROCEDURE、FUNCTION、TRIGGER、FK オブジェクトの移行をサポートしていません。
-
ターゲット DataHub プロジェクトの単一 String フィールドは、最大 2 MB をサポートします。
-
ソースデータベースの移行対象に対して、pt-online-schema-change などのツールを使用してオンライン DDL 操作を実行しないでください。実行した場合、移行が失敗します。
-
オンライン DDL 操作は、Data Management（DMS）を使用して実行できます。手順については、「テーブルのロックなしでオンラインスキーマ変更」をご参照ください。
警告
DTS 以外の手段でターゲットデータベースにデータを書き込む場合、DMS を使用してオンライン DDL 操作を実行しないでください。実行した場合、ターゲットデータが失われる可能性があります。
-
FLOAT または DOUBLE 列に対する DTS の移行精度が、お客様のビジネス要件を満たすことを確認してください。DTS はこれらの列を ROUND(COLUMN,PRECISION) を使用して読み取ります。精度が指定されていない場合、FLOAT には 38 桁、DOUBLE には 308 桁が使用されます。
-
DTS は、失敗したタスクを 7 日間以内に回復しようと試みます。トラフィックをターゲットインスタンスに切り替える前に、タスクを終了またはリリースしてください。または、revoke コマンドを実行して、DTS のターゲットインスタンスアカウントに対する書き込み権限を削除してください。これにより、自動回復によるターゲットデータへのソースデータの上書きを防止できます。
-
RDS for MySQL インスタンスで Always-Encrypted が有効になっている場合、完全移行はサポートされていません。
説明
透過的データ暗号化（TDE）が有効になっている RDS for MySQL インスタンスは、スキーマ移行、完全移行、および増分移行をサポートしています。
-
タスクが失敗した場合、DTS サポートスタッフが 8 時間以内に復旧を試みます。復旧中、タスクを再起動したり、パラメーターを調整したりすることがあります。
説明
データベースパラメーターではなく、DTS タスクパラメーターのみが変更されます。 調整可能なパラメーターについては、「インスタンスパラメーターの変更」をご参照ください。
|
|
特殊ケース
|
-
自己管理 MySQL ソースの場合：
-
ソースデータベースでのマスタースタンバイスイッチオーバーにより、移行タスクが失敗します。
-
DTS は、ターゲットデータベースに移行された最終レコードのタイムスタンプと現在時刻を比較することでレイテンシーを算出します。ソースで長期間 DML 操作が実行されない場合、レイテンシー報告が不正確になります。レイテンシーが過大に表示された場合は、ソースで DML 操作を実行してレイテンシー値を更新してください。
説明
完全データベース移行を選択する場合、ハートビートテーブルを作成し、毎秒更新または書き込みを行ってください。
-
DTS は、バイナリログオフセットを進めるために、ソースデータベースで定期的に CREATE DATABASE IF NOT EXISTS `test` を実行します。
-
ソースが Amazon Aurora MySQL またはその他のクラスタード MySQL インスタンスである場合、タスクで設定されたドメイン名または IP アドレス、およびその DNS 解決が常に読み書き可能（RW）ノードを指すようにしてください。そうでない場合、移行タスクが失敗する可能性があります。
-
|