Cloud SQL for MySQL への移行に関するベスト プラクティス
MySQL から Cloud SQL for MySQL へのデータベース移行の計画と実行には、移行元のデータベースの複雑さ、移行する必要があるデータ量、許容できるダウンタイムのレベルなど、多くの考慮事項があります。これらの考慮事項の 1 つは、MySQL データベースのソース インスタンスです。MySQL のソース インスタンスは、次のいずれかの方法でホストできます。
- AWS や Azure など、別のクラウド プロバイダでホストされている MySQL インスタンス
- 独自のデータセンターまたはオフィスのサーバー（オンプレミス）でホストされている MySQL インスタンス
この記事は、この両方のシナリオに該当します。
概要
データベースの移行には主に 2 つのタイプがあります。MySQL を実行している移行元インスタンス、またはフロントエンドなどの MySQL を含むデータベース（AWS Aurora for MySQL など）から、クラウド内の MySQL または Cloud SQL for MySQL への移行は、同種移行と考えられます。移行元インスタンスが PostgreSQL、SQL Server、Oracle などのデータベースとは異なるデータベースで実行されている場合、このデータベースは異種移行と呼ばれます。
この記事では、同種移行に焦点を当てます。これは、通常、Cloud SQL for MySQL に該当するためです。特に、この記事では、Cloud SQL for MySQL への移行方法、ストレージ エンジンに関する考慮事項、ユーザー権限、MySQL フラグについて説明します。ただし、ヒントと手順の多くは、異種移行にも当てはまります。
Cloud SQL for MySQL に移行する方法
Cloud SQL 上の MySQL に移行するには、さまざまな方法があります。特定の移行元の移行戦略は、データベースのサイズ、ダウンタイムの期待値、移行を行うエンジニアの経験など、いくつかの要因によって決まります。最も一般的な移行戦略をいくつか確認しましょう。
Cloud Storage のインポート
数ギガバイト規模のデータベースや静的データを含むデータベースを移行する場合は、mysqldump ユーティリティを介してデータベースのダンプを取得するのが最も簡単な方法です。ダンプファイルを Cloud Storage にアップロードし、SQL ダンプファイルを使用したエクスポートとインポートの手順に沿って、Cloud SQL インスタンスにインポートします。
ダンプファイルには論理 SQL ステートメントが含まれているため、このアプローチの利点の 1 つは、ダンプファイルを Cloud Storage に読み込む前に編集できることです。 ただし、Cloud SQL の特定の制限があるため、データのインポートとエクスポートのベスト プラクティスに記載されているように、ダンプファイルにインポートの妨げになるような情報を含めないでください。
Database Migration Service（DMS）
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 Relational Database 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 インスタンスの両方で SHOW GLOBAL VARIABLES を実行し、違いを比較することをおすすめします。
オンプレミスまたはクラウド プロバイダで 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 のきめ細かい設定、またはオンプレミスや他のクラウド プロバイダと異なるデフォルト値が設定されているものもあります。
関連プロダクトとサービス
Google Cloud は、オンプレミスのデータセンターの廃止から SaaS アプリケーションの実行、基幹業務システムの移行まで、お客様のビジネスニーズに合わせて構築されたマネージド MySQL データベースを提供します。
