PolarDB for MySQL ソースの移行シナリオの概要
次の移行シナリオに基づいて、移行タスクの注意と制限を確認してください。
PolarDB for MySQL インスタンス間の移行
次の表に、注意点と制限事項を示します。
タイプ | 説明 |
ソースデータベースの制限 | 帯域幅の要件: ソースデータベースをホストするサーバーには、十分なアウトバウンド帯域幅が必要です。そうでない場合、データ移行速度が影響を受けます。 移行するテーブルには、プライマリキーまたは一意制約が必要であり、キーまたは制約のフィールドは一意である必要があります。そうでない場合、ターゲットデータベースに重複データが表示される可能性があります。 テーブルレベルでデータを移行し、列名のマッピングなどテーブルを編集する必要がある場合、単一のデータ移行タスクで移行できるテーブルは最大 1,000 です。この制限を超えると、タスクの送信後にエラーが報告されます。この場合、テーブルを複数の移行タスクに分割するか、データベース全体を移行するタスクを設定します。 増分移行を実行する場合: バイナリログを有効にし、`loose_polar_log_bin` パラメーターを on に設定する必要があります。そうしないと、事前チェックでエラーが報告され、データ移行タスクを開始できません。バイナリログを有効にしてパラメーターを変更する方法の詳細については、「バイナリログを有効にする」および「パラメーターの変更」をご参照ください。
説明 PolarDB for MySQL クラスターのバイナリログを有効にすると、ストレージ領域が消費され、ストレージ料金が発生します。 PolarDB for MySQL クラスターのバイナリログは、少なくとも 3 日間保持する必要があります。7 日間の保持期間を推奨します。そうしないと、DTS がバイナリログを取得できず、タスクが失敗する可能性があります。極端な場合、これはデータの不整合やデータ損失につながる可能性があります。DTS の要件よりも短いバイナリログ保持期間によって引き起こされた問題は、DTS サービスレベルアグリーメント (SLA) の対象外です。
説明 PolarDB for MySQL クラスターのバイナリログの保持期間を設定する方法の詳細については、「保持期間の変更」をご参照ください。
ソースデータベースの操作上の制限: スキーマ移行および完全なデータ移行中は、データベースまたはテーブルスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ移行タスクは失敗します。
説明 完全なデータ移行中、DTS はソースデータベースをクエリします。これによりメタデータロックが作成され、ソースデータベースでの DDL 操作がブロックされる可能性があります。 完全なデータ移行のみを実行する場合は、ソースインスタンスに新しいデータを書き込まないでください。そうしないと、ソースと宛先の間でデータの不整合が発生します。リアルタイムのデータ整合性を維持するには、スキーマ移行、完全なデータ移行、および増分データ移行を選択します。
|
その他の制限 | 互換性を確保するために、ソースと宛先の PolarDB for MySQL インスタンスで同じ MySQL バージョンを実行することをお勧めします。 コメント構文で定義されたパーサーの移行はサポートされていません。 DTS は、ソース PolarDB for MySQL インスタンスの読み取り専用ノードの移行をサポートしていません。 DTS は、ソース PolarDB for MySQL インスタンスからの OSS 外部テーブルの移行をサポートしていません。 DTS は、INDEX と PARTITION の移行をサポートしていません。 DTS は、完全なデータ移行中のデータベースインスタンスのプライマリ/スタンバイスイッチオーバーシナリオをサポートしていません。このようなシナリオでは、移行タスクを速やかに再設定してください。 複数のテーブルのマージなど、一時テーブルを使用するオンライン DDL 操作がソースデータベースで実行されると、ターゲットデータベースでデータが失われたり、移行インスタンスが失敗したりする可能性があります。 移行中にプライマリキーまたは一意キーの競合が発生した場合: 移行するデータに、珍しい文字や絵文字など、4 バイトのストレージを必要とするコンテンツが含まれている場合、データを受信するターゲットデータベースとテーブルは utf8mb4 文字セットを使用する必要があります。
説明 DTS を使用してスキーマを移行する場合、ターゲットデータベースのインスタンスレベルのパラメーター character_set_server を utf8mb4 に設定する必要があります。 データ移行を実行する前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。また、オフピーク時にデータ移行を実行することをお勧めします。そうしないと、DTS は完全なデータ移行中にソースデータベースとターゲットデータベースの両方で読み取りおよび書き込みリソースを消費し、データベースの負荷が増加する可能性があります。 完全なデータ移行には同時 INSERT 操作が含まれるため、ターゲットデータベースでテーブルの断片化が発生します。その結果、完全移行が完了した後、ターゲットデータベースのテーブルストレージ領域はソースインスタンスよりも大きくなります。 FLOAT または DOUBLE データ型の列の移行精度がビジネス要件を満たしているかどうかを確認します。DTS は、ROUND(COLUMN,PRECISION) を使用してこれらの列の値を読み取ります。精度を明示的に定義しない場合、DTS は FLOAT にはデフォルトの精度 38 を、DOUBLE には 308 を使用します。 DTS は 7 日以内に失敗したタスクの回復を試みます。したがって、ビジネスを宛先インスタンスに切り替える前に、タスクを終了またはリリースする必要があります。または、revoke コマンドを使用して、DTS が宛先インスタンスへのアクセスに使用するデータベースアカウントの書き込み権限を取り消します。これにより、タスクが自動的に回復された場合に、ソースデータが宛先インスタンスのデータを上書きするのを防ぎます。 DDL 文がターゲットデータベースへの書き込みに失敗した場合、DTS タスクは実行を継続します。失敗した DDL 文については、タスクログを確認する必要があります。タスクログの表示方法の詳細については、「タスクログのクエリ」をご参照ください。 ソースデータベースからデータベースアカウントを移行するには、前提条件を満たし、関連する注意事項を理解する必要があります。詳細については、「データベースアカウントの移行」をご参照ください。 インスタンスが失敗した場合、DTS ヘルプデスクは 8 時間以内にインスタンスの回復を試みます。回復プロセス中に、インスタンスの再起動やパラメーターの調整などの操作が実行される場合があります。
説明 パラメーターが調整されるとき、DTS インスタンスのパラメーターのみが変更されます。データベース内のパラメーターは変更されません。変更される可能性のあるパラメーターには、インスタンスパラメーターの変更で説明されているものが含まれますが、これらに限定されません。
|
その他の注意事項 | DTS は、ソースデータベースで定期的に CREATE DATABASE IF NOT EXISTS `test` コマンドを実行して、バイナリログのオフセットを進めます。 |
PolarDB for MySQL から RDS for MySQL または自己管理 MySQL への移行
次の表に、注意点と制限事項を示します。
タイプ | 説明 |
ソースデータベースの制限 | 帯域幅の要件: ソースデータベースをホストするサーバーには、十分なアウトバウンド帯域幅が必要です。そうでない場合、データ移行速度が影響を受けます。 移行するテーブルには、プライマリキーまたは一意制約が必要であり、キーまたは制約のフィールドは一意である必要があります。そうでない場合、ターゲットデータベースに重複データが表示される可能性があります。 テーブルレベルでデータを移行し、列名のマッピングなどテーブルを編集する必要がある場合、単一のデータ移行タスクで移行できるテーブルは最大 1,000 です。この制限を超えると、タスクの送信後にエラーが報告されます。この場合、テーブルを複数の移行タスクに分割するか、データベース全体を移行するタスクを設定します。 増分移行を実行する場合: バイナリログを有効にし、`loose_polar_log_bin` パラメーターを on に設定する必要があります。そうしないと、事前チェックでエラーが報告され、データ移行タスクを開始できません。バイナリログを有効にしてパラメーターを変更する方法の詳細については、「バイナリログを有効にする」および「パラメーターの変更」をご参照ください。
説明 PolarDB for MySQL クラスターのバイナリログを有効にすると、ストレージ領域が消費され、ストレージ料金が発生します。 PolarDB for MySQL クラスターのバイナリログは、少なくとも 3 日間保持する必要があります。7 日間の保持期間を推奨します。そうしないと、DTS がバイナリログを取得できず、タスクが失敗する可能性があります。極端な場合、これはデータの不整合やデータ損失につながる可能性があります。DTS の要件よりも短いバイナリログ保持期間によって引き起こされた問題は、DTS サービスレベルアグリーメント (SLA) の対象外です。
説明 PolarDB for MySQL クラスターのバイナリログの保持期間を設定する方法の詳細については、「保持期間の変更」をご参照ください。
ソースデータベースの操作上の制限: スキーマ移行および完全なデータ移行中は、データベースまたはテーブルスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ移行タスクは失敗します。
説明 完全なデータ移行中、DTS はソースデータベースをクエリします。これによりメタデータロックが作成され、ソースデータベースでの DDL 操作がブロックされる可能性があります。 完全なデータ移行のみを実行する場合は、ソースインスタンスに新しいデータを書き込まないでください。そうしないと、ソースと宛先の間でデータの不整合が発生します。リアルタイムのデータ整合性を維持するには、スキーマ移行、完全なデータ移行、および増分データ移行を選択します。
|
注意事項 | DTS は、ソース PolarDB for MySQL インスタンスの読み取り専用ノードの移行をサポートしていません。 DTS は、ソース PolarDB for MySQL インスタンスからの OSS 外部テーブルの移行をサポートしていません。 DTS は、INDEX と PARTITION の移行をサポートしていません。 コメント構文で定義されたパーサーの移行はサポートされていません。 DTS は、完全なデータ移行中のデータベースインスタンスのプライマリ/スタンバイスイッチオーバーシナリオをサポートしていません。このようなシナリオでは、移行タスクを速やかに再設定してください。 複数のテーブルのマージなど、一時テーブルを使用するオンライン DDL 操作がソースデータベースで実行されると、ターゲットデータベースでデータが失われたり、移行インスタンスが失敗したりする可能性があります。 移行中にプライマリキーまたは一意キーの競合が発生した場合: 移行するデータに、珍しい文字や絵文字など、4 バイトのストレージを必要とするコンテンツが含まれている場合、データを受信するターゲットデータベースとテーブルは utf8mb4 文字セットを使用する必要があります。
説明 DTS を使用してスキーマを移行する場合、ターゲットデータベースのインスタンスレベルのパラメーター character_set_server を utf8mb4 に設定する必要があります。 データ移行を実行する前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。また、オフピーク時にデータ移行を実行することをお勧めします。そうしないと、DTS は完全なデータ移行中にソースデータベースとターゲットデータベースの両方で読み取りおよび書き込みリソースを消費し、データベースの負荷が増加する可能性があります。 完全なデータ移行には同時 INSERT 操作が含まれるため、ターゲットデータベースでテーブルの断片化が発生します。その結果、完全移行が完了した後、ターゲットデータベースのテーブルストレージ領域はソースインスタンスよりも大きくなります。 FLOAT または DOUBLE データ型の列の移行精度がビジネス要件を満たしているかどうかを確認します。DTS は、ROUND(COLUMN,PRECISION) を使用してこれらの列の値を読み取ります。精度を明示的に定義しない場合、DTS は FLOAT にはデフォルトの精度 38 を、DOUBLE には 308 を使用します。 DTS は 7 日以内に失敗したタスクの回復を試みます。したがって、ビジネスを宛先インスタンスに切り替える前に、タスクを終了またはリリースする必要があります。または、revoke コマンドを使用して、DTS が宛先インスタンスへのアクセスに使用するデータベースアカウントの書き込み権限を取り消します。これにより、タスクが自動的に回復された場合に、ソースデータが宛先インスタンスのデータを上書きするのを防ぎます。 DTS は、ソースデータベースで定期的に CREATE DATABASE IF NOT EXISTS `test` コマンドを実行して、バイナリログのオフセットを進めます。 DDL 文がターゲットデータベースへの書き込みに失敗した場合、DTS タスクは実行を継続します。失敗した DDL 文については、タスクログを確認する必要があります。タスクログの表示方法の詳細については、「タスクログのクエリ」をご参照ください。 列名が大文字と小文字のみで異なるフィールドを宛先の MySQL データベースの同じテーブルに書き込むと、移行結果が期待どおりにならない場合があります。これは、MySQL データベースの列名が大文字と小文字を区別しないためです。 データ移行が完了した後 (インスタンスの ステータス が 完了 になった後)、analyze table <table_name> コマンドを実行して、すべてのデータが宛先テーブルに書き込まれたことを確認することをお勧めします。たとえば、宛先の MySQL データベースで HA スイッチオーバーがトリガーされた場合、データがメモリにのみ書き込まれ、データが失われる可能性があります。 インスタンスが失敗した場合、DTS ヘルプデスクは 8 時間以内にインスタンスの回復を試みます。回復プロセス中に、インスタンスの再起動やパラメーターの調整などの操作が実行される場合があります。
説明 パラメーターが調整されるとき、DTS インスタンスのパラメーターのみが変更されます。データベース内のパラメーターは変更されません。変更される可能性のあるパラメーターには、インスタンスパラメーターの変更で説明されているものが含まれますが、これらに限定されません。
|
特殊なケース | 宛先データベースが RDS for MySQL インスタンスの場合、DTS はインスタンスにデータベースを自動的に作成します。移行するデータベースの名前が RDS for MySQL の命名規則に準拠していない場合は、移行タスクを設定する前に RDS for MySQL インスタンスにデータベースを作成する必要があります。詳細については、「データベースの管理」をご参照ください。 |
PolarDB for MySQL から PolarDB-X 2.0 への移行
次の表に、注意点と制限事項を示します。
タイプ | 説明 |
ソースデータベースの制限 | 帯域幅の要件: ソースデータベースをホストするサーバーには、十分なアウトバウンド帯域幅が必要です。そうでない場合、データ移行速度が影響を受けます。 移行するテーブルには、プライマリキーまたは一意制約が必要であり、キーまたは制約のフィールドは一意である必要があります。そうでない場合、ターゲットデータベースに重複データが表示される可能性があります。 テーブルレベルでデータを移行し、列名のマッピングなどテーブルを編集する必要がある場合、単一のデータ移行タスクで移行できるテーブルは最大 1,000 です。この制限を超えると、タスクの送信後にエラーが報告されます。この場合、テーブルを複数の移行タスクに分割するか、データベース全体を移行するタスクを設定します。 増分移行を実行する場合: バイナリログを有効にし、`loose_polar_log_bin` パラメーターを on に設定する必要があります。そうしないと、事前チェックでエラーが報告され、データ移行タスクを開始できません。バイナリログを有効にしてパラメーターを変更する方法の詳細については、「バイナリログを有効にする」および「パラメーターの変更」をご参照ください。
説明 PolarDB for MySQL クラスターのバイナリログを有効にすると、ストレージ領域が消費され、ストレージ料金が発生します。 PolarDB for MySQL クラスターのバイナリログは、少なくとも 3 日間保持する必要があります。7 日間の保持期間を推奨します。そうしないと、DTS がバイナリログを取得できず、タスクが失敗する可能性があります。極端な場合、これはデータの不整合やデータ損失につながる可能性があります。DTS の要件よりも短いバイナリログ保持期間によって引き起こされた問題は、DTS サービスレベルアグリーメント (SLA) の対象外です。
説明 PolarDB for MySQL クラスターのバイナリログの保持期間を設定する方法の詳細については、「保持期間の変更」をご参照ください。
ソースデータベースの操作上の制限: 完全なデータ移行中は、データベースまたはテーブルスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ移行タスクは失敗します。
説明 完全なデータ移行中、DTS はソースデータベースをクエリします。これによりメタデータロックが作成され、ソースデータベースでの DDL 操作がブロックされる可能性があります。 完全なデータ移行のみを実行する場合は、ソースインスタンスに新しいデータを書き込まないでください。そうしないと、ソースと宛先の間でデータの不整合が発生します。リアルタイムのデータ整合性を維持するには、完全なデータ移行と増分データ移行を選択します。 DDL 操作の増分移行はサポートされていません。そうしないと、データ移行タスクは失敗します。DDL 操作を実行するには、まず宛先データベースで手動で実行し、次にソースデータベースで同じ DDL 操作を実行することをお勧めします。
|
注意事項 | 複数のテーブルのマージなど、一時テーブルを使用するオンライン DDL 操作がソースデータベースで実行されると、ターゲットデータベースでデータが失われたり、移行インスタンスが失敗したりする可能性があります。 移行中にプライマリキーまたは一意キーの競合が発生した場合: DTS は、ソース PolarDB for MySQL インスタンスの読み取り専用ノードの移行をサポートしていません。 DTS は、ソース PolarDB for MySQL インスタンスからの OSS 外部テーブルの移行をサポートしていません。 DTS は、完全なデータ移行中のデータベースインスタンスのプライマリ/スタンバイスイッチオーバーシナリオをサポートしていません。このようなシナリオでは、移行タスクを速やかに再設定してください。 データ移行を実行する前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。また、オフピーク時にデータ移行を実行することをお勧めします。そうしないと、DTS は完全なデータ移行中にソースデータベースとターゲットデータベースの両方で読み取りおよび書き込みリソースを消費し、データベースの負荷が増加する可能性があります。 完全なデータ移行には同時 INSERT 操作が含まれるため、ターゲットデータベースでテーブルの断片化が発生します。その結果、完全移行が完了した後、ターゲットデータベースのテーブルストレージ領域はソースインスタンスよりも大きくなります。 FLOAT または DOUBLE データ型の列の移行精度がビジネス要件を満たしているかどうかを確認します。DTS は、ROUND(COLUMN,PRECISION) を使用してこれらの列の値を読み取ります。精度を明示的に定義しない場合、DTS は FLOAT にはデフォルトの精度 38 を、DOUBLE には 308 を使用します。 DTS は 7 日以内に失敗したタスクの回復を試みます。したがって、ビジネスを宛先インスタンスに切り替える前に、タスクを終了またはリリースする必要があります。または、revoke コマンドを使用して、DTS が宛先インスタンスへのアクセスに使用するデータベースアカウントの書き込み権限を取り消します。これにより、タスクが自動的に回復された場合に、ソースデータが宛先インスタンスのデータを上書きするのを防ぎます。 DTS は、ソースデータベースで定期的に CREATE DATABASE IF NOT EXISTS `test` コマンドを実行して、バイナリログのオフセットを進めます。 インスタンスが失敗した場合、DTS ヘルプデスクは 8 時間以内にインスタンスの回復を試みます。回復プロセス中に、インスタンスの再起動やパラメーターの調整などの操作が実行される場合があります。
説明 パラメーターが調整されるとき、DTS インスタンスのパラメーターのみが変更されます。データベース内のパラメーターは変更されません。変更される可能性のあるパラメーターには、インスタンスパラメーターの変更で説明されているものが含まれますが、これらに限定されません。
|
PolarDB for MySQL から AnalyticDB for MySQL への移行
次の表に、注意点と制限事項を示します。
タイプ | 説明 |
ソースデータベースの制限 | 帯域幅の要件: ソースデータベースをホストするサーバーには、十分なアウトバウンド帯域幅が必要です。そうでない場合、データ移行速度が影響を受けます。 移行するテーブルには、プライマリキーまたは一意制約が必要であり、キーまたは制約のフィールドは一意である必要があります。そうでない場合、ターゲットデータベースに重複データが表示される可能性があります。 テーブルレベルでデータを移行し、列名のマッピングなどテーブルを編集する必要がある場合、単一のデータ移行タスクで移行できるテーブルは最大 1,000 です。この制限を超えると、タスクの送信後にエラーが報告されます。この場合、テーブルを複数の移行タスクに分割するか、データベース全体を移行するタスクを設定します。 増分移行を実行する場合: バイナリログを有効にし、`loose_polar_log_bin` パラメーターを on に設定する必要があります。そうしないと、事前チェックでエラーが報告され、データ移行タスクを開始できません。バイナリログを有効にしてパラメーターを変更する方法の詳細については、「バイナリログを有効にする」および「パラメーターの変更」をご参照ください。
説明 PolarDB for MySQL クラスターのバイナリログを有効にすると、ストレージ領域が消費され、ストレージ料金が発生します。 PolarDB for MySQL クラスターのバイナリログは、少なくとも 3 日間保持する必要があります。7 日間の保持期間を推奨します。そうしないと、DTS がバイナリログを取得できず、タスクが失敗する可能性があります。極端な場合、これはデータの不整合やデータ損失につながる可能性があります。DTS の要件よりも短いバイナリログ保持期間によって引き起こされた問題は、DTS サービスレベルアグリーメント (SLA) の対象外です。
説明 PolarDB for MySQL クラスターのバイナリログの保持期間を設定する方法の詳細については、「保持期間の変更」をご参照ください。
ソースデータベースの操作上の制限: スキーマ移行および完全なデータ移行中は、データベースまたはテーブルスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ移行タスクは失敗します。
説明 完全なデータ移行中、DTS はソースデータベースをクエリします。これによりメタデータロックが作成され、ソースデータベースでの DDL 操作がブロックされる可能性があります。 移行中に、ALTER TABLE table_name COMMENT='table_comment'; のように、プライマリキーを変更したり、テーブルにコメントを追加したりする DDL 操作を実行しないでください。そうしないと、データ移行タスクは失敗します。 完全なデータ移行のみを実行する場合は、ソースインスタンスに新しいデータを書き込まないでください。そうしないと、ソースと宛先の間でデータの不整合が発生します。リアルタイムのデータ整合性を維持するには、スキーマ移行、完全なデータ移行、および増分データ移行を選択します。
|
注意事項 | DTS はプレフィックスインデックスの移行をサポートしていません。ソースデータベースにプレフィックスインデックスがある場合、データ移行は失敗する可能性があります。 複数のテーブルのマージなど、一時テーブルを使用するオンライン DDL 操作がソースデータベースで実行されると、ターゲットデータベースでデータが失われたり、移行インスタンスが失敗したりする可能性があります。 移行中にプライマリキーまたは一意キーの競合が発生した場合: 宛先データベースにはカスタムプライマリキーが必要です。または、テーブル・列設定 ステップで プライマリキー列の追加 を設定する必要があります。そうしないと、データ移行が失敗する可能性があります。 DTS は、ソース PolarDB for MySQL インスタンスの読み取り専用ノードの移行をサポートしていません。 DTS は、ソース PolarDB for MySQL インスタンスからの OSS 外部テーブルの移行をサポートしていません。 DTS は、INDEX、PARTITION、VIEW、PROCEDURE、FUNCTION、TRIGGER、および FK の移行をサポートしていません。 DTS は、完全なデータ移行中のデータベースインスタンスのプライマリ/スタンバイスイッチオーバーシナリオをサポートしていません。このようなシナリオでは、移行タスクを速やかに再設定してください。 AnalyticDB for MySQL の制限により、AnalyticDB for MySQL クラスター内のノードのディスク領域使用率が 80% を超えると、DTS タスクが異常になり、レイテンシーが発生します。移行対象のオブジェクトに必要な領域を事前に見積もり、宛先クラスターに十分なストレージ領域があることを確認してください。 DTS タスクの実行中に宛先の AnalyticDB for MySQL 3.0 クラスターがバックアップされている場合、タスクは失敗します。 データ移行を実行する前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。また、オフピーク時にデータ移行を実行することをお勧めします。そうしないと、DTS は完全なデータ移行中にソースデータベースとターゲットデータベースの両方で読み取りおよび書き込みリソースを消費し、データベースの負荷が増加する可能性があります。 完全なデータ移行には同時 INSERT 操作が含まれるため、ターゲットデータベースでテーブルの断片化が発生します。その結果、完全移行が完了した後、ターゲットデータベースのテーブルストレージ領域はソースインスタンスよりも大きくなります。 FLOAT または DOUBLE データ型の列の移行精度がビジネス要件を満たしているかどうかを確認します。DTS は、ROUND(COLUMN,PRECISION) を使用してこれらの列の値を読み取ります。精度を明示的に定義しない場合、DTS は FLOAT にはデフォルトの精度 38 を、DOUBLE には 308 を使用します。 DTS は 7 日以内に失敗したタスクの回復を試みます。したがって、ビジネスを宛先インスタンスに切り替える前に、タスクを終了またはリリースする必要があります。または、revoke コマンドを使用して、DTS が宛先インスタンスへのアクセスに使用するデータベースアカウントの書き込み権限を取り消します。これにより、タスクが自動的に回復された場合に、ソースデータが宛先インスタンスのデータを上書きするのを防ぎます。 DTS は、ソースデータベースで定期的に CREATE DATABASE IF NOT EXISTS `test` コマンドを実行して、バイナリログのオフセットを進めます。 DDL 文がターゲットデータベースへの書き込みに失敗した場合、DTS タスクは実行を継続します。失敗した DDL 文については、タスクログを確認する必要があります。タスクログの表示方法の詳細については、「タスクログのクエリ」をご参照ください。 インスタンスが失敗した場合、DTS ヘルプデスクは 8 時間以内にインスタンスの回復を試みます。回復プロセス中に、インスタンスの再起動やパラメーターの調整などの操作が実行される場合があります。
説明 パラメーターが調整されるとき、DTS インスタンスのパラメーターのみが変更されます。データベース内のパラメーターは変更されません。変更される可能性のあるパラメーターには、インスタンスパラメーターの変更で説明されているものが含まれますが、これらに限定されません。
|
PolarDB for MySQL から自己管理 Oracle への移行
次の表に、注意点と制限事項を示します。
タイプ | 説明 |
ソースデータベースの制限 | 帯域幅の要件: ソースデータベースをホストするサーバーには、十分なアウトバウンド帯域幅が必要です。そうでない場合、データ移行速度が影響を受けます。 移行するテーブルには、プライマリキーまたは一意制約が必要であり、キーまたは制約のフィールドは一意である必要があります。そうでない場合、ターゲットデータベースに重複データが表示される可能性があります。 テーブルレベルでデータを移行し、列名のマッピングなどテーブルを編集する必要がある場合、単一のデータ移行タスクで移行できるテーブルは最大 1,000 です。この制限を超えると、タスクの送信後にエラーが報告されます。この場合、テーブルを複数の移行タスクに分割するか、データベース全体を移行するタスクを設定します。 増分移行を実行する場合: バイナリログを有効にし、`loose_polar_log_bin` パラメーターを on に設定する必要があります。そうしないと、事前チェックでエラーが報告され、データ移行タスクを開始できません。バイナリログを有効にしてパラメーターを変更する方法の詳細については、「バイナリログを有効にする」および「パラメーターの変更」をご参照ください。
説明 PolarDB for MySQL クラスターのバイナリログを有効にすると、ストレージ領域が消費され、ストレージ料金が発生します。 PolarDB for MySQL クラスターのバイナリログは、少なくとも 3 日間保持する必要があります。7 日間の保持期間を推奨します。そうしないと、DTS がバイナリログを取得できず、タスクが失敗する可能性があります。極端な場合、これはデータの不整合やデータ損失につながる可能性があります。DTS の要件よりも短いバイナリログ保持期間によって引き起こされた問題は、DTS サービスレベルアグリーメント (SLA) の対象外です。
説明 PolarDB for MySQL クラスターのバイナリログの保持期間を設定する方法の詳細については、「保持期間の変更」をご参照ください。
ソースデータベースの操作上の制限: スキーマ移行および完全なデータ移行中は、データベースまたはテーブルスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ移行タスクは失敗します。
説明 完全なデータ移行中、DTS はソースデータベースをクエリします。これによりメタデータロックが作成され、ソースデータベースでの DDL 操作がブロックされる可能性があります。 完全なデータ移行のみを実行する場合は、ソースインスタンスに新しいデータを書き込まないでください。そうしないと、ソースと宛先の間でデータの不整合が発生します。リアルタイムのデータ整合性を維持するには、スキーマ移行、完全なデータ移行、および増分データ移行を選択します。
|
注意事項 | DTS は、ソース PolarDB for MySQL インスタンスの読み取り専用ノードの移行をサポートしていません。 DTS は、ソース PolarDB for MySQL インスタンスからの OSS 外部テーブルの移行をサポートしていません。 DTS は、完全なデータ移行中のデータベースインスタンスのプライマリ/スタンバイスイッチオーバーシナリオをサポートしていません。このようなシナリオでは、移行タスクを速やかに再設定してください。 複数のテーブルのマージなど、一時テーブルを使用するオンライン DDL 操作がソースデータベースで実行されると、ターゲットデータベースでデータが失われたり、移行インスタンスが失敗したりする可能性があります。 移行中にプライマリキーまたは一意キーの競合が発生した場合: データ移行を実行する前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。また、オフピーク時にデータ移行を実行することをお勧めします。そうしないと、DTS は完全なデータ移行中にソースデータベースとターゲットデータベースの両方で読み取りおよび書き込みリソースを消費し、データベースの負荷が増加する可能性があります。 完全なデータ移行には同時 INSERT 操作が含まれるため、ターゲットデータベースでテーブルの断片化が発生します。その結果、完全移行が完了した後、ターゲットデータベースのテーブルストレージ領域はソースインスタンスよりも大きくなります。 FLOAT または DOUBLE データ型の列の移行精度がビジネス要件を満たしているかどうかを確認します。DTS は、ROUND(COLUMN,PRECISION) を使用してこれらの列の値を読み取ります。精度を明示的に定義しない場合、DTS は FLOAT にはデフォルトの精度 38 を、DOUBLE には 308 を使用します。 DTS は 7 日以内に失敗したタスクの回復を試みます。したがって、ビジネスを宛先インスタンスに切り替える前に、タスクを終了またはリリースする必要があります。または、revoke コマンドを使用して、DTS が宛先インスタンスへのアクセスに使用するデータベースアカウントの書き込み権限を取り消します。これにより、タスクが自動的に回復された場合に、ソースデータが宛先インスタンスのデータを上書きするのを防ぎます。 DTS は、ソースデータベースで定期的に CREATE DATABASE IF NOT EXISTS `test` コマンドを実行して、バイナリログのオフセットを進めます。 インスタンスが失敗した場合、DTS ヘルプデスクは 8 時間以内にインスタンスの回復を試みます。回復プロセス中に、インスタンスの再起動やパラメーターの調整などの操作が実行される場合があります。
説明 パラメーターが調整されるとき、DTS インスタンスのパラメーターのみが変更されます。データベース内のパラメーターは変更されません。変更される可能性のあるパラメーターには、インスタンスパラメーターの変更で説明されているものが含まれますが、これらに限定されません。
|
特殊なケース | 自己管理 Oracle データベースが Real Application Clusters (RAC) アーキテクチャを使用し、Alibaba Cloud VPC に接続する必要がある場合、各ノードの SCAN IP アドレスと仮想 IP アドレス (VIP) の両方を VPC に接続し、ルーティングを設定する必要があります。これにより、DTS タスクが正常に実行されるようになります。詳細については、「オンプレミスデータセンターを Alibaba Cloud に接続するためのシナリオの概要」および「VPN Gateway を介してオンプレミスデータセンターを DTS に接続する」をご参照ください。
重要 DTS コンソールでソース Oracle データベース情報を設定するときは、[データベースアドレス] または [IP アドレス] フィールドに Oracle RAC の SCAN IP アドレスのみを入力します。 |
PolarDB for MySQL から DataHub への移行
次の表に、注意点と制限事項を示します。
タイプ | 説明 |
ソースデータベースの制限 | 移行するテーブルには、プライマリキーまたは一意制約が必要であり、キーまたは制約のフィールドは一意である必要があります。そうでない場合、ターゲットデータベースに重複データが表示される可能性があります。 テーブルレベルでデータを移行し、列名のマッピングなどテーブルを編集する必要がある場合、単一のデータ移行タスクで移行できるテーブルは最大 1,000 です。この制限を超えると、タスクの送信後にエラーが報告されます。この場合、テーブルを複数の移行タスクに分割するか、データベース全体を移行するタスクを設定します。 増分移行を実行する場合: バイナリログを有効にし、`loose_polar_log_bin` パラメーターを on に設定する必要があります。そうしないと、事前チェックでエラーが報告され、データ移行タスクを開始できません。バイナリログを有効にしてパラメーターを変更する方法の詳細については、「バイナリログを有効にする」および「パラメーターの変更」をご参照ください。
説明 PolarDB for MySQL クラスターのバイナリログを有効にすると、ストレージ領域が消費され、ストレージ料金が発生します。 PolarDB for MySQL クラスターのバイナリログは、少なくとも 3 日間保持する必要があります。7 日間の保持期間を推奨します。そうしないと、DTS がバイナリログを取得できず、タスクが失敗する可能性があります。極端な場合、これはデータの不整合やデータ損失につながる可能性があります。DTS の要件よりも短いバイナリログ保持期間によって引き起こされた問題は、DTS サービスレベルアグリーメント (SLA) の対象外です。
説明 PolarDB for MySQL クラスターのバイナリログの保持期間を設定する方法の詳細については、「保持期間の変更」をご参照ください。
ソースデータベースの操作上の制限: スキーマ移行中は、データベースまたはテーブルスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ移行タスクは失敗します。
|
その他の制限 | 初期の完全なデータ同期はサポートされていません。これは、DTS が移行オブジェクトの既存のデータをソース PolarDB for MySQL クラスターから宛先の DataHub インスタンスに移行しないことを意味します。 テーブルレベルのデータ移行のみがサポートされています。 DTS は、ソース PolarDB for MySQL インスタンスの読み取り専用ノードの移行をサポートしていません。 DTS は、ソース PolarDB for MySQL インスタンスからの OSS 外部テーブルの移行をサポートしていません。 DTS は、完全なデータ移行中のデータベースインスタンスのプライマリ/スタンバイスイッチオーバーシナリオをサポートしていません。このようなシナリオでは、移行タスクを速やかに再設定してください。 FLOAT または DOUBLE データ型の列の移行精度がビジネス要件を満たしているかどうかを確認します。DTS は、ROUND(COLUMN,PRECISION) を使用してこれらの列の値を読み取ります。精度を明示的に定義しない場合、DTS は FLOAT にはデフォルトの精度 38 を、DOUBLE には 308 を使用します。 DTS は 7 日以内に失敗したタスクの回復を試みます。したがって、ビジネスを宛先インスタンスに切り替える前に、タスクを終了またはリリースする必要があります。または、revoke コマンドを使用して、DTS が宛先インスタンスへのアクセスに使用するデータベースアカウントの書き込み権限を取り消します。これにより、タスクが自動的に回復された場合に、ソースデータが宛先インスタンスのデータを上書きするのを防ぎます。 インスタンスが失敗した場合、DTS ヘルプデスクは 8 時間以内にインスタンスの回復を試みます。回復プロセス中に、インスタンスの再起動やパラメーターの調整などの操作が実行される場合があります。
説明 パラメーターが調整されるとき、DTS インスタンスのパラメーターのみが変更されます。データベース内のパラメーターは変更されません。変更される可能性のあるパラメーターには、インスタンスパラメーターの変更で説明されているものが含まれますが、これらに限定されません。
|
その他の注意事項 | DTS は、ソースデータベースで定期的に CREATE DATABASE IF NOT EXISTS `test` コマンドを実行して、バイナリログのオフセットを進めます。 |