Cloud SQL 上の MySQL に移行するにはさまざまな方法があります。ソースの移行戦略は、データベースのサイズ、予想されるダウンタイム、移行を実行するエンジニアの経験など、いくつかの要因によって異なります。それでは、最も一般的な移行戦略をいくつか見ていきましょう。

数ギガバイト規模のデータベースや静的データを含むデータベースを移行する場合は、mysqldump ユーティリティを使用したデータベースのダンプを取得するのが最も簡単な方法です。ダンプファイルを Cloud Storage にアップロードし、SQL ダンプファイルを使用したエクスポートとインポートの手順に沿って、Cloud SQL インスタンスにインポートします。

ダンプファイルには論理 SQL ステートメントが含まれているため、このアプローチの利点の 1 つは、ダンプファイルを Cloud Storage に読み込む前に編集できることです。 ただし、Cloud SQL の特定の制限があるため、データのインポートとエクスポートのベスト プラクティスに記載されているように、ダンプファイルにインポートの妨げになるような情報を含めないでください。

MySQL の多数のインスタンスを移行する場合や、大規模な移行を行う場合は、Database Migration Service（DMS）を使用することをおすすめします。MySQL への同種移行と異種移行の両方に対応し、移行先としての SQL Server と PostgreSQL のサポートなど、さまざまな移行パスを提供するサービスです。

ほとんどの中規模から大規模のデータベースについては、DMS を使用して移行するだけで十分です。DMS が適切でない状況としては、大規模なデータベース（数 TB のサイズなど）、またはレプリケーションのノウハウを持ち、ネイティブの MySQL レプリケーションを使用した、よりきめ細かい移行プロセスの制御を希望する MySQL エンジニアがいる場合です。

移行中のダウンタイムの最小化が優先事項であり、経験豊富な MySQL エンジニアがチームに配備されている場合は、ネイティブのバイナリログ ベースのレプリケーションを使用して外部ソース（ES）から複製します。この方法では、Cloud Storage のインポートなどの方法を使用して、データベースのベースライン スナップショットのインポートを利用します。

次に、Cloud SQL インスタンスですでに利用可能な一連の事前作成ストアド プロシージャを使用して、ソース インスタンスからターゲット Cloud SQL インスタンスへの MySQL レプリケーションを構成します。詳しい手順については、カスタム インポートを使用して大規模な外部データベースからのレプリケーションを設定するの記事をご覧ください。

移行にバイナリログ ベースのレプリケーションを使用する際の重要な詳細の 1 つは、移行元インスタンスのバイナリログは、移行先の Cloud SQL インスタンスで不要になるまで使用可能のままであることです。MySQL をオンプレミスまたはセルフマネージドで実行する場合、expire_logs_days などのパラメータを構成してバイナリログのパージを制御できます。ただし、他のクラウド ベンダーのマネージド サービスには、バイナリログの保持に関する独自の制限があります。

たとえば、Amazon リレーショナル データベース　Service（RDS）では、ストアド プロシージャ名 mysql.rds_set_configuration を使用してバイナリログの保持を構成できます。これにより、最大 7 日間保持できます。ほとんどの場合、RDS から Cloud SQL への小規模から中規模の移行には 7 日間で十分です。このような場合、ユーザーは、マネージド RDS レプリカの作成など、詳細に文書化されたプロセスを利用できます。次に何かを「中断」するレプリカの書き込み可能にして行を削除する、ある種の「ポイズン ピル」を挿入するなど、レプリケーションプライマリ上のトランザクションがバイナリログに入り、レプリケーションが中断されます。レプリカがバイナリログをまだ必要としている限り、RDS の自動化によってバイナリログがパージされることはありません（ただし、RDS が壊れたレプリケーション ストリームを「終了」するまでには、全体として 30 日の上限があるようです）。

もう一つの回避策は、mysqlbinlog クライアントを使用してバイナリ中間ログを別の中間 MySQL インスタンスにダウンロードし、バイナリログの早期のパージを防ぎます。たとえば、RDS には mysql.rds_set_configuration という名前のストアド プロシージャがあります。これにより、バイナリログがダウンロードするのに十分な間、ホストに保持される保持期間を時間単位で設定できます。この場合、「Binlog Server」のような MySQL インスタンスのように見えるサーバーは、バイナリログの保存と転送を行うために存在しているため、中間として MySQL インスタンスを立ち上げる必要はありません。

MySQL は、最も普及しているリレーショナル データベース システムの中でも独特な存在であり、複数のプラグイン可能なストレージ エンジンをサポートしています。もともと MySQL は MyISAM という単一のストレージ エンジンをサポートしていましたが、MySQL 8.0 までは、ほとんどのシステム テーブルでこのストレージ エンジンを使用していました。しかし、MyISAM はトランザクションをサポートしていないため、突然のシステム シャットダウンやデータベース クラッシュが発生した場合のクラッシュセーフではありませんでした。

それ以来、InnoDB はクラッシュに強いアーキテクチャとトランザクションのサポートにより、ほとんどの MySQL ユーザー テーブルの事実上のストレージ エンジンになりました。MySQL コミュニティでよく見られるストレージ エンジンは他にもあり、オンプレミスと他のクラウド プロバイダの両方で利用できます。たとえば、次のようなものがあります。

• ARCHIVE - アーカイブ用に高度に圧縮された形式でデータを保存する
• CSV - カンマ区切り形式（CSV）でデータを保存し、一般的なクエリログと遅いクエリログのテーブルのロギングに使用される
• MEMORY - テーブルをメモリに格納する

Cloud SQL の場合、レプリケーションやポイントインタイム リカバリなどの付加価値機能をサポートするには、トランザクションセーフかつクラッシュセーフなストレージ エンジンが必要です。したがって、Cloud SQL に移行するすべてのユーザー テーブルは、移行プロセス中に InnoDB ストレージ エンジンを使用するか、InnoDB に変換する必要があります。

これは、外部ソースから Cloud SQL にネイティブの MySQL レプリケーションを行う場合に特に重要です。Cloud SQL では、ユーザーが CREATE TABLE などのデータ定義言語（DDL）コマンドを使用して Cloud SQL インスタンス上で MyISAM テーブルを直接作成することはできませんが、現在のところ MyISAM テーブルを外部ソースから Cloud SQL に複製することは可能です。

ただし、Cloud SQL にインポートされたこれらの MyISAM テーブルは、後でレプリケーション、ポイントインタイム リカバリ、フェイルオーバーなどのオペレーション中に安定性と信頼性の問題を引き起こす可能性があります。このため、移行を実行する前に、すべての MyISAM ユーザー テーブルを InnoDB に変換することをおすすめします。

次のクエリは、システム以外の MyISAM テーブルを一覧表示します。

MySQL for Cloud SQL はマネージド サービスであるため、ユーザー アカウントには SUPER 権限を使用できません。これは、このような権限を持つ root ユーザーが利用できる MySQL のほとんどのオンプレミス インストールとは異なります。同様に、他のほとんどのクラウド プロバイダは、マネージド MySQL 環境でこの SUPER 権限を提供していません。

Cloud SQL ではどのような状況であれ、前述の SUPER に加えて、FILE と SHUTDOWN など、Google のサービス管理に影響する権限を除き、ユーザーには、MySQL で提供される権限のほとんどが付与される、「root」@「%」 という名前のデフォルトの MySQL ユーザーが与えられます。Cloud SQL で提供される使用権限の詳細については、MySQL ユーザーに関するドキュメントをご覧ください。

移行を準備するときに、移行元インスタンスのすべてのユーザー アカウントを確認します。たとえば、各ユーザーに SHOW GRANTS コマンドを実行して現在の権限セットを確認し、Cloud SQL で制限されている権限があるかどうかを調べます。同様に、Percona の pt-show-grants ツールでも付与を一覧表示できます。

Cloud SQL のユーザー権限の制限は、DEFINER 属性を持つデータベース オブジェクトを移行するときの移行に影響する可能性があります。これは、ストアド プロシージャ、トリガー、ユーザー定義関数、ビューなどがこれに該当します。移行元インスタンスのデータベース オブジェクトの定義者が、Cloud SQL でサポートされていない権限を持つユーザーである場合、移行中または移行後に問題が発生する可能性があります。

たとえば、ストアド プロシージャには、Cloud SQL で許可されていないグローバル変数を変更するなどの SQL コマンドを実行するための、スーパー特権の定義元が含まれている場合があります。このような場合は、別の移行ステップとして、ストアド プロシージャ コードの書き換えや、ストアド プロシージャなどのテーブル以外のオブジェクトの移行が必要になることがあります。

このドキュメントには、DEFINER 句を伴うメタデータを含む MySQL のインポートおよび移行ジョブというタイトルのセクションがあり、データベース オブジェクトの DEFINER 句に関連する別の問題について説明しています。

前述のユーザー権限の制限により、ユーザーは SET GLOBAL コマンドをネイティブに呼び出してデータベース パラメータを変更することができません。その代わり、Cloud SQL では、事前定義された一連の「フラグ」が用意されています。フラグは、UI コンソール、gcloud CLI、REST API を使用してパラメータを変更できます。

MySQL 用にサポートされている Cloud SQL フラグの全一覧については、一般公開ドキュメントのサポートされているフラグというセクションをご覧ください。Cloud SQL に移行する前に、サポートされているフラグと移行元の環境で現在使用されているフラグの一覧をご確認ください。たとえば、ソース インスタンスと同様の CPU とメモリ設定でテスト用 Cloud SQL インスタンスを作成し、ソース インスタンスと Cloud SQL インスタンスの両方で [グローバル変数の表示] を実行して、違いを比較することをおすすめします。

オンプレミスやクラウド プロバイダと Cloud SQL for MySQL で設定が異なる可能性がある共通フラグには、次のものがあります。

• 文字セットと照合設定（character_set_server や collation_server など）。デフォルトはインストールによって異なり、ストレージとパフォーマンスに違いが生じることがあります。たとえば、latin1 と utf8 などです。
• binlog_format などのバイナリログ設定。Cloud SQL は現在、バイナリログでは行ベースのロギングのみをサポートしています。
• 詳細レプリケーション設定。たとえば、Cloud SQL は replicate-do-table、replicate-do-db などのレプリケーション フィルタ パラメータをサポートしていません。
• InnoDB の詳細設定。Cloud SQL では、innodb_buffer_pool_size の変更による InnoDB バッファプールのサイズ変更など、InnoDB 関連のほとんどのパラメータを変更できます。ただし、Cloud SQL で変更できないきめ細かい InnoDB 設定や、オンプレミスや他のクラウド プロバイダとは異なるデフォルト設定が存在する場合があります。