ソースを構成する

MySQL   |  PostgreSQL   |  PostgreSQL から AlloyDB

概要

Database Migration Service は、移行元データベースから Cloud SQL 移行先データベースへの 1 回限りの移行と継続的な移行をサポートしています。

MySQL でサポートされている移行元のデータベースには次のものが含まれます。

• Amazon RDS 5.6、5.7、8.0、8.4
• セルフマネージド（オンプレミス、またはお客様が完全に管理するクラウド VM 上）の MySQL 5.5、5.6、5.7、8.0、8.4
• Cloud SQL for MySQL 5.6、5.7、8.0、8.4
• Amazon Aurora 5.6、5.7、8.0、8.4
• Microsoft Azure Database for MySQL 5.7、8.0、8.4

MySQL 8.0 のソースの場合、Database Migration Service はマイナー バージョンの 8.0.18、8.0.26、8.0.27、8.0.28、8.0.30、8.0.31、8.0.32、8.0.33、8.0.34、8.0.35、8.0.36、8.0.37、 8.0.39、8.0.40、8.0.41、8.0.42、8.0.43 もサポートします。

移行元データベースを構成する手順は次のとおりです。

1. Cloud SQL ソースの場合: プライベート IP 接続を使用する Cloud SQL インスタンスから、 RFC 1918 以外のアドレス IP 範囲を使用する Cloud SQL インスタンスに移行する場合は、RFC 1918 以外の範囲を移行元 Cloud SQL インスタンスのネットワーク構成に追加します。 Cloud SQL ドキュメントの承認済みネットワークを構成する をご覧ください。
2. 移行元データベースから移行先データベースにデータを移行する前に、 フルダンプ フェーズでデータ定義言語（DDL）の書き込みオペレーションをすべて停止していることを確認します。 スクリプトを使用して、DDL オペレーションが停止していることを確認できます。移行が CDC フェーズに入ったら、DDL オペレーションを再開できます。
3. 移行元データベースに、DEFINER 句で定義されたメタデータが 含まれていないことを確認します。 DEFINER 句を含むメタデータを含む MySQL 移行ジョブを作成して実行するをご覧ください。
4. 移行元データベースに、 mysql、performance_schema、 information_schema、ndbinfo、または sys システム スキーマのテーブルを参照するオブジェクトが含まれている場合は、レプリカ データベースにもこれらのシステム スキーマ テーブルが含まれていることを確認します。

   レプリカ データベースにこれらのテーブルがない場合、移行ジョブが 失敗し、 Unknown table in system schema エラーが発生する可能性があります。

5. server-id オプションを 1 以上の値に設定する必要があります。詳細については、レプリケーションとバイナリログのオプションと変数をご覧ください。
6. GTID_MODE を ON または OFF に設定して、グローバル トランザクション ID（GTID）ロギングを構成します。 GTID_MODE の値 ON_PERMISSIVE はサポートされていません。

   使用する値は、移行要件によって異なります。

   • リードレプリカが有効になっている既存の移行先インスタンスに移行する場合は、GTID_MODE を ON に設定します。
   • 手動ダンプを使用してデータを移行する場合は、 GTID_MODE を ON に設定します。
   GTID_MODE の詳細については、 グローバル トランザクション ID システム変数をご覧ください。

7. 移行元データベースへの接続に使用するユーザー アカウントを、どこからの接続でも受け入れるように構成する必要があります（ホスト = %）。後のステップで、アクセスをこのユーザーに制限できます。

   データベースの他の側面を危険にさらす可能性を抑えるには、この目的のために別のアカウントを作成することをおすすめします。

   移行とダンプの組み合わせは 4 種類あります。

   • タイプ 1: 継続的な移行とマネージド ダンプ
   • タイプ 2: 継続的な移行と手動ダンプ
   • タイプ 3: 1 回限りの移行とマネージド ダンプ
   • タイプ 4: 1 回限りの移行と手動ダンプ

   移行とダンプの組み合わせの種類ごとの権限を以下のタブに示します。

   タイプ 1

   構成するユーザー アカウントに次の権限が必要です。

   • REPLICATION SLAVE
   • EXECUTE
   • SELECT
   • SHOW VIEW
   • REPLICATION CLIENT
   • RELOAD
   • TRIGGER
   • （Amazon RDS と Amazon Aurora からの移行の場合のみ） LOCK TABLES

   MySQL バージョン 8.0 以降: 移行アカウントに BACKUP_ADMIN 権限がないことを確認します。

   権限の詳細については、MySQL によって提供される権限をご覧ください。ユーザー アカウントの詳細については、MySQL ユーザー アカウントの形式をご覧ください。

   タイプ 2

   構成するユーザー アカウントに次の権限が必要です。

   • REPLICATION SLAVE
   • EXECUTE

   権限の詳細については、MySQL によって提供される権限をご覧ください。ユーザー アカウントの詳細については、MySQL ユーザー アカウントの形式をご覧ください。

   タイプ 3

   構成するユーザー アカウントに次の権限が必要です。

   • SELECT
   • SHOW VIEW
   • TRIGGER
   • （Amazon RDS と Amazon Aurora からの移行の場合のみ） LOCK TABLES
   • （GTID_MODE = ON 設定のソースからの移行の場合のみ）RELOAD

   MySQL バージョン 8.0 以降: 移行アカウントに BACKUP_ADMIN 権限がないことを確認します。

   権限の詳細については、MySQL によって提供される権限をご覧ください。ユーザー アカウントの詳細については、MySQL ユーザー アカウントの形式をご覧ください。

   タイプ 4

   権限は必要ありません。

   権限の詳細については、MySQL によって提供される権限をご覧ください。ユーザー アカウントの詳細については、MySQL ユーザー アカウントの形式をご覧ください。

8. バイナリログを構成する前に、次のことを確認してください。
   • 移行元データベースでバイナリログを有効にする。
   • 行ベースのバイナリ ロギングを使用する。
   • データベースの移行をサポートするのに十分な期間、バイナリログを保持する。通常、1 週間で十分です。

   バイナリログを構成するには、ソースのセクションを開きます。

   Cloud SQL for MySQL

   Cloud SQL for MySQL では、ポイントインタイム リカバリ（PITR）を使用すると、バイナリ ロギングが自動的に有効になります 。ログ形式 と保持期間は、Cloud SQL で使用可能なシステム フラグで構成できます:

   1. インスタンスで PITR を有効にして、バイナリ ロギングを有効にします。Cloud SQL ドキュメントの ポイントインタイム リカバリ（PITR）をご覧ください。
   2. Cloud SQL フラグを使用して、ロギング構成を調整します。 詳細については、Cloud SQL ドキュメントの データベース フラグの構成 をご覧ください。
      1. ログ形式については、設定を調整する必要はありません。 Cloud SQL for MySQL は、binlog_format フラグを ROW に自動的に設定します。
      2. ログの有効期限には、次のいずれかのフラグを使用します。
         • MySQL 5.6 ～ 5.7: expire_logs_days
         • MySQL 8.0 以降: expire_logs_days、binlog_expire_logs_seconds

   セルフホスト型 MySQL

   MySQL のバージョンに応じて、レプリケーションが行われるのに十分な期間を指定します。

   • MySQL 5.5 ～ 5.7: expire_logs_days
   • MySQL 8.0: expire_logs_days、binlog_expire_logs_seconds

   Microsoft Azure Database for MySQL

   Microsoft Azure Database for MySQL では、バイナリ ロギングがデフォルトで有効になっています。有効にする必要はありません。詳細については、Microsoft のドキュメントをご覧ください。

   次の必須パラメータを構成します。

   1. binlog_expire_logs_seconds には、データベースの移行をサポートするのに十分な期間を設定します。

      詳細については、Azure Database for PostgreSQL でサーバー パラメータを構成すると、Microsoft ドキュメントのbinlog_expire_logs_seconds パラメータをご覧ください。

   2. サーバーを再起動して、変更を反映させます。

   Amazon RDS

   Amazon RDS の場合、パラメータ グループでbinlog retention hours パラメータを構成して、行ベースの構成を設定します。このパラメータは、Amazon RDS がバイナリログ ファイルを保持する時間数を指定するために使用されます。

   Amazon RDS でバイナリログの保持期間を設定するには、mysql.rds_set_configuration ストアド プロシージャを使用して、レプリケーションが行われるのに十分な期間を指定します。次に例を示します。

   call mysql.rds_set_configuration('binlog retention hours',168);

   このパラメータに設定できる最大値は 168 時間（7 日）です。

   Amazon Aurora

   Amazon Aurora の場合、次の操作を行います。

   1. MySQL データベースでバイナリ ロギングを有効にします。
   2. バイナリログの保持期間を設定します。

      mysql> call mysql.rds_set_configuration('binlog retention hours', 168);

      このコマンドを入力するのは、7 日間（168 時間）以上にわたってバイナリログを保持できるようにシステムを構成することで、適切なレプリケーションを維持するためです。
   3. サーバーを再起動して、変更を反映させます。
9. （システム データベース内のテーブルを除く）すべてのテーブルで InnoDB ストレージ エンジンを使用していること。

   InnoDB の詳細については、InnoDB ストレージ エンジンをご覧ください。InnoDB への変換の詳細については、MyISAM から InnoDB へのテーブルの変換をご覧ください。

10. 移行元データベースへの接続に使用するユーザー アカウントのパスワードは、32 文字以内にする必要があり、これは MySQL レプリケーション固有の問題となります。

    MySQL のユーザー パスワードの長さ制限に関する詳細については、MySQL バグ #43439 をご覧ください。

11. Microsoft Azure Database for MySQL ソースの場合のみ: require_secure_transport 設定の値を確認します。

    デフォルトでは、Microsoft Azure データベースでは、すべての受信接続に SSL/TLS 暗号化が必要です。require_secure_transport の値に応じて、移行元接続プロファイルを作成するときに、次のいずれかの暗号化設定を使用します。

    • `require_secure_transport` が `on` に設定されている場合は、[Basic]、[TLS]、または [mTLS] を選択します。
    • require_secure_transport が off に設定されている場合は、[None] を選択します。