MySQL の問題を診断する

MySQL   |  PostgreSQL   |  PostgreSQL to AlloyDB

エラーのトラブルシューティング

移行ジョブ プロセスで、ランタイム中にエラーが発生することがあります。

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

エラーが発生すると、移行ジョブのステータスは 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 '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 の変更を回避します。
エラー メッセージ: Access denied; you need (at least one of) the SUPER privilege(s) for this operation	ソース データベースに、super user@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 権限のないマネージド ソース データベースから移行する場合、移行の開始時に短時間のダウンタイムが必要です。	こちらの記事の手順に沿って対応してください。
ソース データベースで、バイナリログが正しく構成されていません。	Binlog の定義が正しくない。	継続的な MySQL 移行ジョブの場合は、必要な binlog 定義に従ってください。
ダンプファイルが見つからないこと。	DMS が指定されたダンプファイルを検出できません。	これは、移行ジョブが指定された場所でダンプファイルを検出できない場合に発生することがあります。 ダンプパスを確認して、適切なファイルが存在することを確認するか、パスを変更します。 パスを変更する場合は、PATCH リクエストを使用して、ジョブでそのパスが使用されるようにします。 移行ジョブを再起動します。
バイナリログの位置が失われたため、レプリケーションを再開できません。	バイナリログの位置が失われ、移行ジョブを再開できませんでした。	このエラーは、レプリケーション プロセスが長時間一時停止されたときに、バイナリログの位置が失われることによって発生します。バイナリログの保持期間に近づく期間は、移行ジョブを一時停止しないでください。移行ジョブを再起動します。
既存の宛先インスタンスに移行すると、次のエラー メッセージが表示されます。 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 などのクエリでは、レプリカに膨大な数の更新が蓄積されるため、行ベースのレプリケーションでレプリケーション ラグが発生します。	考えられる解決策は次のとおりです。 レプリカが MySQL バージョン 5.7（以降）の場合は、並列レプリケーションを構成します。 レプリカの innodb_flush_log_at_trx_commit フラグを 2 に設定します。このフラグの詳細については、フラグの使用に関するヒントをご覧ください。 Cloud SQL for MySQL インスタンスを編集してレプリカのサイズを増やします。 ソース データベースの負荷を軽減します。 主キーまたは一意のキーのないテーブルについては、レプリカでテーブルにインデックスを作成します。 ソース データベースのテーブルにインデックスを作成します。この場合、移行ジョブを再起動する必要があります。 ソース データベースの遅いクエリを特定して修正します。
エラー メッセージ: '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 レプリカでサポートされていない文字セットまたは照合順序が使用されている可能性があります。たとえば、MySQL 5.7 と互換性のある AWS Aurora バージョン 2.x があります。ただし、このバージョンは utf8mb4_0900_as_ci 照合をサポートしています。これは Cloud SQL for MySQL 5.7 ではサポートされていません。	完全なダンプ フェーズで移行に失敗した場合は、サポートされていない文字セットまたは照合が使用されていないかどうか、ソーステーブルの定義を確認します。可能であれば、サポートされている文字セットまたは照合順序に更新します。 CDC フェーズで移行に失敗した場合は、レプリカのステータスを確認し、移行に失敗する原因となっている binlog を見つけます。次に、ソース データベースとアプリケーションを調べて、文字セットまたは照合順序を使用する 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 検証を一時的に無効にする手順は次のとおりです。

次の場合は...	次に...
新しい宛先インスタンスに移行する場合	移行ジョブを再作成する。 [宛先を定義する] の手順の最後で、[オプションの構成を表示] をクリックします。 [フラグ] セクションで、innodb_strict_mode フラグを選択し、Off に設定します。 移行が完了したら、innodb_strict_mode フラグを On に設定します。Cloud SQL for MySQL ドキュメントのデータベース フラグを構成するをご覧ください。
既存の移行先インスタンスに移行する場合	Cloud SQL で移行先インスタンスに移動し、innodb_strict_mode フラグを Off に設定します。Cloud SQL for MySQL ドキュメントのデータベース フラグを構成するをご覧ください。 移行ジョブを再作成します。 移行が完了したら、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）: <スキーマ名> 内の不明なテーブル

移行ジョブが失敗し、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 というエラーが表示されます。

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

ソース データベースに、super user@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 UI で、宛先インスタンスのレプリケーション指標を確認します。
• 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 の場合は、こちらの記事の手順に沿って操作します。

---

ソース データベースで、バイナリログが正しく構成されていません。

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

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

これは、ソース データベースでバイナリログ構成が正しくない場合に、連続する 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: テキストの後のメッセージを探し、根本的な問題を解決してください。