公司官网突然打不开，客服电话立马炸了锅。运维小李一查，发现主服务器负载正常，但数据库没更新。再一看从节点，数据卡在两小时前。问题出在集群同步机制上，数据根本没传过去。
同步卡住，先看日志
遇到同步异常，别急着重启。第一反应应该是查日志。比如用rsync做文件同步的集群，常见问题是传输中断。查看/var/log/rsyncd.log，经常能发现连接超时或权限拒绝的记录。
如果是基于ZooKeeper的分布式协调服务，注意观察各节点的zxid（事务ID）是否一致。不一致说明有节点掉队。可以用命令手动触发状态检查：
echo stat | nc 127.0.0.1 2181网络延迟让心跳失效
集群靠心跳维持联系。某次生产环境同步失败，排查发现是交换机配置变更导致网络抖动。节点之间心跳包延迟超过阈值，被误判为宕机，自动切换引发数据分裂。
这时候用ping和traceroute只能看出大概，得用更精细的工具，比如mtr或者专门监控心跳间隔的脚本。调整超时参数也得谨慎，设太长错过真故障，设太短容易误判。
时间不同步，后果很严重
一台服务器时间快了3分钟，结果任务调度系统重复执行关键脚本，订单生成了双倍。集群里时间差哪怕只有几十秒，也可能让同步逻辑混乱。
必须确保所有节点跑NTP服务。检查命令：
ntpq -p看到offset列数值稳定在毫秒级才算合格。要是发现某个节点频繁偏移，可能是硬件时钟问题，得标记出来重点盯防。
写操作只走主节点
有次开发直接往从库插数据，自以为方便，结果主库同步时冲突，整个集群卡住。大多数集群架构要求所有写入必须通过主节点，否则数据一致性立刻崩盘。
可以在从节点数据库配置只读模式，避免人为误操作：
read_only = on批量任务挤占同步带宽
凌晨跑报表，千兆网络被打满，同步流量被压到几乎为零。等白天业务高峰到来，缓存未更新，用户看到的全是旧信息。
解决方案是在同步进程上加限速策略，比如rsync可以用--bwlimit参数，留够余量给业务流量。也可以把大任务拆成小批次，错峰执行。
配置文件别忽略细节
一个漏写的IP地址，能让整个集群少一个成员。配置文件更新后，务必逐台核对。有人图省事复制粘贴，忘了改主机名，结果多个节点报同一个身份，协调服务直接瘫痪。
建议用自动化工具管理配置，比如Ansible模板，变量注入主机信息，减少手误。