复制延迟时间

本页面介绍如何排查和修复 Cloud SQL 读取副本的复制延迟问题。

概览

Cloud SQL 读取副本使用 SQL Server Always-On 可用性组进行复制。更改会写入主实例中的事务日志。主实例会将事务转发到任何辅助副本实例，在这些实例中应用更改。使用的可用性模式为异步提交模式。

在几种情况下可能会发生复制延迟，例如：

  • 主实例将更改发送到副本的速度不够快。
  • 副本接收更改的速度不够快。
  • 副本无应用更改的速度不够快。
您可以使用 network_lag metric 监控上述前两个原因。通过 seconds_behind_master 指标观察第三个原因。seconds_behind_master 指标较高表示副本无法足够快速地应用复制更改。下面的监控复制延迟时间部分介绍了这些指标。

优化查询和架构

本部分建议一些可用于提高复制性能的常见查询和架构优化。

读取副本中长时间运行的查询

副本中的长时间运行的查询可能会阻止 Cloud SQL 的复制。您可能希望将单独的副本用于在线事务处理 (OLTP) 和在线分析处理 (OLAP)，并且仅将长时间运行的查询发送到 OLAP 副本。

DDL 导致的独占锁定

数据定义语言 (DDL) 命令（例如 ALTER TABLE 和 CREATE INDEX）可能会导致副本因独占锁定而出现复制延迟。为避免锁定争用，请考虑在副本上的查询负载较低期间安排 DDL 执行。

此外，诸如 CREATE INDEX、ALTER INDEX 和 INDEX MAINTENANCE 等 DDL 语句可能会由于这些语句可以生成大量事务日志记录而导致复制延迟。

过载的副本

如果读取副本收到的查询过多，则系统可能会阻止复制。请考虑在多个副本之间拆分读取，以减少每个副本的负载。

为了避免查询高峰，请考虑在应用逻辑或代理层（如果使用代理层）中限制副本读取查询。

如果主实例上出现活动峰值，请考虑分散更新。

单体式主数据库

请考虑将主数据库垂直（或水平）分片，以防止一个或多个滞后表阻止其他所有表。

监控复制延迟

您可以使用 replica_lag 和 network_lag 指标来监控复制延迟，并确定延迟原因在于主数据库、网络还是副本。

指标说明
复制延迟
(cloudsql.googleapis.com/database/replication/seconds_behind_master)

副本状态晚于主实例状态的秒数。这是次要实例上最后重做的日志记录的时间戳与主实例上最后发送的日志记录的时间戳之间的差值。
网络延迟
(cloudsql.googleapis.com/database/replication/network_lag)

副本上最后收到的日志条目的时间戳与主实例上最后发送的日志条目的时间戳之间的差值。

验证复制

如需验证复制是否正常工作，请检查主实例上 cloudsql.googleapis.com/database/replication/state 指标的值。如果状态为 Running，则表示复制正常。