Compartir a través de

排查异地复制和重做滞后问题

适用于：Azure SQL Database

在活动异地复制中，异地辅助副本会持续接收并应用主副本的事务日志记录。 当次要副本无法像主副本生成日志时那样快地应用日志时，积压工作生成（重做队列）和时间差距增加（重做延迟）。 这种情况可能会影响辅助数据库上的只读新鲜度，并增加故障转移时间。

  • 重做队列：异地复制传送到辅助数据库的事务日志量，但尚不适用。
  • 重做延迟：在主要副本上提交事务与在辅助副本上完成重播之间的已用时间。

异地复制是异步的。 次要副本上的重做延迟不会导致主要副本上的等待，但重做延迟可能会导致次要副本上的数据落后。

症状

  • 辅助服务器上的陈旧数据用于只读工作负载（报告、分析或转移读取）。
  • 更长的故障转移时间，这会增加恢复时间目标（RTO）。
  • 辅助系统承受持续的资源压力，降低了其跟上进度的能力。
  • 确认 DMV sys.dm_database_replica_states中的重做滞后时间，如果redo_queue_size > 0正在增加并且secondary_lag_seconds也在增加。

为什么重做积压任务会增长

尽管辅助数据库是只读的，但它仍会维护用于内部作的事务日志，包括从主数据库重播日志记录。 重做队列增长时，辅助数据库必须保留更多事务日志数据。

这种情况可能导致：

  • 辅助数据库上的事务日志增长。
  • 更高的存储消耗量，这可能会影响成本和性能。
  • 超出阈值时的潜在限制情景。

副本大小不匹配的影响

应使用相同的服务级别目标（SLO）、备份存储冗余、 计算层 （预配或无服务器）和计算大小（DTU 或 vCore）配置主副本和异地辅助副本。

如果配置计算大小低于主数据库的辅助数据库，则可能会遇到以下情况：

  • 辅助（CPU、I/O）上的资源争用会降低重做操作的速度。
  • 无法跟上主数据库的事务日志生成速率。
  • 增加重做队列大小，这会使延迟恶化并降低复制有效性。

建议

为了减少重做延迟，维护次要副本上的复制运行状况和日志的高效使用，请按照以下步骤操作：

  • 对齐 SLO 和计算尺寸。 确保辅助数据库的性能层与主数据库相同。

  • 定期监视。 使用动态管理视图（例如 sys.dm_database_replica_states ）跟踪重做延迟和队列大小。 当redo_queue_size > 0得到确认，并且secondary_lag_seconds正在增加时，表明恢复滞后的出现。

  • 优化工作负荷：

    • 减少辅助数据库上长时间运行的事务，并降低主数据库上的高日志生成峰值。
      • 避免在高峰期重新生成大型索引。 重新生成可以获取架构修改（SCH-M）锁，这些锁可能会阻止辅助服务器上的重做线程，并导致重做队列的生成。

相关内容

  • Last updated on