诊断 MySQL 问题

迁移作业流程在运行时可能会发生错误。

  • 某些错误（例如源数据库上的密码错误）是可恢复的，这意味着这些错误可以修复，并且迁移作业会自动恢复。
  • 有些错误是不可恢复的，例如 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 更改。
错误消息：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 权限的受管源数据库进行迁移，需要在迁移开始时短暂停机。 请按照这篇文章中的步骤操作。
源数据库上的 Binlog 配置不正确。 Binlog 定义不正确。 对于持续 MySQL 迁移作业，请确保遵循所需的 binlog 定义。
未能找到转储文件。 DMS 无法找到提供的转储文件。 如果迁移作业无法在给定位置找到转储文件，就可能会发生这种情况。
  1. 请检查转储路径，确保其中有正确的文件，或更改路径。
  2. 如果您更改了路径，请使用 PATCH 请求，以确保作业使用该路径。
  3. 重启迁移作业。
无法恢复复制，因为 binlog 位置已丢失。 binlog 位置丢失，迁移作业无法恢复。 如果复制过程长时间暂停，导致 binlog 位置丢失，就可能会发生此错误。迁移作业的暂停时间不应接近 binlog 保留期限。重启迁移作业。
当您迁移到 现有目标实例时，会收到以下出错提示： 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 权限的托管源数据库进行迁移会导致在迁移开始时出现短暂的停机时间。 按照从没有 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 阶段失败，请检查副本状态，找到导致迁移失败的 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。您可以使用 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 实用程序会尝试默认导出此表。导出失败，因为该列不存在。

可以尝试的操作

将 --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。

可能的原因

源数据库中可能存在使用超级用户@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，这可能是由于源实例上的 binlog 保留设置不足所致。

    如果您收到错误 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 配置不正确

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

可能的原因

如果源数据库上的 binlog 配置不正确，则可能会发生这种情况（对于持续 MySQL 迁移作业）。

可以尝试的操作

请务必按照此处的步骤操作。

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

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

可能的原因

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

可以尝试的操作

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

无法恢复复制，因为 binlog 位置已丢失

binlog 位置丢失。

可能的原因

如果复制进程暂停时间过长，导致 binlog 位置丢失，则可能会发生此错误。迁移作业的暂停时间不应接近 binlog 保留期限。

可以尝试的操作

重启迁移作业。

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

来源数据库版本和目标数据库版本不是受支持的组合。

可能的原因

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

可以尝试的操作

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

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

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