MySQL の問題を診断する

移行ジョブのプロセスで、実行時にエラーが発生することがあります。

  • 移行元データベースのパスワードが間違っているなどの一部のエラーは回復可能です。つまり、修正すると移行ジョブが自動的に再開されます。
  • バイナリログの位置が失われた場合など、回復不能なものもあります。この場合、移行ジョブを最初からやり直す必要があります。

エラーが発生すると、移行ジョブのステータスが Failed に変わり、サブステータスに失敗前の最後のステータスが反映されます。

エラーのトラブルシューティングを行うには、失敗した移行ジョブに移動してエラーを表示し、エラー メッセージに記載されている手順に沿って操作します。

エラーの詳細を表示するには、移行ジョブのリンクを使用して Cloud Monitoring に移動します。ログは特定の移行ジョブにフィルタされます。

次の表に、問題の例とその解決方法を示します。

この問題については... 次のような問題が考えられます... 次のことを試します...
移行先データベースの設定が、データベースのプロビジョニングに使用された Terraform 構成と異なる。（この問題は、構成ドリフトと呼ばれることもあります）。 既存の移行先データベースに移行する場合、Database Migration Service は移行ジョブを実行するために移行先データベースの特定の設定を変更します。 移行ジョブをプロモートした後、Terraform 構成で使用する設定を再適用する必要があります。Terraform 構成のずれをご覧ください。
エラー メッセージ: Error processing table {table_name}: MySQL Error 1118 (42000): Row size too large (>8126). VARCHAR 列を使用するテーブルには、InnoDB（MySQL で使用されるデフォルトのストレージ エンジン）で許可されている最大サイズを超える行が含まれている場合があります。 移行ジョブのブロックを解除するには、列を BLOB または TEXT に変換するか、innodb_strict_mode フラグを一時的に off に設定します。エラー 1118: 行サイズが大きすぎるをご覧ください。
初期ダンプフェーズ中に移行ジョブが失敗し、次のエラー メッセージが表示される。
ERROR 1064 (42000) at {line_number}: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near {reserved_word} at {line_number}.		 この問題は、MySQL バージョン間で移行するときに発生します。移行先の MySQL バージョンで許可されていない単語が、移行元の MySQL バージョンのエンティティで使用されている可能性があります。

たとえば、MySQL 5.7 では、列名に function という単語を使用できます。ただし、MySQL 8.0 では function は予約語であるため、移行先のデータベースでソースを解析できません。

 エラー メッセージで参照されているソース データベース オブジェクトの名前を変更するか、バッククォート（``）で囲んで構文をエスケープします。完了したら、移行ジョブを再試行します。
エラー メッセージ: ERROR 1109 (42S02): Unknown table in <schema name here> Database Migration Service は、mysql、performance_schema、information_schema、ndbinfo、sys のシステム スキーマを移行しません。

移行元データベースにこれらのスキーマのテーブルを参照するオブジェクトが含まれている場合、移行ジョブが失敗する可能性があります。

 移行されていないシステム スキーマに含まれるテーブルを参照するオブジェクトがソース データベースにないか確認します。ERROR 1109 (42S02): Unknown table in <schema name here> をご覧ください。
エラー メッセージ: Unknown table 'COLUMN_STATISTICS' in information_schema (1109) mysqldump のみを使用した手動データベース ダンプのシナリオに関連します。

バージョン 8 より前の MySQL データベースには COLUMN_STATISTICS テーブルがありません。バージョン 8 以降の mysqldump ユーティリティは、デフォルトでこのテーブルをエクスポートしようとします。列が存在しないため、エクスポートが失敗します。

 mysqldump を使用する場合は、--column-statistics=0 フラグを使用します。
エラー メッセージ: Specified key was too long; max key length is 767 bytes ソース データベース インスタンスに変数 innodb_large_prefix が設定されている可能性があります。 移行先インスタンスの作成時に innodb_large_prefix フラグを に設定ONするか、フラグを使用して既存の移行先インスタンスを更新します。
エラー メッセージ: Table definition has changed ダンプ処理中にデータ定義言語（DDL）が変更されました。 ダンププロセス中の DDL の変更を回避します。
エラー メッセージ: While 'Loading data': Dump timeout 接続の問題が原因でタイムアウトが発生している可能性があります。 移行元データベースとのネットワーク接続を確認します。ガイダンスの例については、接続のデバッグをご覧ください。
ダンプ プロセス中にデータ定義言語（DDL）の変更が行われた場合、Database Migration Service がメタデータ ロックにより停止することがあります。 ソース データベースを調査して、Waiting for table metadata lock 状態で停止しているプロセスがないか確認します。このステータスのプロセスが見つかった場合は、移行ジョブを再起動することをおすすめします。再起動後の完全ダンプフェーズ中に DDL の変更を行わないでください。 サンプル スクリプトを使用して、DDL オペレーションが停止したことを確認できます。
MySQL Error 2013: (HY000): Lost connection to MySQL server during query 接続の問題が原因でタイムアウトが発生している可能性があります。 移行元データベースとのネットワーク接続を確認します。サンプル ガイダンスについては、接続のデバッグをご覧ください。
ダンプ プロセス中にデータ定義言語（DDL）の変更が行われた場合、Database Migration Service がメタデータ ロックで停止する可能性があります。 ソース データベースを調査して、Waiting for table metadata lock 状態で停止しているプロセスがないか確認します。このステータスのプロセスが見つかった場合は、移行ジョブを再開することをおすすめします。再起動後の完全ダンプフェーズ中に DDL の変更を行わないでください。 サンプル スクリプトを使用して、DDL オペレーションが停止していることを確認できます。
エラー メッセージ: Timeout waiting for no write traffic on source: context deadline exceeded 接続の問題が原因でタイムアウトが発生している可能性があります。 移行元データベースとのネットワーク接続を確認します。サンプル ガイダンスについては、接続のデバッグをご覧ください。
ダンプ プロセス中にデータ定義言語（DDL）の変更が行われた場合、Database Migration Service がメタデータ ロックで停止することがあります。 ソース データベースを調べて、Waiting for table metadata lock 状態のままになっているプロセスがないか確認します。このステータスのプロセスが見つかった場合は、移行ジョブを再開することをおすすめします。再起動後の完全なダンプ フェーズでは、DDL の変更を行わないでください。 サンプル スクリプトを使用して、DDL オペレーションが停止したことを確認できます。
エラー メッセージ: Access denied; you need (at least one of) the SUPER privilege(s) for this operation ソース データベースに、スーパー ユーザー@localhost（root@localhost など）を使用するイベント、ビュー、関数、プロシージャが存在する可能性があります。これは Cloud SQL ではサポートされていません。 Cloud SQL での DEFINER の使用量については、詳細をご覧ください。
エラー メッセージ: Definer user 'x' does not exist. Please create the user on the replica. ユーザーがレプリカに存在しない。 Cloud SQL での DEFINER の使用量については、詳細をご覧ください。
エラー メッセージ: ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost ソース データベースに、レプリカに存在しない DEFINER があります。 Cloud SQL での DEFINER の使用に関する詳細をご覧ください。
エラー メッセージ: Lost connection to MySQL server during query when dumping table 移行元データベースにアクセスできなくなったか、ダンプに含まれているパケットが大きすぎる可能性があります。 こちらの手順をお試しください。
エラー メッセージ: Got packet bigger than 'max_allowed_packet' bytes when dumping table パケットが、設定された許容量を超えました。 max_allowed_packet オプションを指定して手動ダンプを使用します。
最初のデータの移行は成功しましたが、データが複製されていません。 レプリケーション フラグが競合している可能性があります。 こちらのフラグ設定をご確認ください。
最初のデータ移行は成功したが、しばらくするとデータ レプリケーションが機能しなくなる。 さまざまな原因が考えられます。 こちらの手順をお試しください。
エラー メッセージ: mysqld check failed: data disk is full 宛先インスタンスのデータディスクに空き容量がありません。 宛先インスタンスのディスクサイズを増やします。ディスクサイズを手動で増やすか、自動ストレージ増加を有効にします。
ソース データベース インスタンスへの接続エラー。 移行元データベース インスタンスと移行先インスタンスの間に接続の問題が発生しました。 接続のデバッグの記事の手順に沿って操作します。
マネージド データベース（Amazon RDS/Aurora）からの移行が開始されない。 SUPERUSER 権限のないマネージド移行元データベースから移行する場合は、移行の開始時に短時間のダウンタイムが必要です。 こちらの記事の手順に沿って操作してください。
ソース データベースでバイナリログが正しく構成されていません。 バイナリログの定義が正しくない。 継続的な MySQL 移行ジョブの場合は、必要な binlog 定義に従ってください。
ダンプファイルが見つかりません。 DMS が、指定されたダンプファイルを見つけることができません。 これは、移行ジョブが指定された場所でダンプファイルを見つけられない場合に発生することがあります。
  1. ダンプパスを確認して、適切なファイルがあることを確認するか、パスを変更します。
  2. パスを変更する場合は、PATCH リクエストを使用して、ジョブがそのパスを使用するようにします。
  3. 移行ジョブを再開します。
バイナリログの位置が失われたため、レプリケーションを再開できません。 バイナリログの位置が失われ、移行ジョブを再開できませんでした。 このエラーは、レプリケーション プロセスが長時間一時停止されたときに、バイナリログの位置が失われることによって発生します。バイナリログの保持期間が近づく期間は、移行ジョブを一時停止しないでください。移行ジョブを再開します。
既存の宛先インスタンスに移行すると、次のエラー メッセージが表示されます。 The destination instance contains existing data or user defined entities (for example databases, tables, or functions). You can only migrate to empty instances. Clear your destination instance and retry the migration job. 宛先の Cloud SQL インスタンスに余分なデータが含まれている。移行できるのは、空の既存のインスタンスのみです。既知の制限事項をご覧ください。 移行先インスタンスをプロモートして読み取り/書き込みインスタンスにし、余分なデータを削除して、移行ジョブを再試行します。既存の宛先インスタンスから余分なデータを消去するをご覧ください。
移行元データベースと移行先データベースのバージョンに互換性がないため、移行ジョブを実行できません。 指定されたソース データベースのバージョンは、移行先データベースのバージョンと互換性がありません。 移行先データベースのバージョンが移行元データベースのバージョンと同じか、1 つ上のメジャー バージョンであることを確認してから、新しい移行ジョブを作成します。
エラー メッセージ: Unable to connect to source database server. Database Migration Service が移行元データベース サーバーへの接続を確立できない。 移行元と移行先のデータベース インスタンスが相互に通信できること、および移行ジョブの設定を定義したときに表示された必要な前提条件をすべて完了していることを確認します。
エラー メッセージ: Timeout waiting for no write traffic on source. SUPERUSER 権限のないマネージド ソース データベースから移行すると、移行の開始時に短時間のダウンタイムが発生します。 SUPERUSER 権限なしで RDS MySQL から移行するの手順に沿って操作します。
エラー メッセージ: ERROR 1146 (42S02) at line {line_number}: Table '{table_name}' doesn't exist. 移行元データベースの lower_case_table_names フラグの値と、移行先の Cloud SQL インスタンスのフラグの値が一致していない可能性があります。 Cloud SQL インスタンスのフラグの値を、移行元データベースのフラグの値と一致するように設定します。
エラー メッセージ: ERROR 1109 (42S02) at line {line_number}: Unknown table '{table}' in {database}. ソース データベース上の一部のオブジェクト（ビュー、関数、ストアド プロシージャ、トリガーなど）が、データベース上に存在しないテーブルを参照しています。 これらのオブジェクトが存在するかどうかを確認します。含まれている場合は、移行元データベースからオブジェクトを削除するか、オブジェクトが参照しているテーブルを移行元データベースに追加します。
エラー メッセージ: ERROR 1045: Access denied for user '{user_name}'@'{replica_IP}' (using password: YES)". Check if MySQL replication user and password are correct. Not attempting further retries. 移行元インスタンスに指定したパスワードが正しくありません。または、移行元インスタンスが SSL 接続を強制しているが、移行ジョブが SSL 証明書を使用するように構成されていない。

mysql クライアントを使用して、移行元インスタンスのユーザー名、パスワード、SSL 設定が正しいかどうかを確認します。

移行元インスタンスが Cloud SQL の場合は、SSL/TLS を必須にするを参照して、TCP 接続に SSL/TLS が必要かどうかを確認します。

レプリケーション ラグが常に大きい。

書き込みの負荷が大きすぎてレプリカで処理できません。レプリケーション ラグは、レプリカの Cloud SQL for MySQL スレッドが I/O スレッドに追いつけない場合に発生します。クエリやワークロードによっては、特定のスキーマで一時的または永続的に高いレプリケーション ラグが発生することがあります。レプリケーション ラグの一般的な原因は次のとおりです。

  • レプリカで低速なクエリが実行される。遅いクエリを見つけて修正します。
  • すべてのテーブルに一意の主キーを設定することを強くおすすめします。このキーのないテーブルを更新するたびに、レプリカでテーブル全体がスキャンされ、レプリケーションの遅延が発生します。
  • DELETE ... WHERE field < 50000000 などのクエリでは、レプリカに膨大な数の更新が蓄積されるため、行ベースのレプリケーションでレプリケーション ラグが発生します。

考えられる解決策は次のとおりです。

エラー メッセージ: 'Character set '#255' is not a compiled character set and is not specified in the '/usr/share/mysql/charsets/Index.xml' file' on query. 移行元データベースでは、選択した Cloud SQL レプリカでサポートされていない文字セットまたは照合順序が使用されている可能性があります。たとえば、AWS Aurora バージョン 2.x は MySQL 5.7 と互換性があります。ただし、このバージョンでは utf8mb4_0900_as_ci 照合順序がサポートされています。これは、Cloud SQL for MySQL 5.7 ではサポートされていません。
  • 完全ダンプ フェーズで移行が失敗した場合は、サポートされていない文字セットまたは照合順序が使用されているかどうか、移行元テーブルの定義を確認します。可能であれば、サポートされている文字セットまたは照合順序に更新します。
  • CDC フェーズで移行が失敗した場合は、レプリカのステータスを確認し、移行が失敗した原因のバイナリログを見つけて、ソース データベースとアプリケーションを調べて、文字セットまたは照合順序を使用する SQL ステートメントを見つけます。可能であれば、サポートされている文字セットまたは照合順序に更新します。

エラー 1108: 行のサイズが大きすぎます

可変長文字列を格納する列を含むテーブルには、デフォルトの InnoDB の最大行サイズを超える行が含まれる場合があります。

次の方法をお試しください

ソーステーブルのスキーマを調整する

この問題は、最大サイズ行の上限を超えるテーブルに対して INSERT ステートメントを実行するたびに再発する可能性があります。今後の問題を回避するには、移行を再試行する前にテーブルを調整することをおすすめします。

  • 次のクエリを実行して、テーブル ROW_FORMAT を DYNAMIC または COMPRESSED に変更します。
    ALTER TABLE TABLE_NAME ROW_FORMAT=FORMAT_NAME;
    ここで:
    • TABLE_NAME は、行が最大行サイズの上限を超えているテーブルの名前です。
    • FORMAT_NAME は DYNAMIC または COMPRESSED
    次に例を示します。 
    ALTER TABLE mytable ROW_FORMAT=DYNAMIC;
  • 行データを BLOB または TEXT に変換します。この操作を実現する方法の 1 つは、CONVERT() 関数を使用することです。
InnoDB 厳格モードを無効にする

移行元テーブルのスキーマを調整できない場合は、移行ジョブを完了するために InnoDB 検証を一時的に無効にできます。この問題は、今後のデータベース書き込み試行中に再発する可能性があるため、可能な場合はテーブル スキーマを調整することをおすすめします。

移行ジョブを完了するために InnoDB 検証を一時的に無効にする手順は次のとおりです。

その後...
新しい宛先インスタンスに移行する場合
  1. 移行ジョブを再作成する。
  2. [宛先を定義する] ステップの最後で、[オプションの構成を表示] をクリックします。
  3. [フラグ] セクションで、innodb_strict_mode フラグを選択して Off に設定します。
  4. 移行が完了したら、innodb_strict_mode フラグを On に設定します。Cloud SQL for MySQL のドキュメントのデータベース フラグを構成するをご覧ください。
既存の移行先インスタンスに移行する場合
  1. Cloud SQL で、移行先インスタンスに移動し、innodb_strict_mode フラグを Off に設定します。Cloud SQL for MySQL のドキュメントのデータベース フラグを構成するをご覧ください。
  2. 移行ジョブを再作成する。
  3. 移行が完了したら、innodb_strict_mode フラグを On に設定します。Cloud SQL for MySQL のドキュメントのデータベース フラグを構成するをご覧ください。

既存の移行先インスタンスから余分なデータを消去する

既存の宛先インスタンスに移行すると、次のエラー メッセージが表示されます。 The destination instance contains existing data or user defined entities (for example databases, tables, or functions). You can only migrate to empty instances. Clear your destination instance and retry the migration job.

この問題は、移行先インスタンスに余分なデータが含まれている場合に発生することがあります。移行できるのは、空の既存のインスタンスのみです。既知の制限事項をご覧ください。

次の方法をお試しください

次の手順で、移行先インスタンスから余分なデータを消去し、移行ジョブを再度開始します。

  1. 移行ジョブを停止します。
  2. この時点で、移行先の Cloud SQL インスタンスは read-only モードになっています。移行先インスタンスをプロモートして、書き込みアクセス権を取得します。
  3. 移行先の Cloud SQL インスタンスに接続します。
  4. 移行先インスタンスのデータベースから余分なデータを削除します。移行先にはシステム構成データのみを含めることができます。宛先データベースにユーザーデータ（テーブルなど）を含めることはできません。データベースで実行してシステム以外のデータを見つけることができる SQL ステートメントは、次のようにさまざまです。
    SELECT schema_name FROM information_schema.SCHEMATA
WHERE schema_name NOT IN ('information_schema', 'sys', 'performance_schema', 'mysql');
  5. 移行ジョブを開始します。

Terraform 構成ドリフト

既存の移行先データベースに移行すると、Database Migration Service は移行先データベースの特定の設定を変更して移行ジョブを実行します。Terraform でプロビジョニングされたデータベースの場合、この操作により、実際の宛先データベース構成が Terraform ファイルで設定された構成と異なる構成ドリフトが発生する可能性があります。

次の方法をお試しください

移行ジョブの実行中に Terraform 構成を再適用しないでください。移行先データベースがプロモートされた後、必要な構成を安全に調整できます。Database Migration Service は、移行先の Cloud SQL インスタンスに次の変更を行います。 Terraform 構成にこれらの機能の設定が含まれている場合は、構成のドリフトが発生する可能性があります。移行先データベースの構成を修正する必要がある場合は、移行ジョブが完了して移行先データベースがプロモートされるまで待ちます。以下の手順を行います。 1. `terraform plan` コマンドを実行して、変更のプレビューを確認します。1. 「terraform apply」コマンドを実行して、移行先データベースの設定を再調整します。

ERROR 1109 (42S02): Unknown table in <schema name here>

移行ジョブが失敗し、次のメッセージが表示されます。ERROR 1109 (42S02): Unknown table in <schema name here> （例: ERROR 1109 (42S02) at line X: Unknown table 'GLOBAL_STATUS' in information_schema）。

次のような問題が考えられます

Database Migration Service は、mysql、performance_schema、information_schema、ndbinfo、sys のシステム スキーマを移行しません（既知の制限事項を参照）。移行元データベースに、これらのスキーマのテーブルを参照するオブジェクトが含まれている場合、移行ジョブが失敗することがあります。

次の方法をお試しください

システム スキーマのテーブルを参照するオブジェクトがないか、移行元のデータベースを確認します。ソース データベースで、次のクエリを実行します。
# Query to check routines or functions definitions.
SELECT ROUTINE_SCHEMA, ROUTINE_NAME FROM information_schema.routines
WHERE ROUTINE_SCHEMA NOT IN ('information_schema', 'mysql', 'ndbinfo', 'performance_schema', 'sys')
AND ROUTINE_DEFINITION like '%OBJECT_NAME_REPORTED_IN_THE_ERROR_MESSAGE%'

# Query to check view definitions.
SELECT TABLE_SCHEMA, TABLE_NAME FROM information_schema.views
WHERE TABLE_SCHEMA NOT IN ('information_schema', 'mysql', 'ndbinfo', 'performance_schema', 'sys')
AND view_definition like '%OBJECT_NAME_REPORTED_IN_THE_ERROR_MESSAGE%'

# Query to check trigger definitions.
SELECT TRIGGER_SCHEMA, TRIGGER_NAME FROM information_schema.TRIGGERS
WHERE TRIGGER_SCHEMA NOT IN ('information_schema', 'mysql', 'ndbinfo', 'performance_schema', 'sys')
AND event_object_table = 'OBJECT_NAME_REPORTED_IN_THE_ERROR_MESSAGE'

# Query to check constraint definitions.
SELECT TABLE_SCHEMA, TABLE_NAME
FROM information_schema.KEY_COLUMN_USAGE
WHERE TABLE_SCHEMA NOT IN ('information_schema', 'mysql', 'ndbinfo', 'performance_schema', 'sys')
AND REFERENCED_TABLE_NAME = 'OBJECT_NAME_REPORTED_IN_THE_ERROR_MESSAGE'
 これらのクエリで結果が返された場合は、関連するコード オブジェクトを削除して、移行を再度実行することを検討してください。

information_schema に不明なテーブル「COLUMN_STATISTICS」があります

mysqldump ユーティリティ バージョン 8 以降を実行して、8 より前の MySQL データベース バージョンをエクスポートすると、Unknown table 'COLUMN_STATISTICS' in information_schema (1109) エラーが発生します。

次のような問題が考えられます

バージョン 8 より前の MySQL データベースには COLUMN_STATISTICS テーブルがありません。バージョン 8 以降の mysqldump ユーティリティは、デフォルトでこのテーブルをエクスポートしようとします。列が存在しないため、エクスポートが失敗します。

次の方法をお試しください

mysqldump コマンドに --column-statistics=0 フラグを追加して、エクスポートから COLUMN_STATISTICS テーブルを削除します。詳細については、mysqldump を使用した MySQL データベースのエクスポートをご覧ください。

指定された鍵が長すぎる（キーの最大長は 767 バイト）

Specified key was too long; max key length is 767 bytes. というエラーが表示されます。

次のような問題が考えられます

移行元データベースで変数 innodb_large_prefix が設定されている場合があります。これにより、767 バイトを超えるインデックス キーの接頭辞を使用できます。MySQL 5.6 のデフォルト値は OFF です。

次の方法をお試しください

宛先データベースの作成時に innodb_large_prefix フラグを ON に設定するか、このフラグを使用して既存の宛先データベースを更新します。

表の定義が変更された

Table definition has changed というエラーが表示されます。

次のような問題が考えられます

ダンプ処理中に DDL が変更されました。

次の方法をお試しください

ダンプ処理中にテーブルを変更したり、他の DDL 変更を行ったりしないでください。スクリプトを使用して、DDL オペレーションが停止していることを確認できます。

アクセスが拒否された（この操作を行うには、SUPER の権限の少なくとも 1 つが必要）

Access denied; you need (at least one of) the SUPER privilege(s) for this operation というエラーが表示されます。

次のような問題が考えられます

ソース データベースに、スーパー ユーザー@localhost（root@localhost など）を使用するイベント、ビュー、関数、プロシージャが存在する可能性があります。これは Cloud SQL ではサポートされていません。

次の方法をお試しください

DEFINER 句を含むデータベースの移行については、こちらのドキュメントをご覧ください。

エラー メッセージ: Definer user 'x' does not exist. Please create the user on the replica.

Definer user 'x' does not exist. Please create the user on the replica. というエラーが表示されます。

次のような問題が考えられます

根本原因は、DEFINER 句を含むソース データベースのユーザーがレプリカ データベースに存在しないことです。

次の方法をお試しください

DEFINER 句を含むデータベースの移行については、こちらのドキュメントをご覧ください。レプリカ データベースでユーザーを作成する必要がある場合があります。

エラー メッセージ: ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost

ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost というエラーが表示されます。

次のような問題が考えられます

根本原因は、DEFINER 句を含むソース データベースのユーザーがレプリカ データベースに存在せず、そのユーザーがソース データベースのオブジェクト定義で相互参照されていることです。

次の方法をお試しください

DEFINER 句を使用してデータベースを移行する方法については、こちらのドキュメントをご覧ください。レプリカ データベースに 1 人以上のユーザーを作成する必要がある場合があります。

テーブルをダンプする際にクエリ中に MySQL サーバーとの接続が切断された

Lost connection to MySQL server during query when dumping table というエラーが表示されます。

次のような問題が考えられます

  • 移行元データベース インスタンスが移行先インスタンスから到達不能になった可能性があります。
  • 移行元データベースに、大きな blob や長い文字列を含むテーブルがある場合は、移行元データベースで max_allowed_packet をより大きな値に設定する必要があります。

次の方法をお試しください

  • 移行元データベース インスタンスが起動していて、到達可能であることを確認します。
  • 移行ジョブで max-allowed-packet フラグを構成し、移行ジョブを再開します。または、max_allowed_packet オプションを指定して手動ダンプを生成し、データをダンプしてダンプファイルを使用して移行します。
  • max_allowed_packet を増やすと、移行元データベースの net_read_timeout と net_write_timeout の設定を調整する必要が生じる可能性が高くなります（通常は、接続エラーがなくなるまで増やす必要があります）。

テーブルをダンプする際に max_allowed_packet バイトを超えるパケットを取得した

Got packet bigger than 'max_allowed_packet' bytes when dumping table というエラーが表示されます。

次のような問題が考えられます

パケットが、設定された許容量を超えました。

次の方法をお試しください

max_allowed_packet オプションを指定した手動ダンプを使用して移行ジョブを作成し、データをダンプしてダンプファイルを使用して移行します。

データは複製されていません

最初のデータの移行は成功しましたが、データが複製されていません。

次のような問題が考えられます

根本原因の一つとして、ソース データベースにレプリケーション フラグがあるため、データベースの一部またはすべての変更が複製されていない可能性があります。

次の方法をお試しください

binlog-do-db、binlog-ignore-db、replicate-do-db、replicate-ignore-db などのレプリケーション フラグが競合する方法で設定されていないことを確認します。
移行元データベースで show master status コマンドを実行して、現在の設定を確認します。

最初のデータ移行は成功したが、しばらくするとデータ レプリケーションが機能しなくなる

最初のデータ移行は成功したが、しばらくするとデータ レプリケーションが機能しなくなる。

次のような問題が考えられます

この問題には、多数の根本原因が考えられます。

次の方法をお試しください

  • Cloud Monitoring で、移行先インスタンスのレプリケーション指標を確認します。
  • MySQL IO スレッドまたは SQL スレッドのエラーは、mysql.err ログファイルの Cloud Logging で確認できます。
  • このエラーは、宛先インスタンスに接続するときにも発生する場合があります。SHOW REPLICA STATUS コマンドを実行して、出力で次のフィールドを確認します。
    • Replica_IO_Running
    • Replica_SQL_Running
    • Last_IO_Error
    • Last_SQL_Error

    注: SHOW REPLICA STATUS は、MySQL 8.0.22 で導入されたエイリアスです。以前のバージョン（MySQL 5.7、MySQL 8.0）では、status コマンドの古いエイリアスを使用します。詳細については、MySQL ドキュメントのステータス ステートメントをご覧ください。

    fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file' in Last_IO_Error エラーが発生した場合は、ソース インスタンスのバイナリログ保持設定が不十分であることが原因である可能性があります。

    error connecting to master 'USER_NAME@SOURCE_HOST:SOURCE_PORT' - retry-time: RETRY_TIME retries: RETRIES エラーが発生した場合は、接続または認証の問題が原因で、移行先インスタンスが移行元に再接続できなかった可能性があります。

mysqld チェックエラー: データディスクに空きがない

mysqld check failed: data disk is full というエラーが表示されます。

次のような問題が考えられます

宛先インスタンスのデータディスクに空き容量がない可能性があります。

次の方法をお試しください

移行先インスタンスのディスクサイズを増やします。

ソース データベースへの接続エラー

ソース データベースへの接続エラー。

次のような問題が考えられます

移行元データベース インスタンスと移行先インスタンスの間に接続の問題がありました。

次の方法をお試しください

接続性のデバッグに関する記事の手順に沿って操作します。

マネージド データベース（Amazon RDS/Aurora）からの移行が開始されない

移行ジョブが開始されない。

次のような問題が考えられます

SUPERUSER 権限なしでマネージド ソース データベースから移行するには、移行の開始時に短時間のダウンタイムが必要です。

次の方法をお試しください

  • Amazon RDS の場合は、こちらの記事の手順に沿って操作してください。
  • Amazon Aurora の場合は、こちらの記事の手順に沿って操作します。

ソース データベースでバイナリログが正しく構成されていない

バイナリログに問題があることを示すエラーが表示されます。

次のような問題が考えられます

これは、ソース データベースで binlog 構成が正しくない場合に、継続的な MySQL 移行ジョブで発生する可能性があります。

次の方法をお試しください

こちらの手順に沿って操作してください。

指定されたダンプファイルの読み取りに失敗しました

ダンプファイルに問題があることを示すエラーが表示される。

次のような問題が考えられます

DMS が、指定されたダンプファイルを見つけることができません。

次の方法をお試しください

  1. ダンプパスを確認して、適切なファイルがあることを確認するか、パスを変更します。
  2. パスを変更する場合は、PATCH リクエストを使用して、ジョブがそのパスを使用するようにします。
  3. 移行ジョブを再開します。

バイナリログの位置が失われたため、レプリケーションを再開できません

バイナリログの位置が失われました。

次のような問題が考えられます

このエラーは、レプリケーション プロセスが長時間一時停止されたときに、バイナリログの位置が失われることによって発生します。バイナリログの保持期間に近づく期間は、移行ジョブを一時停止しないでください。

次の方法をお試しください

移行ジョブを再開します。

ソース データベースと移行先データベースのバージョンに互換性がないため、移行ジョブを実行できない

ソース データベースと宛先データベースのバージョンの組み合わせがサポートされていません。

次のような問題が考えられます

指定されたソース データベースのバージョンは、移行先データベースのバージョンと互換性がありません。

次の方法をお試しください

移行先データベースのバージョンが移行元データベースのバージョンと同じか、1 つ上のメジャー バージョンであることを確認してから、新しい移行ジョブを作成します。

ソース データベース サーバーに接続できない

Unable to connect to source database server というエラーが表示されます。

次のような問題が考えられます

Database Migration Service が移行元データベース サーバーへの接続を確立できない。

次の方法をお試しください

移行元データベース インスタンスと移行先データベース インスタンスが相互に通信できることを確認します。次に、移行ジョブの設定を定義したときに表示された、必要な前提条件をすべて完了していることを確認します。

Cloud SQL 宛先インスタンスのディスク使用量がゼロになる

移行中にディスク使用量が突然ゼロになる。

次のような問題が考えられます

初期データのインポート時にエラーが発生することがあります。この場合、移行プロセスはデータの別の読み込みを試みます。このプロセスでは、まず移行先インスタンスの既存のデータが消去され（ディスク使用量がゼロになるのはこのためです）、その後、データの再読み込みが試行されます。

次の方法をお試しください

ログ エクスプローラに移動し、リソースリストから宛先インスタンスを選択します。次のようなログ メッセージを探します。 DUMP_STAGE(RETRY): Attempt .../...: import failed: error..."; Clearing database and trying again." import failed: テキストの後のメッセージを見つけて、根本的な問題を解決します。