分布式数据库一旦出现故障，往往不是单点问题，而是涉及网络分区、副本一致性、事务状态残留和节点时钟漂移的综合结果。排查时最忌讳直接重启节点，因为很多故障在重启后会被掩盖，导致后续出现更隐蔽的数据不一致。正确的做法是先确定故障域：是客户端报错、单节点异常、跨节点通信失败，还是整个集群不可用。客户端报错通常和连接池耗尽、SQL超时、分片键路由错误有关；单节点异常常见于磁盘写满、内存压力、线程池阻塞或数据页损坏；跨节点通信失败多与网络抖动、防火墙规则变更、TLS证书过期有关；集群不可用则要优先检查元数据服务、选主协议和仲裁节点状态。

排查的第一步是抓取故障时间点的监控指标，而不是先看日志。分布式数据库的监控必须覆盖几个关键维度：QPS、延迟分位数（P99、P999）、节点间复制延迟、心跳超时次数、磁盘I/O等待时间、连接池活跃连接数、事务冲突重试率。如果P99延迟突然升高但QPS没有明显下降，大概率是慢查询或热点分片导致；如果复制延迟持续增大，说明写入压力超过了副本同步能力，或者网络带宽被其他流量挤占；如果心跳超时次数激增，基本可以判定是网络分区或节点假死。监控数据能帮助你把问题收敛到具体组件，避免在日志海里盲目搜索。

日志分析要按时间线对齐多个节点的输出。分布式数据库的日志分散在每个节点上，单看一个节点的日志很容易误判。建议使用统一的日志收集工具，按事务ID或请求追踪ID串联跨节点调用链。排查时重点关注三类日志：选主与租约日志、事务提交与回滚日志、数据迁移与副本修复日志。选主日志中出现频繁的“lease expired”或“term changed”，说明集群选主不稳定，可能和时钟漂移或GC停顿有关；事务日志中大量“write conflict”或“deadlock detected”，说明业务并发模型和数据库锁机制不匹配；副本修复日志反复出现“repair failed”或“checksum mismatch”，意味着底层存储已经出现数据损坏，需要立即隔离节点。

网络分区是分布式数据库最棘手的故障类型。发生网络分区时，集群会分裂成多个子集群，每个子集群都可能认为自己是主集群并继续接受写入，这就是脑裂。排查脑裂不能只看数据库本身，还要检查交换机日志、机架拓扑和云平台网络事件。确认脑裂后，第一步是切断少数派子集群的写入能力，而不是直接恢复网络。如果直接恢复网络，两个子集群的写入会冲突，数据修复成本极高。正确做法是保留多数派子集群，将少数派节点标记为不可用，等网络恢复后从多数派做全量或增量同步。判断多数派的依据是选主协议中的quorum配置，通常要求超过半数的节点参与投票。

副本不一致的修复需要区分是延迟导致还是数据损坏导致。延迟导致的不一致可以通过等待复制追平解决，但如果延迟持续不下降，就要检查是否存在复制流中断。复制流中断常见于binlog或WAL日志被提前清理、复制线程被阻塞、或者目标节点磁盘性能不足。数据损坏导致的不一致则要立即触发副本重建。重建前必须确认损坏节点上的数据不会再被读取，否则脏数据会扩散到其他副本。操作步骤是：先从集群中摘除损坏节点，再从一个健康副本做全量快照恢复，最后重新加入集群并追平增量日志。整个过程要监控副本同步进度，避免在业务高峰期执行。

事务状态残留是容易被忽略的故障源。分布式事务通常采用两阶段提交或Percolator模型，协调者节点在事务执行到一半时宕机，会留下prepared状态的事务记录。这些残留记录会持有锁，导致后续事务阻塞。排查时可以在元数据表中查询长时间处于prepared状态的事务，按创建时间排序，超过阈值的事务需要人工介入。处理方式是先确认该事务对应的业务操作是否已经完成，如果业务侧已确认提交，则手动提交残留事务；如果业务侧已回滚，则手动回滚。不要盲目清理事务记录，否则可能破坏原子性。对于使用Raft或Paxos协议的数据库，还要检查日志条目是否被正确应用到状态机，未应用的日志条目会在节点重启后重新执行，可能引发重复写入。

节点假死和GC停顿经常被误判为硬件故障。分布式数据库对节点响应时间非常敏感，一次超过数秒的GC停顿就可能导致心跳超时，触发选主和副本切换。如果频繁发生节点切换，但监控显示CPU和内存使用率并不高，就要检查JVM或运行时的GC日志。对于Java技术栈的数据库，重点看Full GC频率和停顿时间，调整堆大小和GC算法通常能缓解；对于Go或Rust技术栈的数据库，要检查内存分配压力和调度延迟。此外，磁盘I/O抖动也会造成节点假死，使用SSD时要注意写入放大和TRIM策略，使用云盘时要关注云厂商的IOPS限制和突发性能耗尽。

运维修复中最实用的手段是建立分级响应机制。一级故障是集群不可用或数据损坏，需要立即隔离故障节点、停止写入、保留现场证据，并通知业务方降级；二级故障是性能严重下降或复制延迟过大，需要限流、扩容或调整参数；三级故障是单节点异常但集群仍可服务，可以安排计划内维护。分级响应的好处是避免小问题被过度操作放大成大故障。很多分布式数据库事故的根源不是初始故障，而是运维人员慌乱中执行了错误操作，比如误删数据目录、强制重启多个节点、或者错误地执行了全量重建。

预防性维护比事后修复更值得投入。分布式数据库的健康检查应该包括：定期校验副本一致性，使用checksum对比各副本数据页；定期演练节点故障切换，验证选主时间和数据丢失窗口；定期检查磁盘空间增长趋势，避免写满导致节点自动下线；定期审查慢查询和热点分片，提前优化分片键和索引设计。对于跨机房部署的集群，还要定期测试机房间网络延迟和带宽，模拟单机房故障时的容灾能力。这些检查项可以做成自动化脚本，每周执行一次，结果输出到运维报表。

参数调优是运维修复中经常被忽视的环节。分布式数据库的默认参数通常偏保守，适合通用场景，但业务模型不同，需要的参数组合也不同。比如写入密集型业务需要调大复制缓冲区、增加刷盘频率、减少检查点间隔；读多写少的业务需要扩大连接池、增加缓存命中率、调整读一致性级别。调参前要明确当前瓶颈是什么，不要照搬其他团队的配置。每次只调整一个参数，观察至少一个完整业务周期，记录性能变化和稳定性指标。参数变更要有版本管理，方便回滚和审计。

数据恢复的最后手段是全量重建加增量追平。当多个副本同时损坏，或者元数据服务不可用导致无法定位分片时，需要从备份恢复。分布式数据库的备份策略必须支持时间点恢复，最好有跨机房或跨区域的异地备份。恢复时要先恢复元数据，再恢复数据分片，最后重建索引和约束。整个过程要验证数据完整性，不能只验证行数，还要抽查关键业务表的数据内容。恢复完成后，需要让应用层做一轮数据校验，确认核心业务数据没有丢失或错乱。

分布式数据库的故障排查和运维修复是一个系统工程，需要把监控、日志、网络、存储、事务和副本机制结合起来分析。遇到问题时，先定位故障域，再按时间线串联证据，最后执行最小化修复操作。日常运维中建立分级响应机制和预防性检查，能显著降低重大故障的发生概率。真正成熟的运维团队，不是能快速解决所有故障，而是能让大部分故障在发生前就被发现和消除。