诊断 MySQL 问题

MySQL   |  PostgreSQL   |  PostgreSQL 到 AlloyDB

排查错误

迁移作业流程在运行时可能会出错。

• 某些错误（例如源数据库上的密码错误）可以恢复，这意味着它们可以得到修复，并且迁移作业会自动恢复。
• 有些错误无法恢复，例如丢失 binlog 位置，这意味着需要从头开始重启迁移作业。

发生错误时，迁移作业状态会更改为 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 系统架构。 如果源数据库包含引用任何这些架构中表的对象，则迁移作业可能会失败。	检查源数据库，看看是否有对象引用未迁移的任何系统架构中包含的表。请参阅错误 1109 (42S02)：<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 更改。
错误消息：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 迁移作业，请确保遵循必需的二进制日志定义。
找不到转储文件。	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 实例包含额外的数据。您只能迁移到空的现有实例。请参阅 已知限制。	将目标实例升级为读写实例，移除多余的数据，然后重试迁移作业。请参阅 清除现有目标实例中的额外数据。
由于源数据库和目标数据库版本不兼容，迁移作业运行失败。	提供的源数据库版本与目标数据库版本不兼容。	确保目标数据库版本与源目标版本相同或比源目标版本高一个主要版本，然后创建新的迁移作业。
错误消息：Unable to connect to source database server.	Database Migration Service 无法与源数据库服务器建立连接。	确保源数据库实例和目标数据库实例可以相互通信，并且您已完成为迁移作业定义设置时显示的所有必要前提条件。
错误消息：Timeout waiting for no write traffic on source.	如果从没有 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 副本不支持的字符集或排序规则。例如，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。实现此操作的一种方法是使用 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` 命令，重新调整目标数据库设置。

---

错误 1109 (42S02)：<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 实用程序默认会尝试导出此表格。导出失败，因为该列不存在。

可以尝试的操作

将 --column-statistics=0 标志添加到 mysqldump 命令，以从导出内容中移除 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 特权才能执行此操作

您会看到错误 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 子句迁移数据库，请参阅此文档。您可能需要在副本数据库中创建一个或多个用户。

---

在查询期间转储表时与 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，请按照这篇文章中的步骤操作。

---

二进制日志在源数据库上配置错误

您看到一条错误消息，指明二进制日志存在问题。

可能的原因

如果源数据库上的二进制日志配置不正确，持续性 MySQL 迁移作业可能会出现这种情况。

可以尝试的操作

请务必遵循此处的定义。

---

读取所提供的转储文件失败

您会看到一条错误消息，表明转储文件存在问题。

可能的原因

DMS 找不到提供的转储文件。

可以尝试的操作

1. 检查转储路径，确保其中包含正确的文件，或更改路径
2. 如果您更改了路径，请使用 PATCH 请求确保作业使用该路径。
3. 重启迁移作业。

---

由于二进制日志位置丢失，无法恢复复制

二进制日志位置丢失。

可能的原因

当复制过程长时间暂停时，可能会发生此错误，从而导致二进制日志位置丢失。迁移作业暂停的时长不得接近二进制日志保留期限。

可以尝试的操作

重启迁移作业。

---

由于源数据库和目标数据库版本不兼容，无法运行迁移作业

源数据库版本和目标数据库版本不受支持。

可能的原因

提供的源数据库版本与目标数据库版本不兼容。

可以尝试的操作

确保目标数据库版本与源目标版本相同或比源目标版本高一个主要版本，然后创建新的迁移作业。

---

无法连接到源数据库服务器

您会看到错误 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: 文本后面的消息，然后尝试解决根本问题。