ZooKeeper 生产检查清单

适用 ZooKeeper 3.8 / 3.9；4lw 的默认行为以 3.5.3+ 为准。默认值标注版本，版本差异以官方文档为准。只列不做会丢数据、会不可用、会查不出故障的动作；机制解释见本目录各篇正文。

上线前

[ ] 3 或 5 节点、奇数、跨机架/可用区：3 节点容忍 1 台，5 节点容忍 2 台；4 节点容错和 3 节点相同。禁止单节点上生产——单节点没有 quorum，重启即不可用。
[ ] dataDir 与 dataLogDir 分盘、用本地盘：事务日志和快照只增不减，放 NFS 会破坏 fsync 语义。按写入量估算增长，数据盘到 70% 启动扩容/清理评估。
[ ] 开启自动清理：autopurge.purgeInterval=0（默认，单位小时，0 表示不清理）、autopurge.snapRetainCount=3、snapCount=100000。不开早晚写满；保留份数要覆盖备份窗口。
[ ] 时间参数对齐：tickTime=2000（ms）、initLimit=10、syncLimit=5；会话超时被夹在 2×tickTime ~ 20×tickTime（默认 4s–40s）。syncLimit×tickTime 是 Follower 同步上限，不是会话超时。
[ ] 4lw 白名单显式配置：3.5.3+ 默认只放行 srvr；需要 mntr/stat/cons/wchs/ruok 就写 4lw.commands.whitelist=srvr,ruok,mntr,stat,cons,wchs，不要用 *。白名单只在启动时读取，改完滚动重启。
[ ] myid 与 server.N 一一对应，并做过恢复演练：清空 dataDir 必须保留 myid；全挂恢复先起 zxid 最大的节点。备份要覆盖快照和事务日志，并在同版本集群验证恢复。

[ ] quorum 与同步：echo mntr | nc <host> 2181 看 zk_server_state、zk_synced_followers 与 zk_followers、zk_pending_syncs；looking 表示未选出 Leader，synced 小于 followers 表示有副本掉队。
[ ] 磁盘增长：df -h 看 dataDir/dataLogDir，ls -1 version-2/log.* version-2/snapshot.* | wc -l 看文件数；增长不降先查自动清理是否生效、是否有异常写入。
[ ] 连接与会话：echo cons | nc <host> 2181 | wc -l 看连接量，按来源 IP 聚合；maxClientCnxns=60（每 IP 每服务端）打满会让新客户端连不上。mntr 的 zk_ephemerals_count 异常增长查临时节点泄漏。
[ ] 延迟与请求堆积：mntr 看 zk_avg_latency、zk_max_latency、zk_outstanding_requests；持续大于 0 先查磁盘 fsync 和网络，再看 Leader 负载。zk_watch_count 异常增长查 Watch 泄漏或羊群效应。

[ ] 单节点挂 → echo ruok | nc <node> 2181、tail -200 zookeeper.out、zkServer.sh status → 3 节点剩 2 台仍有 quorum；只重启这一台，确认 zk_server_state 为 follower/leader 且 Leader 的 zk_synced_followers 恢复，不要同时重启其他节点。
[ ] 过半挂、节点停在 LOOKING → echo srvr | nc <survivor> 2181 看 Mode: looking，比较各节点 version-2/log.* 的最大 zxid → 先启动 zxid 最大的宕机节点，再启动第二台凑够 quorum；不要清空任何节点的 dataDir。
[ ] 全挂 → 确认每台 myid 与 server.N 一致，找最大 zxid → 先起 zxid 最大的节点，再起第二台形成 quorum，最后起其余节点；客户端会话已过期，临时节点消失，业务要重新注册和抢锁。
[ ] 数据损坏 → 启动日志搜 EOFException/Invalid snapshot/Unable to load database，ls -l version-2/ → 先确认其他节点仍有 quorum；只对损坏单节点停进程、移走 version-2、保留 myid，让它从 Leader 全量同步。多数节点同时损坏时不要逐个清空。
[ ] 会话过期、锁丢失 → 客户端日志搜 SessionExpired，mntr 看 zk_max_latency 和 GC 停顿 → ZK 没有锁续期，会话过期即失锁、临时节点删除；先查 GC/网络，业务重新抢锁，不能假设原锁还在。