问题排查

使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。

检查您的疑问或问题是否已在以下某个页面中得到解决:

本页面包含以下主题:

备份与恢复

问题 问题排查
您无法查看当前操作的状态。 Google Cloud Console 仅在操作完成后报告成功或失败,而不会显示警告或其他更新。

运行 gcloud sql operations list 命令以列出给定 Cloud SQL 实例的所有操作。

您想要了解发起按需备份操作的人员。 界面未显示开始操作的用户。

查看日志并按文本进行过滤以查找用户。您可能需要对私密信息使用审核日志。相关日志文件包括:

  • cloudsql.googlapis.com/mysql-general.log
  • cloudsql.googleapis.com/mysql.err
  • 如果启用了 Cloud Audit Logs,并且您具有查看这些日志的必要权限,那么 cloudaudit.googleapis.com/activity 也可以使用。
删除实例后,您无法执行备份。 Cloud SQL 实例完全清除的宽限期为四天,读取副本除外,后者会立即完全清除。在此期间,客户服务可以重新创建实例。如果重新创建实例,则其备份也会重新创建。清除实例后,将无法恢复数据。

如果您已完成导出操作,则可以创建新实例,然后执行导入操作以重新创建数据库。导出数据将写入 Cloud Storage,导入数据从此处进行读取。

自动备份停滞了数小时,无法取消。 备份可能需要很长时间,具体取决于数据库大小。

如果您确实需要取消该操作,可以要求客户服务对实例执行 force restart

如果 SQL 转储文件中引用的一个或多个用户不存在,恢复操作可能会失败。 在恢复 SQL 转储之前,拥有对象或获得了对转储数据库中的对象权限的所有数据库用户都必须存在于目标数据库中。否则,恢复操作将无法使用原始所有权或权限重新创建对象。

在恢复 SQL 转储之前,先创建数据库用户

您想要将自动备份的天数从 7 天增加到 30 天,或更长时间。 系统仅保留 7 个备份。由于保留备份的费用和空间占用,备份会定期进行清除。遗憾的是,这也意味着当前可见的备份是所有可以用于恢复的自动备份。

如需无限期地保留备份,您可以创建按需备份,因为它们的删除方式与自动备份不同。按需备份会无限期保留。也就是说,按需备份会一直保留,直到被删除或它们所属的实例被删除为止。由于该类型的备份不会自动删除,因此可能会影响结算。

自动备份失败,但您未收到电子邮件通知。 备份失败时不支持通知。

如果自动备份失败,Cloud SQL 实例的 Details 页面中将显示 Operation error 消息。

您可以通过 REST APIgcloud 命令查找备份的状态。例如,首先列出实例的备份,然后按 ID 描述特定备份:


gcloud sql backups list \
--project=PROJECT_ID \
--instance=INSTANCE_ID
   

gcloud sql backups describe BACKUP-ID \
--instance=INSTANCE_ID
    

克隆

问题 问题排查
克隆失败并显示 constraints/sql.restrictAuthorizedNetworks 错误。 克隆操作被 Authorized Networks 配置阻止。在 Google Cloud Console 的“连接”部分中为公共 IP 地址配置了 Authorized Networks,并且出于安全考虑,不允许克隆。

如果可以,请移除 Cloud SQL 实例中的所有 Authorized Networks 条目。否则,请创建副本(不包含 Authorized Networks 条目)。

错误消息:Failed to create subnetwork. Couldn't find free blocks in allocated IP ranges. Please allocate new ranges for this service provider. Help Token: [help-token-id].

您正尝试使用 Google Cloud 控制台克隆具有专用 IP 地址的实例,但您未指定要使用的已分配 IP 范围,并且未创建具有指定范围的来源实例。因此,克隆的实例是在随机范围内创建的。

使用 gcloud 克隆实例,并为
--allocated-ip-range-name 参数提供值。如需了解详情,请参阅克隆具有专用 IP 的实例

连接

问题 问题排查
Aborted connection 可能的问题:
  • 网络不稳定。
  • 没有对 TCP keep-alive 命令的响应(客户端或服务器无响应,可能超载)。
  • 超出了数据库引擎的连接生命周期,服务器终止了该连接。

应用必须能够容忍网络故障并遵循最佳做法,例如连接池和重试。大多数连接池程序会尽可能捕获这些错误。否则,应用必须正常重试或失败。

对于连接重试,我们建议使用以下方法:

  1. 指数退避算法。以指数方式增加每次重试之间的时间间隔。
  2. 另外,增加随机退避时间。

结合使用这些方法有助于减少限制。

创建实例

问题 问题排查
您看到错误消息:Failed to create subnetwork. Couldn't find free blocks in allocated IP ranges. Please allocate new ranges for this service provider 分配的 IP 范围中没有更多的可用地址。 可能存在多种潜在情况:

  • 专用服务连接所分配 IP 地址范围的大小小于 /24。
  • 专用服务连接所分配 IP 地址范围的大小对于 Cloud SQL 实例数量而言太小。
  • 如果在多个区域中创建实例,则分配的 IP 地址范围大小要求将更大。请参阅分配的范围大小

对于上述每种场景,您可以选择扩大已分配的现有 IP 地址范围,也可以选择将额外的 IP 地址范围分配给专用服务连接

如果您在创建 Cloud SQL 实例时使用 --allocated-ip-range-name 标志,则只能扩大指定的 IP 地址范围。

如果您要分配新范围,请注意分配的范围不会与任何现有的分配范围重叠。

创建新的 IP 地址范围后,使用以下命令更新 VPC 对等互连:


gcloud services vpc-peerings update \
--service=servicenetworking.googleapis.com \
--ranges=OLD_RESERVED_RANGE_NAME,NEW_RESERVED_RANGE_NAME \
--network=VPC_NETWORK \
--project=PROJECT_ID \
--force
    

如果要扩大现有的分配范围,请注意只能扩大分配范围,不能缩减分配范围。例如,如果原始分配范围是 10.0.10.0/24,则新分配范围至少为 10.0.10.0/23。

一般来说,如果从 /24 分配范围开始,对于每个条件(额外的实例类型组、额外的区域),将“/子网掩码位数”递减 1 是一种较好的做法。例如,如果尝试在同一分配范围中创建两个实例类型组,则从 /24 递减到 /23 就足够了。

扩大现有 IP 地址范围后,使用以下命令更新 VPC 对等互连:


gcloud services vpc-peerings update \
--service=servicenetworking.googleapis.com \
--ranges=RESERVED_RANGE_NAME \
--network=VPC_NETWORK \
--project=PROJECT_ID
    

导出

问题 问题排查
HTTP Error 409: Operation failed because another operation was already in progress. 您的实例已有一项待处理的操作。一次只能执行一项操作。在当前操作完成后尝试您的请求。
HTTP Error 403: The service account does not have the required permissions for the bucket. 确保存储桶已存在,并且 Cloud SQL 实例(正在执行导出)的服务帐号具有 Storage Object Creator 角色 (roles/storage.objectCreator) 以允许导出到存储桶。请参阅适用于 Cloud Storage 的 IAM 角色
CSV 导出成功,但 SQL 导出失败。 CSV 和 SQL 格式的导出方式不同。SQL 格式会导出整个数据库,可能需要较长的时间才能完成。CSV 格式可让您定义要导出的数据库元素。

使用 CSV 导出以仅导出您需要的文件。

导出时间太长。 Cloud SQL 不支持并发同步操作。

使用导出分流。概括来讲,在进行导出分流时,Cloud SQL 会启动一个分流实例来执行导出,而不是在源实例上发起导出。导出分流具有多项优势,包括可提高源实例的性能,以及在导出操作期间取消屏蔽管理操作。使用导出分流时,总延迟时间会增加,因为启动分流实例需要时间。通常,对于规模合理的导出,延迟时间并不明显。但是,如果导出作业足够小,那么您可能会发现延迟时间有所增加。

您希望自动执行导出。 Cloud SQL 不提供自动执行导出的方法。

您可以使用 Cloud Scheduler、Pub/Sub 和 Cloud Functions 等 Google Cloud 产品构建自己的自动导出系统,类似自动备份一文所述。

外部主实例

问题 问题排查
Lost connection to MySQL server during query when dumping table 来源可能不可用,或者转储包含的数据包过大。

确保外部主实例可供连接,或将 max_allowed_packet 选项与 mysqldump 结合使用。

如需详细了解如何使用 mysqldump 标志进行托管式导入迁移,请参阅允许和默认的初始同步标志

初始数据迁移成功,但未复制任何数据。 一个可能的根本原因是源数据库已定义了复制标志,导致部分或所有数据库更改没有被复制。

确保没有以冲突的方式设置 binlog-do-dbbinlog-ignore-dbreplicate-do-dbreplicate-ignore-db 等复制标志。

在主实例上运行 show master status 命令以查看当前设置。

初始数据迁移成功,但一段时间后数据复制停止工作。 可以尝试的操作:

  • 在 Google Cloud Console 的 Cloud Monitoring 部分中查看副本实例的复制指标
  • MySQL IO 线程或 SQL 线程中的错误可以在 mysql.err log 文件的 Cloud Logging 中找到。
  • 在连接到副本实例时,也可能会发现此错误。 运行 SHOW SLAVE STATUS 命令,并在输出中检查以下字段:
    • Slave_IO_Running
    • Slave_SQL_Running
    • Last_IO_Error
    • Last_SQL_Error
mysqld check failed: data disk is full 副本实例的数据磁盘已满。

增加副本实例的磁盘大小。 您可以手动增加磁盘大小或启用存储空间自动扩容功能。

外部副本

问题 问题排查
错误消息:The slave is connecting ... master has purged binary logs containing GTIDs that the slave requires 主 Cloud SQL 实例具有自动备份和二进制日志,并且启用了时间点恢复,因此它应该具有副本可以捕获的足够的日志。但在这种情况下,虽然存在二进制日志,但副本不知道从哪个行开始读取。

使用正确的标志设置创建一个新的转储文件,并使用该文件配置外部副本

  1. 通过 Compute Engine 实例连接到您的 mysql 客户端。
  2. 运行 mysqldump 并使用 --master-data=1--flush-privileges 标志。

    重要提示:请勿添加 --set-gtid-purged=OFF 标志

    了解详情

  3. 确保刚创建的转储文件包含 SET @@GLOBAL.GTID_PURGED='...' 行。
  4. 将转储文件上传到 Cloud Storage 存储桶,然后使用转储文件配置副本

标志

问题 问题排查
启用标志后,实例会在错误和崩溃之间循环。 请与客户服务联系,请求移除标志,然后执行 hard drain。这会强制实例在使用新配置(没有不需要的标志或设置)的其他主机上重启。
尝试设置标志时,您看到错误消息 Bad syntax for dict arg与 gcloud 命令搭配使用时,复杂的参数值(例如以英文逗号分隔的列表)需要特殊处理。

高可用性

问题 问题排查
找不到手动故障切换的指标。 只有自动故障切换会纳入指标。
Cloud SQL 实例资源(CPU 和 RAM)使用率接近 100%,导致高可用性实例发生故障。 实例机器大小对于负载而言过小。

对实例进行修改以升级为更大的机器,从而获得更多 CPU 和内存。

导入

问题 问题排查
HTTP Error 409: Operation failed because another operation was already in progress 您的实例已有一项待处理的操作。一次只能执行一项操作。在当前操作完成后尝试您的请求。
导入操作花费的时间太长。 过多的有效连接可能会干扰导入操作。

关闭未使用的操作。检查 Cloud SQL 实例的 CPU 和内存用量,以确保有大量的可用资源。确保将最多资源用于导入操作的最佳方法是在开始执行操作之前重启实例。

重启后,系统会执行以下操作:

  • 关闭所有连接。
  • 结束任何可能正在消耗资源的任务。
如果转储文件中引用的一个或多个用户不存在,导入操作可能会失败。 在导入转储文件之前,拥有对象或获得了对转储数据库中的对象权限的所有数据库用户都必须存在于目标数据库中。否则,导入操作将无法使用原始所有权或权限重新创建对象。

在导入之前,先创建数据库用户

导入操作因表不存在而失败。 表可以与其他表有外键依赖关系,根据操作的顺序,其中一个或多个表可能在导入操作期间还不存在。

可以尝试的操作:

在转储文件的开头添加以下行:


SET FOREIGN_KEY_CHECKS=0;
  

此外,请在转储文件的末尾添加以下行:


SET FOREIGN_KEY_CHECKS=1;
  

这些设置会在导入操作执行期间停用数据完整性检查,并在加载数据后重新激活数据完整性检查。这不会影响数据库中数据的完整性,因为数据在创建转储文件期间已经过验证。

日志记录

问题 问题排查
未找到审核日志。 只有当操作是经过身份验证的用户进行的 API 调用(用于创建、修改或读取用户创建的数据),或者操作访问配置文件或资源元数据时,才会写入数据访问日志。
在日志中找不到操作信息。 您想要详细了解某项操作。

例如,用户已被删除,但您找不到谁执行了此操作。日志显示操作已开始,但未提供任何更多信息。您必须为要记录的详细个人身份信息 (PII) 等启用审核日志记录

Logging 占用了大量磁盘空间。 有三种类型的日志文件占用磁盘空间:重做日志、常规日志和二进制日志。

连接到数据库并运行以下命令以获取每种类型的详细信息:


SHOW VARIABLES LIKE 'innodb_log_file%';

SELECT ROUND(SUM(LENGTH(argument)/POW(1024,2),2)
AS GB from mysql.general_log;

SHOW BINARY LOGS;
    
日志文件难以读取。 最好以 json 或文本形式查看日志。您可以使用 gcloud logging read 命令以及 Linux 后处理命令来下载日志。

如需将日志下载为 JSON,请执行以下操作:


gcloud logging read \
"resource.type=cloudsql_database \
AND logName=projects/PROJECT_ID \
/logs/cloudsql.googleapis.com%2FLOG_NAME" \
--format json \
--project=PROJECT_ID \
--freshness="1d" \
> downloaded-log.json
    

如需将日志下载为 TEXT,请执行以下操作:


gcloud logging read \
"resource.type=cloudsql_database \
AND logName=projects/PROJECT_ID \
/logs/cloudsql.googleapis.com%2FLOG_NAME" \
--format json \
--project=PROJECT_ID \
--freshness="1d"| jq -rnc --stream 'fromstream(1|truncate_stream(inputs)) \
| .textPayload' \
--order=asc
> downloaded-log.txt
   

管理实例

问题 问题排查
重启 MySQL 后性能下降。 Cloud SQL 允许在 InnoDB 缓冲区池中缓存数据。 但是,重启后,此缓存始终为空,并且所有读取操作都需要往返后端才能获取数据。因此,在缓存被填满之前,查询可能比预期慢。
崩溃恢复速度缓慢。 可能已累积大型 general_log。 您可以通过阻止累积大型 general_log 来缩短崩溃恢复时间。如果启用了 general_log,请截断表并仅在短时间内启用 general_log

您可以通过连接到数据库并运行以下查询来了解常规日志的大小:

SELECT ROUND(SUM(LENGTH(argument)/POW(1024,2)),2) from mysql.general_log;
您想要了解哪些内容占满了存储空间。 例如,您发现数据库仅使用了 3 GB,但存储空间却显示使用了 14 GB。表未占用的大多数空间都被二进制日志和/或临时文件占用了。

可以尝试的操作:

  • 您可以在 MySQL 命令行界面中使用以下命令检查二进制日志占用的存储空间: SHOW BINARY LOGS;
  • 临时表可能还占用了大量存储空间。要检查临时空间用量,请使用以下命令:SELECT * FROM INFORMATION_SCHEMA.FILES WHERE TABLESPACE_NAME='innodb_temporary'\G
  • 使用以下命令可检查重做日志大小:SHOW VARIABLES LIKE 'innodb_log_file%';
  • 您可以借助以下命令检查 general_log(如果已启用)的大小:SELECT ROUND(SUM(LENGTH(argument)/POW(1024,2)),2) AS GB from mysql.general_log;
  • 如果需要,您可使用 API 截断日志表。如需了解详情,请参阅 instances.truncateLog 参考页面
  • 详细了解如何设置配置慢查询日志。
查询被阻止。 查询可能锁定 MySQL 数据库,导致所有后续查询被阻止/超时。

连接到数据库并执行以下查询:

SHOW PROCESSLIST

列表中的第一项可能是占用锁的项,后续项正在等待获取该锁。

SHOW INNODB STATUS 查询可能也会有帮助。

您无法手动删除二进制日志。 无法手动删除二进制日志。 二进制日志会连同其相关联的自动备份自动删除,通常是大约七天后删除。
您想要查找有关临时文件的信息。 名为 ibtmp1 的文件用于存储临时数据。此文件在数据库重启时重置。 如需查找有关临时文件使用情况的信息,请连接到数据库并执行以下查询:

SELECT * FROM INFORMATION_SCHEMA.FILES WHERE TABLESPACE_NAME='innodb_temporary'\G

您想要了解表的大小。 此信息可以在数据库中找到。

连接到数据库并执行以下查询:

SELECT TABLE_SCHEMA, TABLE_NAME, sum(DATA_LENGTH+INDEX_LENGTH)/pow(1024,2) FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA NOT IN ('PERFORMANCE_SCHEMA','INFORMATION_SCHEMA','SYS','MYSQL') GROUP BY TABLE_SCHEMA, TABLE_NAME;

mysqld 收到了信号 11。 尝试重构查询,使其不会创建过多的连接。如果没有解决问题,请与客户服务联系。信号 11 通常表示 MySQL 软件问题。

InnoDB: page_cleaner: 1000ms intended loop took 5215ms. The settings might not be optimal. 页面清理线程无法跟上实例上的更改速率。 页面清理线程每秒扫描缓冲池一次,以将脏页从缓冲池刷入磁盘。您看到的警告表明它有许多脏页要刷入,并且将一批脏页刷入磁盘需要的时间超过了一秒。

如有可能,对实例进行分片。使用多个较小的 Cloud SQL 实例要优于使用一个大型实例。

临时存储使自动存储空间增加。 启用了自动存储空间。

重启会删除临时文件,但不会减少存储空间。只有客户服务才能重置实例大小。

数据被自动删除。 很有可能是某个脚本正在您的环境中的某个位置运行。

查看删除时间点前后的日志,看看是否有在信息中心或其他自动化进程中运行的恶意脚本。

无法删除实例。 您可能会看到错误消息 ERROR: (gcloud.sql.instances.delete) HTTP Error 409: The instance or operation is not in an appropriate state to handle the request,或者实例可能具有 INSTANCE_RISKY_FLAG_CONFIG 标志状态。

以下是一些可能的原因:

  • 另一项操作正在进行中。 Cloud SQL 操作不会并发运行。等待其他操作完成。
  • 只要使用至少一个 beta 标志,就会触发 INSTANCE_RISKY_FLAG_CONFIG 警告。移除存在风险的标志设置并重启实例。
实例因临时数据大小较大而停滞。 系统可以一次创建多个临时表,具体取决于查询和负载。

遗憾的是,除了重启该服务,没有其他任何方法能缩小 ibtmp1 文件。

一种缓解方法是使用 ROW_FORMAT=COMPRESSED 标志创建临时表,这会将临时表存储在临时文件目录下的单表文件表空间中。但是,这样做的缺点是为每个临时表创建和移除单表文件表空间会降低性能。

升级过程中出现严重错误。 日志可能会显示更多信息,但在任何情况下都可能需要客户服务来强制重新创建实例。
实例在磁盘空间用尽后重启时停滞。 未启用存储空间自动扩容功能。

如果实例的存储空间不足,并且未启用存储空间自动扩容功能,则实例将进入离线状态。为避免此问题,您可以对实例进行修改,以启用存储空间自动扩容功能。

本地主实例停滞。 Google Cloud 无法帮助处理非 Cloud SQL 实例。
重启时关停速度缓慢。 实例关停时,任何未在 60 秒内终止的未完成连接都会导致关停异常。

通过使用持续时间少于 60 秒的连接,可以避免大多数异常关停,包括来自数据库命令提示符的连接。如果您将这些连接保持打开状态数小时或数天,则关停可能会出现异常情况。

无法删除用户。 用户在数据库中可能有依赖于该用户的对象。您需要删除这些对象或将其重新分配给其他用户。

确定哪些对象依赖于该用户,然后删除这些对象或将其重新分配给其他用户。

本文介绍如何查找用户拥有的对象。
某些查询运行速度缓慢。 查询可能会由于多种原因而缓慢运行,主要是由于特定数据库方面。可能会涉及 Cloud SQL 的一个原因是当来源(写入或读取)资源和目的地 (Cloud SQL) 资源位于不同区域时发生网络延迟。

请参阅一般性能提示,具体而言:

对于缓慢的数据库插入、更新或删除操作,请考虑以下事项:

  • 您可以启用 long_query_time 标志以检查慢速查询的日志。转到项目的日志浏览器页面,然后运行如下查询:
    
    resource.type="cloudsql_database"
    resource.labels.database_id="INSTANCE-ID"
    log_name="projects/PROJECT-ID/logs/cloudsql.googleapis.com%2Fmysql-slow.log"
          

    您可以以 JSON 或 TEXT 格式下载日志以进行本地处理。

  • 检查写入者和数据库的位置;长距离发送数据会导致延迟。
  • 检查读取者和数据库的位置;相对于写入性能,延迟对读取性能的影响更大

为了缩短延迟时间,建议您在同一区域中查找来源资源和目的地资源。

表明内存不足,但监控图表未显示。 实例可能会失败并报告 Out of memory,但 Google Cloud Console 或 Cloud Monitoring 图表似乎显示仍然剩余内存。

除了工作负载以外,其他因素(例如活跃连接和内部开销进程的数量)可能也会影响内存使用量。这些指标不一定会反映在监控图表中。

确保该实例的开销足以满足您的工作负载和一些额外开销。

恢复已删除的实例。 删除某个实例时,该实例上的所有数据(包括备份)都会永久丢失。

如需保留数据,请在删除实例之前将数据导出到 Cloud Storage

Cloud SQL Admin 角色具有删除实例的权限。为防止意外删除,请仅在需要时授予此角色。

您想要重命名现有 Cloud SQL 实例。 不支持重命名现有实例。

可采用其他方法通过创建新实例来实现此目标。

  • 您可以克隆要重命名的实例,并为克隆的实例设置新名称。这样一来,您无需手动导入数据即可创建新实例。与创建新实例时一样,克隆的实例具有新的 IP 地址。
  • 您可以将实例中的数据导出到 Cloud Storage 存储桶,使用所需的新名称创建一个新实例,然后将数据导入到新实例。

在这两种情况下,您都可以在操作完成后删除旧实例。建议您使用克隆路由,因为它不会影响性能,并且您无需重新进行任何实例配置设置(例如标志、机器类型、存储空间大小和内存)。

删除实例时出错。 如果为实例启用了删除保护,请确认您计划删除该实例。然后,先停用删除保护,再删除该实例。

复制

问题 问题排查
创建时只读副本未开始复制。 日志文件中可能有更具体的错误信息。在 Cloud Logging 中查看日志以找到实际错误。
无法创建只读副本 - invalidFlagValue 错误 请求中的某个标志无效。它可能是您明确提供的标志,也可能是设置为默认值的标志。

首先,检查 max_connections 标志的值是否大于或等于主实例上的值。

如果 max_connections 标志设置正确,请在 Cloud Logging 中检查日志以找出实际错误。

无法创建只读副本 - 未知错误。 日志文件中可能有更具体的错误信息。在 Cloud Logging 中查看日志以找到实际错误。

如果错误为 set Service Networking service account as servicenetworking.serviceAgent role on consumer project,则停用 Service Networking API,然后重新启用。此操作会创建继续执行该过程所需的服务帐号。

磁盘已满。 主实例磁盘大小可能在副本创建期间变满。 修改主实例以将其升级为更大的磁盘。
副本实例占用的内存过多。 副本使用临时内存来缓存经常请求的读取操作,这可能会导致其占用的内存多于主实例。

重启副本实例以收回临时内存空间。

已停止复制。 已达到存储空间上限,且未启用存储空间自动扩容功能。

修改实例以启用 automatic storage increase

复制延迟一直很高。 写入负载过高,副本无法处理。当副本上的 SQL 线程无法与 IO 线程保持同步时,会发生复制延迟。某些类型的查询和工作负载会导致指定架构出现暂时性或永久性的高复制延迟。下面列出了复制延迟的部分常见原因:
  • 对副本的查询速度较慢。找到这些查询并进行修复。
  • 所有表都必须具有唯一键/主键。每次更新此类没有唯一键/主键的表都会导致对副本进行全表扫描。
  • 由于大量更新堆积在副本上,因此 DELETE ... WHERE field < 50000000 等查询会导致基于行的复制出现复制延迟。

以下是一些可行的解决方案:

复制延迟时间突然激增。 这是因为长时间运行的事务导致。当事务(单语句或多语句)在源实例上提交时,事务的开始时间记录在二进制日志中。当副本收到此 binlog 事件时,会将该时间戳与当前时间戳进行比较,以计算复制延迟时间。因此,来源上的长时间运行的事务将导致副本的复制延迟时间大幅度增加。如果事务中的行更改量很大,则副本还会花费很长时间来执行它。在此期间,复制延迟时间不断增加。一旦副本完成此事务,同步周期将取决于来源上的写入工作负载以及副本的处理速度。

为了避免长时间运行的事务,可以考虑一些可能的解决方案,包括:

  • 将事务拆分为多个小事务
  • 将单个大型写入查询分成较小的批次
  • 尝试将长时间运行的 SELECT 查询与混合 DML 的事务分开
更改并行复制标志会导致错误。 一个或多个这些标志的值设置错误。

在显示错误消息的主实例上,设置并行复制标志:

  1. 修改 binlog_transaction_dependency_trackingtransaction_write_set_extraction 标志:
    • binlog_transaction_dependency_tracking=COMMIT_ORDER
    • transaction_write_set_extraction=OFF
  2. 添加 slave_pending_jobs_size_max 标志:

    slave_pending_jobs_size_max=33554432

  3. 修改 transaction_write_set_extraction 标志:

    transaction_write_set_extraction=XXHASH64

  4. 修改 binlog_transaction_dependency_tracking 标志:

    binlog_transaction_dependency_tracking=WRITESET

副本创建失败并超时。 主实例上长时间运行的未提交事务可能会导致只读副本创建失败。

停止所有正在运行的查询后重新创建副本。