継続的な移行のために移行元 MySQL データベースを構成する

このページでは、継続的な同種 MySQL 移行用に次のソース データベース インスタンスを構成する方法について説明します。

Cloud SQL for MySQL ソースを構成する

移行プロセス用に Cloud SQL for MySQL のソース インスタンスを構成するには、次の操作を行います。

  1. ソース データベースに、DEFINER 句を使用してユーザーが定義したメタデータが含まれているかどうかを確認します。 DEFINER 句でメタデータを確認するをご覧ください。

    同種の MySQL 移行用の Database Migration Service では、ユーザー アカウントとログインは移行されません。DEFINER 句を含むユーザー アカウントで定義されたメタデータを含むソースは、移行をブロックする可能性があります。

  2. ソース データベースに mysql、performance_schema、information_schema、ndbinfo、sys のシステム スキーマのテーブルを参照するオブジェクトが含まれている場合は、レプリカ データベースにもこれらのシステム スキーマ テーブルが含まれていることを確認してください。

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

  3. 移行元データベースでバイナリログを有効にして構成します。

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

    1. インスタンスで PITR を有効にします。この機能により、バイナリ ロギングが自動的に有効になります。Cloud SQL で PITR を使用せずにバイナリ ロギングを有効にすることはできません。Cloud SQL のドキュメントの ポイントインタイム リカバリ（PITR）をご覧ください。
    2. Cloud SQL フラグを使用して、ロギング構成を調整します。詳細については、Cloud SQL のドキュメントのデータベース フラグを構成するをご覧ください。
      1. Database Migration Service では、binlog_format を ROW に設定する必要があります。この設定を調整する必要はありません。Cloud SQL for MySQL は binlog_format フラグを ROW に自動的に設定します。
      2. ログの保持期間を、データベースの移行をサポートするのに十分な期間に設定します。通常は 1 週間ほどで十分です。 次のいずれかのフラグを使用します。
        • MySQL 5.6 ～ 5.7: expire_logs_days
        • MySQL 8.0 以降: expire_logs_days、binlog_expire_logs_seconds

  4. インスタンスに移行専用のユーザー アカウントを作成します。 Cloud SQL ドキュメントの ユーザーを作成するをご覧ください。次の点を確認してください。

    • 専用ユーザー アカウントが任意のホスト（host=%）から接続できるようにします。
    • アカウントのパスワードの長さが 32 文字を超えていない。 MySQL ユーザーのパスワードの長さの制限については、MySQL バグ #43439 をご覧ください。

  5. 移行専用のユーザー アカウントに必要な権限を割り当てます。継続的な移行の場合、必要な権限の完全なリストは、独自のダンプファイルを提供するか、Database Migration Service のマネージド ダンプ機能を使用するかによって異なります。

    マネージド ダンプ

    Database Migration Service で移行元データベースの完全ダンプを自動的に取得する場合は、ユーザー アカウントに次の権限を割り当てます。

    手動ダンプ

    mysqldump で作成した独自のダンプファイルを使用する場合は、CDC フェーズに必要な権限を付与する必要があります。

セルフホスト型 MySQL ソースを構成する

移行プロセス用に自己ホスト型の MySQL ソース インスタンスを構成するには、次の操作を行います。

  1. すべてのテーブル（システム データベース内のテーブルを除く）で InnoDB ストレージ エンジンが使用されていることを確認します。別のストレージ エンジンを使用する場合は、テーブルの変換が必要になることがあります。詳細については、 MyISAM から InnoDB へのテーブルの変換をご覧ください。
  2. ソース データベースに、DEFINER 句を使用してユーザーが定義したメタデータが含まれているかどうかを確認します。 DEFINER 句を使用してメタデータを検証するをご覧ください。

    Database Migration Service の同タイプの MySQL 移行では、ユーザー アカウントとログインは移行されません。DEFINER 句を含むユーザー アカウントで定義されたメタデータを含むソースは、移行をブロックする可能性があります。

  3. ソース データベースに mysql、performance_schema、information_schema、ndbinfo、sys のシステム スキーマのテーブルを参照するオブジェクトが含まれている場合は、レプリカ データベースにもこれらのシステム スキーマ テーブルが含まれていることを確認してください。

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

  4. server-id の設定を 1 以上の値に構成します。詳細については、 レプリケーションとバイナリログのオプションと変数をご覧ください。

  5. GTID_MODE が ON または OFF に設定されていることを確認します。他の値はサポートされていません。

    Database Migration Service では、次のシナリオで GTID_MODE を ON に設定する必要があります。

    GTID_MODE の詳細については、 グローバル トランザクション ID システム変数をご覧ください。

  6. ソース データベースでバイナリログを有効にして構成します。手順は次のとおりです。

      • 移行元データベースでバイナリログを有効にします。
      • binlog_format を 'ROW' に設定します。行ベースのバイナリ ロギングをご覧ください。
      • ログの保持期間を、データベースの移行をサポートするのに十分な期間に設定します。通常は 1 週間ほどで十分です。次のいずれかのフラグを使用します。
        • MySQL 5.5 ～ 5.7: expire_logs_days
        • MySQL 8.0: expire_logs_days、binlog_expire_logs_seconds

  7. インスタンスに移行専用のユーザー アカウントを作成します。 アカウント管理に関する声明をご覧ください。次の点を確認してください。

    • 専用ユーザー アカウントが任意のホスト（host=%）から接続できるようにします。
    • アカウントのパスワードが 32 文字以内である。MySQL ユーザーのパスワードの長さの制限については、MySQL バグ #43439 をご覧ください。

  8. 移行専用のユーザー アカウントに必要な権限を割り当てます。継続的移行の場合、必要な権限の完全なリストは、独自のダンプファイルを提供するか、Database Migration Service のマネージド ダンプ機能を使用するかによって異なります。

    マネージド ダンプ

    Database Migration Service で移行元データベースの完全ダンプを自動的に取得する場合は、ユーザー アカウントに次の権限を割り当てます。

    手動ダンプ

    mysqldump で作成されたダンプファイルを独自に指定する場合は、CDC フェーズに必要な権限を付与する必要があります。

Amazon RDS for MySQL ソースを構成する

移行プロセス用に Amazon RDS for MySQL のソース インスタンスを構成するには、次の操作を行います。

  1. Amazon RDS for MySQL は、デフォルトで InnoDB ストレージ エンジンを使用しますが、他のストレージ エンジンを使用することもできます。すべてのテーブル（システム データベースのテーブルを除く）で InnoDB ストレージ エンジンが使用されていることを確認します。別のストレージ エンジンを使用している場合は、テーブルの変換が必要になることがあります。詳細については、 MyISAM から InnoDB へのテーブルの変換をご覧ください。
  2. ソース データベースに DEFINER 句でユーザーが定義したメタデータが含まれているかどうかを確認します。 DEFINER 句でメタデータを確認するをご覧ください。

    同種の MySQL 移行用の Database Migration Service では、ユーザー アカウントとログインは移行されません。DEFINER 句を含むユーザー アカウントで定義されたメタデータを含むソースは、移行をブロックする可能性があります。

  3. ソース データベースに mysql、performance_schema、information_schema、ndbinfo、sys のシステム スキーマのテーブルを参照するオブジェクトが含まれている場合は、レプリカ データベースにもこれらのシステム スキーマ テーブルが含まれていることを確認してください。

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

  4. GTID_MODE が ON または OFF に設定されていることを確認します。他の値はサポートされていません。Amazon RDS for MySQL は、デフォルトで GTID_MODE = OFF を使用します。

    Database Migration Service では、次のシナリオで GTID_MODE を ON に設定する必要があります。

    GTID_MODE の詳細については、 グローバル トランザクション ID システム変数をご覧ください。

  5. 移行元データベースでバイナリログを確認して構成します。手順は次のとおりです。

    1. インスタンスで自動バックアップが使用されていることを確認します。Amazon RDS は、自動バックアップが有効になっている場合にのみバイナリログを生成します。詳細については、Amazon RDS ドキュメントの自動バックアップの有効化をご覧ください。

    2. ログの保持期間を、データベースの移行をサポートするのに十分な期間に設定します。通常は 1 週間ほどで十分です。 Amazon RDS ドキュメントの バイナリログ構成の設定と表示をご覧ください。

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

  6. インスタンスに移行専用のユーザー アカウントを作成します。 アカウント管理ステートメントをご覧ください。次のことを確認してください。

    • 専用ユーザー アカウントが任意のホスト（host=%）から接続できるようにします。
    • アカウントのパスワードが 32 文字以下である。MySQL ユーザーのパスワードの長さの制限については、MySQL バグ #43439 をご覧ください。

  7. 移行専用のユーザー アカウントに必要な権限を割り当てます。継続的な移行の場合、必要な権限の完全なリストは、独自のダンプファイルを提供するか、Database Migration Service のマネージド ダンプ機能を使用するかによって異なります。

    マネージド ダンプ

    Database Migration Service で移行元データベースの完全ダンプを自動的に取得する場合は、ユーザー アカウントに次の権限を割り当てます。

    手動ダンプ

    mysqldump で作成されたダンプファイルを指定する場合は、CDC フェーズに必要な権限を指定する必要があります。

Amazon Aurora for MySQL ソースを構成する

移行プロセス用に Amazon Aurora for MySQL のソース インスタンスを構成するには、次の操作を行います。

  1. ソース データベースに DEFINER 句でユーザーが定義したメタデータが含まれているかどうかを確認します。 DEFINER 句を使用してメタデータを検証するをご覧ください。

    同種の MySQL 移行用の Database Migration Service では、ユーザー アカウントとログインは移行されません。DEFINER 句を使用してユーザー アカウントで定義されたメタデータを含むソースは、移行をブロックする可能性があります。

  2. ソース データベースに mysql、performance_schema、information_schema、ndbinfo、sys システム スキーマのテーブルを参照するオブジェクトが含まれている場合は、レプリカ データベースにもこれらのシステム スキーマ テーブルが含まれていることを確認します。

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

  3. GTID_MODE が ON または OFF に設定されていることを確認します。他の値はサポートされていません。Amazon Aurora for MySQL は、デフォルトで GTID_MODE = OFF を使用します。

    Database Migration Service では、次のシナリオで GTID_MODE を ON に設定する必要があります。

    GTID_MODE の詳細については、 グローバル トランザクション ID システム変数をご覧ください。

  4. ソース データベースでバイナリログを有効にして構成します。手順は次のとおりです。

    1. MySQL データベースのバイナリ ロギングを有効にします。

    2. ログの保持期間を、データベースの移行をサポートするのに十分な期間に設定します。通常は 1 週間ほどで十分です。 バイナリログの構成の設定と表示をご覧ください。

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

  5. インスタンスに移行専用のユーザー アカウントを作成します。 アカウント管理ステートメントをご覧ください。次の点を確認してください。

    • 専用ユーザー アカウントが任意のホスト（host=%）から接続できるようにします。
    • アカウントのパスワードが 32 文字以下である。MySQL ユーザーのパスワードの長さの制限については、MySQL バグ #43439 をご覧ください。

  6. 移行専用のユーザー アカウントに必要な権限を割り当てます。継続的移行の場合、必要な権限の完全なリストは、独自のダンプファイルを提供するか、Database Migration Service のマネージド ダンプ機能を使用するかによって異なります。

    マネージド ダンプ

    Database Migration Service で移行元データベースの完全ダンプを自動的に取得する場合は、ユーザー アカウントに次の権限を割り当てます。

    手動ダンプ

    mysqldump で作成されたダンプファイルを独自に指定する場合は、CDC フェーズに必要な権限を付与する必要があります。

Microsoft Azure Database for MySQL ソースを構成する

移行プロセス用に Microsoft Azure Database for MySQL のソース インスタンスを構成するには、次の操作を行います。

  1. ソース データベースに、DEFINER 句を使用してユーザーが定義したメタデータが含まれているかどうかを確認します。 DEFINER 句を使用してメタデータを検証するをご覧ください。

    同種の MySQL 移行用の Database Migration Service では、ユーザー アカウントとログインは移行されません。DEFINER 句を含むユーザー アカウントで定義されたメタデータを含むソースは、移行をブロックする可能性があります。

  2. ソース データベースに mysql、performance_schema、information_schema、ndbinfo、sys システム スキーマのテーブルを参照するオブジェクトが含まれている場合は、レプリカ データベースにもこれらのシステム スキーマ テーブルが含まれていることを確認します。

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

  3. GTID_MODE が ON または OFF に設定されていることを確認します。他の値はサポートされていません。Microsoft Azure Database for MySQL では、デフォルトで GTID_MODE = OFF が使用されます。

    Database Migration Service では、次のシナリオで GTID_MODE を ON に設定する必要があります。

    • リードレプリカが有効になっている既存の宛先インスタンスに 移行する場合。
    • ダンプファイルを手動で作成し、移行ジョブで提供する場合。

    GTID_MODE の詳細については、 グローバル トランザクション ID システム変数をご覧ください。

  4. 移行元データベースのバイナリ ロギング設定を確認して構成します。次のように対応します。

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

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

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

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

  5. require_secure_transport 設定の値を確認します。

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

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

  6. インスタンスに移行専用のユーザー アカウントを作成します。 アカウント管理ステートメントをご覧ください。次の点を確認してください。

    • 専用ユーザー アカウントが任意のホスト（host=%）から接続できるようにします。
    • アカウントのパスワードが 32 文字以下である。MySQL ユーザーのパスワードの長さの制限については、MySQL バグ #43439 をご覧ください。

  7. 移行専用のユーザー アカウントに必要な権限を割り当てます。継続的移行の場合、必要な権限の完全なリストは、独自のダンプファイルを提供するか、Database Migration Service のマネージド ダンプ機能を使用するかによって異なります。

    マネージド ダンプ

    Database Migration Service で移行元データベースの完全なダンプを自動的に取得する場合は、ユーザー アカウントに次の権限を割り当てます。

    手動ダンプ

    mysqldump で作成されたダンプファイルを指定する場合は、CDC フェーズに必要な権限を指定する必要があります。

次のステップ

同種の Cloud SQL for MySQL 移行の詳細な移行手順については、 Cloud SQL for MySQL 移行のスタートガイドをご覧ください。