既知の制限事項

データベースを Cloud SQL に移行する前に、この移行シナリオの既知の制限事項を考慮してください。

注: Google Cloud Migration Center を使用して、機能サポートのギャップを検出することもできます。Migration Center のドキュメントのデータベースを検出してインポートするをご覧ください。

MySQL データベースを移行元として使用する場合の既知の制限事項は次のとおりです。

• 暗号化されたデータベースを移行するには、Database Migration Service に暗号鍵を指定する必要があります。Database Migration Service は、暗号化された Amazon Aurora データベースまたは Amazon RDS データベースからのデータの移行をサポートしています。これらのデータベースは、サービス内で復号を透過的に処理するためです。詳細については、Amazon Aurora リソースの暗号化、Amazon RDS リソースの暗号化、顧客管理の暗号鍵（CMEK）を構成するをご覧ください。

• Percona XtraBackup 物理バックアップ ファイルを使用した MySQL 5.6、MySQL 8.4、MySQL 9.7 への移行はサポートされていません。

• MySQL 8.0 から MySQL 8.4 への移行、MySQL 8.4 から MySQL 9.7 への移行:

  • 移行先データベースでは、local_infile フラグを ON に設定する必要があります。
  • 移行元インスタンスの専用移行アカウントに BACKUP_ADMIN 権限を付与することはできません。

  これらの考慮事項については、ソース データベースを構成するページなどの関連セクションでも説明しています。

• MySQL のメジャー バージョン間で移行する場合（MySQL 8.0 から MySQL 8.4 への移行など）、データの整合性の問題が発生することなくスムーズに移行できるように、互換性のない問題に対処する必要があります。

  クロスバージョン移行の準備を行う際は、Cloud SQL for MySQL でサポートされている機能と、対象メジャー バージョンのリリースノートを確認して、対処が必要な非互換性を特定します。

  • MySQL 9.7
  • MySQL 8.4
  • MySQL 8.0
  • MySQL 5.7

• 完全なデータダンプ フェーズでは、ソース データベースに対してデータ定義言語（DDL）オペレーション（ALTER TABLE、DROP TABLE、TRUNCATE TABLE など）を実行できません。フルダンプ フェーズ中にこれらのオペレーションを実行すると、メタデータのデッドロックが発生し、移行プロセスが失敗する（Table definition has changed エラーが発生する）か、応答を停止する（ERROR: While 'Loading data': Dump timeout や MySQL Error 2013 (HY000): Lost connection to MySQL server during query などのタイムアウト エラーが報告される）可能性があります。CDC フェーズ中に、ソース データベースで DDL の変更を実行できます。詳細については、トラブルシューティング セクションの次のエントリをご覧ください。

  • Table definition has changed
  • While 'Loading data': dump timeout
  • MySQL Error 2013: Lost connection to MySQL server during query
  • Timeout waiting for no write traffic on the source: context deadline exceeded

• 移行元が Amazon RDS MySQL、Amazon Aurora MySQL、または SUPERUSER 権限を付与しない移行元の場合、移行を正常に完了するには、移行元での書き込みの短いダウンタイムなど、追加の手順が必要です。詳細については、Amazon RDS のソース データベースを構成すると Amazon Aurora 固有のセクションをご覧ください。

• Database Migration Service は、Amazon Aurora リードレプリカ インスタンスまたは Oracle Cloud Infrastructure（OCI）MySQL リードレプリカ インスタンスからデータを移行できません。これは、インスタンスからバイナリログ ファイルを取得できないためです。Amazon Aurora の詳細については、Amazon Aurora 固有のセクションをご覧ください。

• セルフマネージド MySQL リードレプリカから移行する場合、GTID はサポートされません。バイナリログ ファイルと位置ベースのレプリケーションを使用する必要があります。詳細については、移行の種類とフェーズをご覧ください。

• MySQL システム データベースはサーバー移行の一部として移行されないため、ユーザー アカウント、ログイン、ロールに関する情報は含まれません。

• 移行する特定のデータベースを選択できますが、Database Migration Service を使用して移行する場合、データベース内の個々のデータベース オブジェクト（特定のテーブル、ビュー、ストアド プロシージャなど）をフィルタリングまたは選択することはできません。選択した各データベースのすべての InnoDB テーブルとオブジェクトが移行されます。ただし、次のシステム スキーマは除きます。mysql、performance_schema、information_schema、sys。移行を開始する前に、ソース データベースに、これらのスキーマのテーブルを参照するオブジェクトが含まれていないことを確認してください。そうしないと、移行が失敗し、ERROR 1109 (42S02): Unknown table in <schema name here> メッセージが表示されることがあります。ソース データベースを構成すると問題の診断をご覧ください。

• 移行中、移行先の Cloud SQL データベースは読み取り専用モードになります。これにより、移行プロセスやデータの完全性を損なう可能性のあるデータベースの変更を防ぎます。移行先がプロモートされると、書き込み可能になります。

• Database Migration Service は MariaDB に対応していません。

• バイナリログ形式を ROW に設定する必要があります。バイナリログが他の形式（STATEMENT や MIXED など）となるように構成されている場合は、レプリケーションが失敗する可能性があります。たとえば、LOAD DATA IN FILE ステートメントを使用します。

  詳しくは、STATEMENT 形式または MIXED 形式の制限事項をご覧ください。

• 独自のダンプファイルを使用して継続的な移行ジョブを作成する場合は、MySQL バージョン 5.7.36 の mysqldump ユーティリティを使用しないでください。詳細については、MySQL のドキュメントのバグ #105761 をご覧ください。

• InnoDB は、Cloud SQL で対応している唯一のストレージ エンジンです。MyISAM を使用して移行すると、データに不整合が生じる可能性があり、データの検証が必要になることがあります。テーブルを MyISAM から InnoDB に変換する方法については、MySQL のドキュメントをご覧ください。

• Private Service Connect インターフェースの接続方法は、既存の移行先インスタンスへの移行でのみサポートされています。プライベート IP 接続を使用して新しい宛先インスタンスに移行する場合は、VPC ピアリングを使用します。

データダンプの並列処理に関する考慮事項

データダンプ並列処理を使用すると、高性能のダンプ メカニズムを使用して MySQL データベースから移行できるため、移行速度が大幅に向上します。データダンプの並列処理を使用する場合は、次の点を考慮してください。

• データダンプの並列処理は、MySQL バージョン 5.7、8.0、8.4、9.7 に移行する場合にのみ使用できます。

• データダンプの開始時に、Database Migration Service は移行元データベースを一時的にロックし、書き込みを一時的に利用できなくします。ロック期間は、ソース データベース内のテーブルの数によって異なります。

  テーブル数	おおよそのロック時間
  100	1 秒
  10K	9 秒
  5 万	49 秒

注: 移行元データベースをロックできないシナリオでは、代わりにリードレプリカを移行元データベースとして使用します。Amazon RDS のリードレプリカからの移行については、RDS MySQL からの移行をご覧ください。

既存の移行先インスタンスへの移行に関する制限事項

• 既存の移行先インスタンスには、移行先インスタンスの作成時に自動的に設定されるデフォルトのシステム データベースのみを含めることができます。ユーザーデータ（システム スキーマのテーブルやデータベースなど）を含む既存の移行先インスタンスへの移行はサポートされていません。

  既存の移行先インスタンスに余分なデータがあるために問題が発生した場合は、移行先インスタンスのデータベースを消去して、移行ジョブを再試行します。既存の宛先インスタンスから余分なデータを消去するをご覧ください。

• 移行ジョブは、移行先インスタンスごとに 1 つだけ構成できます。
• 移行できるのは、スタンドアロンの Cloud SQL インスタンスのみです。外部サーバー レプリカへの移行はサポートされていません。
• リードレプリカがある Cloud SQL インスタンスに移行するには、移行元インスタンスでグローバル トランザクション ID（GTID）ロギングを有効にする必要があります。
• Cloud SQL for MySQL リードレプリカを移行先のインスタンスとして使用することはできません。
• Terraform ユーザーの場合: Database Migration Service は、移行先インスタンスのバックアップと復元の設定を変更します。これにより、宛先インスタンスの設定が、プロビジョニングに使用した Terraform 構成と異なる場合があります。この問題が発生した場合は、問題の診断のガイダンスに沿って対応してください。

割り当て

• 同時に最大 2,000 個の接続プロファイルと 1,000 個の移行ジョブを維持できます。スペースを増やすには、移行ジョブ（完了したものを含む）と接続プロファイルを削除します。