概要
データベースを 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 個の移行ジョブを維持できます。この上限に達した後で他の作業を行うには、移行ジョブ（完了したジョブを含む）または接続プロファイルを削除できます。