Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

既知の制限事項

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

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 でサポートされている機能と、対象メジャーバージョンのリリースノートを確認して、対処が必要な非互換性を特定します。
完全なデータダンプフェーズでは、移行元データベースでデータ定義言語（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 の変更を行うことができます。詳細については、トラブルシューティングセクションの次のエントリをご覧ください。
移行元が 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 秒

50K 49 秒

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

既存の移行先インスタンスへの移行の制限事項

既存の移行先インスタンスには、移行先インスタンスの作成時に自動的に設定されるデフォルトのシステムデータベースのみを含めることができます。ユーザーデータ（システムスキーマのテーブルやデータベースなど）を含む既存の移行先インスタンスへの移行はサポートされていません。
既存の移行先インスタンスに余分なデータがあるために問題が発生した場合は、移行先インスタンスのデータベースをクリアして、移行ジョブを再試行してください。既存の移行先インスタンスから余分なデータをクリアするをご覧ください。
移行先インスタンスごとに構成できる移行ジョブは 1 つだけです。
スタンドアロンの Cloud SQL インスタンスにのみ移行できます。外部サーバーレプリカへの移行はサポートされていません。
リードレプリカがある Cloud SQL インスタンスに移行するには、移行元インスタンスでグローバルトランザクション ID（GTID）ロギングが有効になっている必要があります。
Cloud SQL for MySQL リードレプリカを移行先インスタンスとして使用することはできません。
Terraform ユーザーの場合: Database Migration Service は、移行先インスタンスのバックアップと復元の設定を変更します。これにより、移行先インスタンスの設定が、プロビジョニングに使用した Terraform 構成と異なる場合があります。この問題が発生した場合は、問題を診断するの手順に沿って操作してください。

割り当て

同時に最大 2,000 個の接続プロファイルと 1,000 個の移行ジョブを維持できます。移行ジョブ（完了したジョブを含む）と接続プロファイルを削除して、より多くのスペースを確保できます。