エラーのトラブルシューティング
移行ジョブ プロセスでは、ランタイム中にエラーが発生することがあります。
- エラーには、ソース データベースの不正なパスワードなど、回復可能なものもあります。つまり、エラーを修正して移行ジョブを自動的に再開できます。
- バイナリログの位置が失われた場合など、回復不能なものもあります。この場合、移行ジョブを最初からやり直す必要があります。
エラーが発生すると、移行ジョブのステータスが Failed に変わり、サブステータスには失敗前の最後のステータスが反映されます。
エラーのトラブルシューティングを行うには、失敗した移行ジョブに移動してエラーを表示し、エラー メッセージに記載されている手順に沿って操作します。
エラーの詳細を表示するには、移行ジョブのリンクを使用して Cloud Monitoring に移動します。ログは特定の移行ジョブにフィルタリングされます。
次の表に、問題とその解決方法の例を示します。
| この問題については... | 次のような問題が考えられます... | 次のことを試します... |
|---|---|---|
| 宛先データベースの設定が、データベースのプロビジョニングに使用された Terraform 構成と異なる。（この問題は、構成ドリフトとも呼ばれます）。 | 既存の移行先データベースに移行する場合、Database Migration Service は移行ジョブを実行するために移行先データベースの特定の設定を変更します。 | 移行ジョブをプロモートした後、Terraform 構成で使用する設定を再適用する必要があります。 Terraform 構成のずれをご覧ください。 |
エラー メッセージ: ERROR: Error executing DDL script for view {view_name} MySQL Error {1049 or 1146 or 1824} |
選択したデータベースに、移行用に選択されていないデータベース内のデータを参照するオブジェクトが含まれているため、初期ダンプが失敗しました。 | 後続のエラー メッセージを調べて、参照されているオブジェクトが欠落しているかどうかを確認します。移行を再試行する場合は、まず、オブジェクトを含むデータベースを移行ジョブに追加するか、参照を含むデータベースを削除します。 |
| CDC フェーズ中にエラーコード 1049、1146、1824 でレプリケーションが失敗しました。 | これは、次のいずれかで DDL ステートメントが実行された場合に発生する可能性があります。
|
後続のエラー メッセージを調べて、参照されているオブジェクトが欠落しているかどうかを確認します。移行を再試行する場合は、まず、オブジェクトを含むデータベースを移行ジョブに追加するか、参照を含むデータベースを削除します。 |
エラー メッセージ: 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 では、列名に |
エラー メッセージで参照されているソース データベース オブジェクトの名前を変更するか、バッククォート（``）で囲んで構文をエスケープします。完了したら、移行ジョブを再試行します。 |
エラー メッセージ: 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 を使用する場合は、--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 権限のないマネージド移行元データベースから移行する場合は、移行の開始時に短時間のダウンタイムが必要です。 | こちらの記事の手順に沿って操作します。 |
| ソース データベースで、バイナリログが正しく構成されていません。 | バイナリログの定義が正しくありません。 | 継続的な MySQL 移行ジョブの場合は、必要な binlog 定義に従っていることを確認してください。 |
| ダンプ ファイルが見つかりませんでした。 | DMS が、指定されたダンプファイルを見つけることができません。 | これは、移行ジョブが指定された場所でダンプファイルを見つけられない場合に発生することがあります。
|
| バイナリログの位置が失われたため、レプリケーションを再開できません。 | バイナリログの位置が失われたため、移行ジョブを再開できませんでした。 | このエラーは、レプリケーション プロセスが長時間一時停止されたときに、バイナリログの位置が失われることによって発生します。バイナリログの保持期間が近づく期間は、移行ジョブを一時停止しないでください。移行ジョブを再開します。 |
既存の宛先インスタンスに移行すると、次のエラー メッセージが表示されます。
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 接続を強制している。 |
ソース インスタンスが Cloud SQL の場合は、SSL/TLS の必須化を参照して、TCP 接続に SSL/TLS が必要かどうかを確認します。 |
| レプリケーション ラグが常に大きい。 | 書き込みの負荷が大きすぎてレプリカで処理できません。レプリケーション ラグは、レプリカの Cloud SQL for MySQL スレッドが I/O スレッドに対応できない場合に発生します。クエリやワークロードによっては、特定のスキーマで一時的または永続的に高いレプリケーション ラグが発生することがあります。レプリケーション ラグの一般的な原因は次のとおりです。
|
考えられる解決策は次のとおりです。
|
エラー メッセージ: '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 ではサポートされていません。 |
|
エラー 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 検証を一時的に無効にする手順は次のとおりです。
| 場合 | その後... |
|---|---|
| 新しい宛先インスタンスに移行する場合 |
|
| 既存の移行先インスタンスに移行する場合 |
|
既存の移行先インスタンスから余分なデータを削除する
既存の宛先インスタンスに移行すると、次のエラー メッセージが表示されます。
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 インスタンスは
read-onlyモードになっています。 移行先インスタンスを昇格させて、書き込みアクセス権を取得します。 - 移行先の Cloud SQL インスタンスに接続します。
- 移行先インスタンスのデータベースから余分なデータを削除します。移行先にはシステム構成データのみを含めることができます。宛先データベースにユーザーデータ（テーブルなど）を含めることはできません。データベースで実行してシステム以外のデータを見つけることができる SQL ステートメントは、次のようにさまざまです。
SELECT schema_name FROM information_schema.SCHEMATA WHERE schema_name NOT IN ('information_schema', 'sys', 'performance_schema', 'mysql');
- 移行ジョブを開始します。
Terraform 構成のずれ
既存の移行先データベースに移行する場合、Database Migration Service は移行ジョブを実行するために移行先データベースの特定の設定を変更します。Terraform でプロビジョニングされたデータベースの場合、この操作により、実際の宛先データベースの構成が Terraform ファイルで設定された構成と異なる構成ドリフトが発生する可能性があります。次の方法をお試しください
移行ジョブの実行中に Terraform 構成を再適用しないでください。移行先のデータベースが昇格された後で、必要な構成を安全に調整できます。Database Migration Service は、移行先の Cloud SQL インスタンスに対して次の変更を行います。- バックアップ構成がデフォルト値に設定されます。
- ポイントインタイム リカバリがデフォルト値にリセットされます。
ERROR 1109 (42S02): Unknown table in <ここにスキーマ名>
移行ジョブが失敗し、次のメッセージが表示されます: 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 オプションを指定して手動ダンプを使用し、データをダンプして、そのダンプファイルを使用して移行を行う移行ジョブを作成します。
複製中のデータがない
最初のデータの移行は成功しましたが、データが複製されていません。
次のような問題が考えられます
根本原因の 1 つとして、ソース データベースにレプリケーション フラグが設定されているため、データベースの一部またはすべての変更が複製されていない可能性があります。
次の方法をお試しください
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）の場合は、ステータス コマンドの古いエイリアスを使用します。詳細については、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 権限のないマネージド移行元データベースから移行する場合は、移行の開始時に短時間のダウンタイムが必要です。
次の方法をお試しください
ソース データベースでバイナリログが正しく構成されていない
バイナリログに問題があることを示すエラーが表示されます。
次のような問題が考えられます
これは、ソース データベースでバイナリログ構成が正しくない場合に、継続的な MySQL 移行ジョブで発生する可能性があります。
次の方法をお試しください
こちらの定義に沿って対応してください。
指定されたダンプファイルの読み取りに失敗しました
ダンプファイルに関する問題を示すエラーが表示されます。
次のような問題が考えられます
DMS が、指定されたダンプファイルを見つけることができません。
次の方法をお試しください
- ダンプパスを確認して、適切なファイルがあることを確認するか、パスを変更します。
- パスを変更する場合は、
PATCHリクエストを使用して、ジョブでそのパスが使用されるようにします。 - 移行ジョブを再開します。
バイナリログの位置が失われたため、レプリケーションを再開できません
バイナリログの位置が失われました。
次のような問題が考えられます
このエラーは、レプリケーション プロセスが長時間一時停止されたときに、バイナリログの位置が失われることによって発生します。バイナリログの保持期間に近づく期間は、移行ジョブを一時停止しないでください。
次の方法をお試しください
移行ジョブを再開します。
移行元データベースと移行先データベースのバージョンに互換性がないため、移行ジョブを実行できません
移行元と移行先のデータベース バージョンがサポートされていない組み合わせです。
次のような問題が考えられます
指定されたソース データベース バージョンは、宛先データベース バージョンと互換性がありません。
次の方法をお試しください
移行先データベースのバージョンが移行元データベースのバージョンと同じか、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: テキストの後のメッセージを見つけて、根本的な問題の解決を試みます。