复制延迟 Replication lag

原因 ID db-replica-lag · 主责 运维团队·数据库运维 · 配合研发团队·服务器开发

写入走主库、读取走从库时，如果从库同步落后，刚写入的内容就读不到。

起因写入集中涌向主库，从库落后几秒 → 结果刚保存的内容，去从库读时还没有 → 画面表现 刚买的物品看不到，交易所价格还是旧值，出现重复发放 bug

症状: 吞操作/回档
因素: 延迟
谁会遇到: 仅特定功能
何时出现: 人多的时候, 晚高峰
负责方: 主责 运维团队·数据库运维 · 配合研发团队·服务器开发
研发团队要做的事: 刚写入的数据从主库读；检查是否已发放和执行发放，在主库的同一个事务里完成（用唯一键或条件 UPDATE 防止重复）。
运维团队要做的事: 复制延迟告警；从库规格不低于主库并启用并行复制；大批量删除拆小分批执行；管控在从库上长时间运行的统计查询。
监控图上: 随人数/负载上升 · 复制延迟（秒）
查看位置: MySQL 在从库上看 SHOW REPLICA STATUS 的 Seconds_Behind_Source（8.0.22 之前的版本用 SHOW SLAVE STATUS）。PostgreSQL 看主库 pg_stat_replication 的 write_lag、flush_lag、replay_lag，RDS 看 ReplicaLag
确认依据: 玩家反馈“看不到”的时刻延迟在几秒以上，延迟消除后再看就正常。写入激增、大批量删除或在从库上运行长统计查询时，延迟变大
排除依据: 延迟接近 0 仍然看不到，属于游戏服务器的缓存或同步问题
确认手段: 运维工具即可确认（无需游戏代码）
深入了解: 写入不多也可能落后。主库上耗时 10 分钟的一次大批量删除，在从库上重放期间也会让从库落后同样的时间；在从库上长时间运行的统计查询也会拖慢同步。

出处

SHOW REPLICA STATUS Statement MySQL
Seconds_Behind_Source：从库当前正在应用的事件与它在主库上被记录的时间之差（复制延迟）
Replica Server Options and Variables MySQL
通过 replica_parallel_workers 让多个线程并行应用事务（默认 4；为 0 时由一个线程按顺序应用）
Log-Shipping Standby Servers (PostgreSQL Documentation) PostgreSQL
流复制默认是异步的，提交与从库生效之间有延迟（从库跟得上时通常不到 1 秒）
MySQL 8.0 Reference Manual: SHOW REPLICA STATUS Statement MySQL
从 8.0.22 起用 SHOW REPLICA STATUS 取代 SHOW SLAVE STATUS，之前的版本用 SHOW SLAVE STATUS
The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
pg_stat_replication 的 write_lag、flush_lag、replay_lag：主库写入 WAL 后，到从库报告已写入、已刷盘、已应用为止所用的时间
Amazon CloudWatch metrics for Amazon RDS AWS
ReplicaLag：只读副本落后于源实例的时间（秒）