1 回限りの移行用に移行元 MySQL データベースを構成する

このページでは、1 回限りの同種 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 ドキュメントの ユーザーを作成するをご覧ください。次の点を確認してください。

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

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

    マネージド ダンプ

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

    • SELECT
    • SHOW VIEW
    • TRIGGER
    • RELOAD
    • ソース MySQL バージョン 8.0 以降の場合: 移行アカウントに BACKUP_ADMIN 権限がないことを確認します。

    手動ダンプ

    mysqldump で作成した独自のダンプファイルを提供する場合、ユーザー アカウントに追加の権限を割り当てる必要はありません。

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

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

  1. すべてのテーブル（システム データベース内のテーブルを除く）で 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 に設定されていることを確認します。他の値はサポートされていません。

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

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

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

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

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

    マネージド ダンプ

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

    手動ダンプ

    mysqldump で作成した独自のダンプファイルを提供する場合、ユーザー アカウントに追加の権限を割り当てる必要はありません。

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

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

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

    マネージド ダンプ

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

    手動ダンプ

    mysqldump で作成された独自の ダンプファイルを指定する場合は、ユーザー アカウントに追加の権限を割り当てる必要はありません。

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

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

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

    Database Migration Service の同タイプの MySQL 移行では、ユーザー アカウントとログインは移行されません。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. インスタンスに移行専用のユーザー アカウントを作成します。 アカウント管理ステートメントをご覧ください。次のことを確認してください。

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

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

    マネージド ダンプ

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

    手動ダンプ

    mysqldump で作成した独自のダンプファイルを提供する場合、ユーザー アカウントに追加の権限を割り当てる必要はありません。

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

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

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

    Database Migration Service の同タイプの MySQL 移行では、ユーザー アカウントとログインは移行されません。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. require_secure_transport 設定の値を確認します。

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

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

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

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

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

    マネージド ダンプ

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

    手動ダンプ

    mysqldump で作成された独自のダンプファイルを指定する場合は、ユーザー アカウントに追加の権限を割り当てる必要はありません。

次のステップ

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