データベース

Database Migration Service を使用した MySQL データベースの移行に伴う準備作業

2020年12月24日

Google Cloud Japan Team

※この投稿は米国時間 2020 年 12 月 12 日に、Google Cloud blog に投稿されたものの抄訳です。

Google は先日、Google Cloud へのデータベースの移行を容易にする、新しい Database Migration Service（DMS）を発表しました。DMS は使いやすいサーバーレス移行ツールで、Cloud SQL for MySQL（プレビュー版）と Cloud SQL for PostgreSQL（希望者にプレビュー版を提供）へのデータベースの移行を最小限のダウンタイムで実現します。

本投稿では、DMS を使用した MySQL データベースの移行に伴う準備作業についてご説明します。

サポートされている移行の種類

移行について検討する際、オフライン移行、または継続的なデータレプリケーションを使用してダウンタイムを最小限に抑えた移行が一般的に行われます。MySQL 向けの Database Migration Service（DMS）はその両方に対応しており、1 回限りの移行または継続的な移行を選択できます。

バージョンサポート

MySQL 向けの DMS は、移行元（ソース）データベースのバージョン 5.5、5.6、5.7、8.0 をサポートし、同じバージョンまたは 1 つ上のメジャーバージョンへの移行をサポートしています。

各バージョンの考えられる移行パスは次のとおりです。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Screen_Shot_2020-12-10_at_1.51.53_PM.max-1.max-1000x1000.png

移行元のデータベースと違うバージョンのデータベースに移行する場合、移行元データベースと移行先データベースの sql_mode フラグの値が異なる場合があります。SQL モードは、MySQL がサポートする SQL 構文と、MySQL が実行するデータ検証チェックのタイプを定義します。たとえば、デフォルトの SQL モードの値は MySQL 5.6 と 5.7 では異なります。

そのため、デフォルトの SQL モードが設定されている場合、0000-00-00 のような日付はバージョン 5.6 では有効ですが、バージョン 5.7 では無効となります。さらに、デフォルトの SQL モードでは、バージョン 5.6 と 5.7 の間で GROUP_BY 動作が変更されています。sql_mode フラグの値が移行先データベースで適切に設定されていることを確認するようにしましょう。

sql_mode フラグやさまざまな値の意味について詳しくは、MySQL のドキュメントをご覧ください。

前提条件

移行を進めるにあたり、事前にいくつかの前提条件を満たす必要があります。データベースを移行するためのすべての手順がクイックスタートに示されていますが、本投稿では移行元データベースの構成に必要な作業について取り上げます。また、接続プロファイルの設定と接続の構成についても簡単にご説明します。

移行元データベースの構成

移行元データベースを構成するには、いくつかの手順を踏む必要があります。現在の構成によっては、必要な構成を適用するために移行元データベースの再起動が必要になる場合がありますのでご注意ください。

DDL 書き込みオペレーションの停止

移行元データベースから移行先データベースにデータ移行を開始する前に、ソースで実行されているデータ定義言語（DDL）の書き込みオペレーションをすべて停止する必要があります。こちらのスクリプトを使用して、過去 24 時間に DDL オペレーションが実行されたかどうか、または実行中のアクティブなオペレーションがあるかどうかを確認できます。

server_id システム変数

移行元データベースのインスタンスに設定する特に重要な項目の一つが server_id システム変数です。現在の値が不明な場合は、mysql クライアントで次のコマンドを実行して確認できます。

読み込んでいます...

表示される値は、1 以上の値になっているはずです。server_id の構成方法がわからない場合は、こちらのページをご参照ください。この値は動的に変更できますが、変数を変更してもサーバーを再起動しない限り、レプリケーションは自動的に開始されません。

グローバルトランザクション ID（GTID）ログ

gtid_mode フラグは、グローバルトランザクション ID ログを有効にするかどうか、およびログに含めることができるトランザクションのタイプを制御します。ON_PERMISSIVE と OFF_PERMISSIVE は DMS でサポートされていないため、gtid_mode が ON または OFF に設定されていることを確認してください。

移行元データベースの gtid_mode を確認するには、以下のコマンドを実行します。

読み込んでいます...

gtid_mode の値が、ON_PERMISSIVE または OFF_PERMISSIVE に設定されている場合、値を変更する際は一度に 1 ステップしか実行できませんのでご注意ください。たとえば、gtid_mode が ON_PERMISSIVE に設定されている場合、この値を ON または OFF_PERMISSIVE に変更できますが、1 ステップで OFF に設定することはできません。

gtid_mode の値は、サーバーを再起動せずに動的に変更できます。これは全体的に変更することをおすすめします。全体的に変更しないと、変更が発生したセッションでのみ有効となり、DMS を使用して移行を開始したときに効果を発揮しません。gtid_mode について詳しくは、MySQL のドキュメントをご覧ください。

データベースのユーザーアカウント

移行元データベースへの接続に使用しているユーザーアカウントには、以下のグローバル権限が必要です。

EXECUTE
RELOAD
REPLICATION CLIENT
REPLICATION SLAVE
SELECT
SHOW VIEW

移行に特化した特定のユーザーを作成することをおすすめします。また、このデータベースホストへのアクセスは一時的に % のままにしておくことができます。ユーザーの作成に関する詳細は、こちらをご覧ください。

移行元データベースへの接続に使用するユーザーアカウントのパスワードは、32 文字以内にする必要があり、これは MySQLreplication 固有の問題となります。MySQL のユーザーパスワードの長さ制限に関する詳細については、MySQL バグ #43439 をご覧ください。

DEFINER 句

MySQL の移行ジョブはユーザーデータを移行しないため、ユーザーが DEFINER 句を使って定義したメタデータを含むソースを新しい Cloud SQL レプリカで呼び出すと、そのユーザーがまだ存在せずエラーとなります。

次のクエリを使用して、メタデータに存在する DEFINER 値を特定できます。root%localhost またはターゲットインスタンスに存在しないユーザーのエントリがあるかどうかを確認します。

読み込んでいます...

移行元データベースにこのメタデータが含まれている場合は、以下のいずれかを行います。

移行ジョブを設定する前に、ソースの MySQL インスタンスの DEFINER 句を INVOKER に変更します。
移行ジョブを開始する前に、ターゲット Cloud SQL インスタンスにユーザーを作成します。

移行ジョブを作成します。ただし、まだ開始しないでください。[Create & Start] ではなく [Create] を選択します。
Cloud SQL API または UI を使用して、移行元 MySQL インスタンスからターゲット Cloud SQL インスタンスにユーザーを作成します。
移行ジョブリストか、ジョブのページから移行ジョブを開始します。

バイナリログ

移行元データベースでバイナリログを有効にして、最低でも 2 日保持されるように設定します。ログの位置が失われる可能性を最小限にするには 7 日をおすすめします。バイナリログについて詳しくは、MySQL のドキュメントをご覧ください。

InnoDB

システムデータベース内のテーブルを除くすべてのテーブルで、InnoDB ストレージエンジンを使用します。InnoDB への変換についてさらに詳しい情報が必要な場合は、MyISAM から InnoDB へのテーブルの変換に関するドキュメントをご参照ください。

接続プロファイルの設定

接続プロファイルには、データソースへの接続に必要なすべての情報が含まれています。独自に作成することも、特定の移行ジョブのコンテキストで作成することも可能です。ソース接続プロファイルを独自に作成すると、ソースのアクセス情報を持っているユーザーと移行ジョブを作成したユーザーが異なる場合に役立ちます。また、複数の移行ジョブでソース接続プロファイル定義を再利用することもできます。

接続プロファイルとその設定方法について詳しくは、こちらのドキュメントをご覧ください。