概要
データベースを Cloud SQL に移行する前に、この移行シナリオの既知の制限事項を考慮してください。
MySQL データベースを移行元として使用する場合の既知の制限事項は次のとおりです。
Percona XtraBackup 物理バックアップ ファイルを使用して MySQL 5.6 または MySQL 8.4 に移行することはできません。
MySQL のメジャー バージョン間で移行する場合（MySQL 8.0 から MySQL 8.4 など）、データ整合性の問題が発生することなくスムーズに移行できるように、互換性のない可能性のある問題に対処する必要があります。
クロス バージョン移行の準備を行う際は、Cloud SQL for MySQL でサポートされている機能と、対象のメジャー バージョンのリリースノートを確認して、対処が必要な非互換性を特定します。
完全なデータダンプ フェーズでは、テーブル定義の変更などのデータ定義言語（DDL）の変更を行わないでください。移行ジョブが CDC フェーズに移行する前に行われた DDL の変更により、移行ジョブが失敗する可能性があります。詳細については、問題の診断:
Table definition has changedエラーをご覧ください。移行元が Amazon RDS MySQL、Amazon Aurora MySQL、または SUPERUSER 権限を付与しない移行元の場合、移行を成功させるには、移行元での短時間の書き込みダウンタイムなど、追加の手順が必要です。詳細については、Amazon RDS 固有と Amazon Aurora 固有のセクションをご覧ください。
バイナリログ ファイルをインスタンスから取得できないため、Database Migration Service は MySQL データベース クラスタの Amazon Aurora リードレプリカ インスタンスからデータを移行できません。詳細については、Amazon Aurora 固有のセクションをご覧ください。
MySQL システム データベースはサーバー移行の一部として移行されないため、ユーザーロールに関する情報は含まれません。
Database Migration Service を使用して移行する場合、特定のデータベース オブジェクト（データベース、テーブル、スキーマなど）を選択することはできません。すべてのデータベースとスキーマのすべてのテーブルが移行されます。ただし、
mysql、performance_schema、information_schema、sysのシステム スキーマは除きます。移行を開始する前に、移行元データベースにこれらのスキーマのテーブルを参照するオブジェクトが含まれていないことを確認してください。そうしないと、移行が失敗し、ERROR 1109 (42S02): Unknown table in <schema name here>メッセージが表示されることがあります。移行元データベースを構成すると問題を診断するをご覧ください。暗号化されたデータベースで、データベース内の情報を復号するために顧客管理の暗号鍵が必要であり、Database Migration Service がその鍵にアクセスできない場合、データベースを移行できません。
Database Migration Service は、暗号化された Amazon Aurora または Amazon RDS データベースからのデータ移行をサポートしています。これらのデータベースは、サービス内で復号を透過的に処理するためです。詳細については、Amazon Aurora リソースの暗号化と Amazon RDS リソースの暗号化をご覧ください。
移行中、移行先の Cloud SQL データベースは読み取り専用モードになります。これは、移行プロセスやデータの完全性を損なう可能性のあるデータベースの変更を防ぐためです。移行先がプロモートされると、書き込み可能になります。
現在、Database Migration Service は MariaDB に対応していません。
バイナリログ形式を設定する必要があります。
ROWバイナリログが他の形式（STATEMENTやMIXEDなど）となるように構成されている場合は、レプリケーションが失敗する可能性があります。たとえば、LOAD DATA IN FILEステートメントを使用します。独自のダンプファイルを使用して継続的移行ジョブを作成する場合は、MySQL バージョン 5.7.36 の
mysqldumpユーティリティを使用しないでください。詳細については、MySQL ドキュメントの バグ #105761 をご覧ください。InnoDB は、Cloud SQL でサポートされている唯一のストレージ エンジンです。MyISAM を使用して移行すると、データに不整合が生じる可能性があり、データの検証が必要になることがあります。MyISAM から InnoDB へのテーブルの変換については、MySQL のドキュメントをご覧ください。
データダンプの並列処理に関する考慮事項
データダンプ並列処理を使用すると、高性能のダンプ メカニズムを使用して MySQL データベースから移行できるため、移行速度が大幅に向上します。データダンプの並列処理を使用する場合は、次の点を考慮してください。
データダンプの並列処理は、現在、MySQL バージョン 5.7 または 8 に移行する場合にのみ使用できます。
データダンプの開始時に、Database Migration Service は移行元データベースを短時間ロックし、書き込みを一時的に使用不可にします。ロックの期間は、ソース データベース内のテーブルの数によって異なります。
テーブル数 おおよそのロック時間 100 1 秒 10K 9 秒 50K 49 秒
既存の宛先インスタンスへの移行の制限事項
- 既存の移行先インスタンスは空であるか、システム構成データのみが含まれている必要があります。ユーザーデータ（テーブルなど）を含む既存の宛先インスタンスへの移行はサポートされていません。
既存の移行先インスタンスに余分なデータがあるために問題が発生した場合は、移行先インスタンスのデータベースをクリアして、移行ジョブを再試行します。既存の移行先インスタンスから余分なデータを消去するをご覧ください。
- 宛先インスタンスごとに構成できる移行ジョブは 1 つだけです。
- 移行できるのは、スタンドアロンの Cloud SQL インスタンスのみです。外部サーバー レプリカへの移行はサポートされていません。
- Private Service Connect が有効になっている Cloud SQL インスタンスへのデータの移行はサポートされていません。
- リードレプリカがある Cloud SQL インスタンスに移行するには、移行元インスタンスでグローバル トランザクション ID（GTID）ロギングが有効になっている必要があります。
- Terraform ユーザーの場合: Database Migration Service は、移行先インスタンスのバックアップと復元の設定を変更します。これにより、宛先インスタンスの設定が、プロビジョニングに使用した Terraform 構成と異なる場合があります。この問題が発生した場合は、問題の診断のガイダンスに沿って対応してください。
割り当て
- 同時に最大 2,000 個の接続プロファイルと 1,000 個の移行ジョブを維持できます。この上限に達した後で他の作業を行うには、移行ジョブ（完了したジョブを含む）または接続プロファイルを削除する必要があります。