概要
データベースを Cloud SQL に移行する場合は、この移行シナリオの既知の制限事項を考慮してください。
MySQL データベースを移行元として使用する場合の既知の制限事項は次のとおりです。
Percona XtraBackup 物理バックアップ ファイルを使用して MySQL 5.6 または MySQL 8.4 への移行は対象外です。
MySQL 8.0 から MySQL 8.4 への移行の場合 __: 8.0 から 8.4 への移行に関するその他の考慮事項は次のとおりです。
- 移行先データベースの
local_infileフラグをONに設定する必要があります。 - 移行元インスタンスの専用移行アカウントに
BACKUP_ADMIN権限を付与することはできません。
- 移行先データベースの
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 のドキュメントをご覧ください。
Private Service Connect インターフェースの接続方法 は、既存の移行先インスタンスへの移行でのみサポートされています。 プライベート IP 接続を使用して新しい移行先インスタンスに移行する場合は、VPC ピアリングを使用します。
データダンプの並列処理に関する考慮事項
データダンプの並列処理を使用すると、高性能なダンプメカニズムを使用して MySQL データベースから移行できるため、移行速度が大幅に向上します。 データダンプの並列処理を使用する場合は、次の点を考慮してください。
データダンプの並列処理は、現在、MySQL バージョン 5.7 または 8 に移行する場合にのみ使用できます。
データダンプの開始時に、Database Migration Service は移行元データベースを短時間ロックし、書き込みを一時的に使用できなくします。 ロック時間は、移行元データベース内のテーブルの数によって異なります。
テーブル数 おおよそのロック時間 100 1 秒 10K 9 秒 5 万 49 秒
既存の移行先インスタンスへの移行の制限事項
- 既存の移行先インスタンスには、移行先インスタンスの作成時に自動的に設定されるデフォルトのシステム データベースのみを含めることができます。ユーザーデータ（システム スキーマのテーブルやデータベースなど）を含む既存の移行先インスタンスへの移行はサポートされていません。
既存の移行先 インスタンスに余分なデータがあるために問題が発生した場合は、移行先インスタンスのデータベースをクリアして、移行ジョブを再試行してください。 既存の移行先インスタンスから余分なデータをクリアするをご覧ください。
- 移行先インスタンスごとに構成できる移行ジョブは 1 つだけです。
- スタンドアロンの Cloud SQL インスタンスにのみ移行できます。外部サーバー レプリカへの移行はサポートされていません。
- リードレプリカがある Cloud SQL インスタンスに移行するには、移行元インスタンスでグローバル トランザクション ID（GTID）ロギングが有効になっている必要があります。
- Cloud SQL for MySQL リードレプリカを移行先インスタンスとして使用することはできません。
- Terraform ユーザーの場合: Database Migration Service は、移行先インスタンスのバックアップと復元の設定を変更します。これにより、移行先インスタンスの設定が、プロビジョニングに使用した Terraform 構成と異なる場合があります。この問題が発生した場合は、 問題の診断のガイダンスに沿って対応してください。
割り当て
- 同時に最大 2,000 個の接続プロファイルと 1,000 個の移行ジョブを維持できます。この上限に達した後で他の作業を行うには、移行ジョブ（完了したジョブを含む）または接続プロファイルを削除する必要があります。