ConfigServer数据不一致必须通过副本集同步重建损坏节点，禁用db.repairDatabase()和mongod --repair；需确保3节点副本集、清空损坏节点dbpath、参数一致启动并rs.add加入，最后校验哈希与optimeDate一致性。
ConfigServer数据不一致不能靠db.repairDatabase()或mongod --repair修复——这些命令对config server完全无效，强行运行可能破坏分片元数据一致性。必须通过副本集同步机制，从健康节点重建损坏节点。
确认config server是否为3节点副本集
自MongoDB 3.4起，config server强制要求以3节点副本集模式运行。单节点或主从结构无法安全同步，必须先升级。
- 连接任一config server执行
rs.status()，检查members数组长度是否为3，且至少有一个成员的stateStr为"PRIMARY" - 若返回
"errmsg" : "not master and slaveOk=false"，先运行rs.slaveOk()再查状态 - 若存在成员状态为
"STARTUP2"或"RECOVERING"，说明副本集未完成初始化，此时不能开始同步
停止并清空损坏节点的数据目录
损坏节点必须彻底隔离，复用旧dbpath会触发WiredTiger元数据冲突，典型错误如Invalid argument: unable to read config.system.sessions。
- 执行
sudo systemctl stop mongod（或kill -2 $(cat /var/lib/mongodb/mongod.pid)），确认进程已退出：ps aux | grep mongod | grep config无输出 - 备份原目录（强烈建议）：
sudo mv /var/lib/mongodb-config /var/lib/mongodb-config.bak-$(date +%s) - 重建空目录：
sudo mkdir -p /var/lib/mongodb-config && sudo chown mongodb:mongodb /var/lib/mongodb-config
以相同参数启动并加入副本集
启动参数必须与健康节点100%一致，尤其是--replSet名称、端口、--bind_ip；否则会创建孤立副本集，导致rs.add()失败或同步卡在STARTUP2。
- 使用完整参数启动：
mongod --configsvr --replSet configReplSet --port 27019 --dbpath /var/lib/mongodb-config --bind_ip localhost,10.0.1.100 --logpath /var/log/mongodb/config.log --fork - 立即连接：
mongo --host 10.0.1.100:27019 - 执行
rs.add("10.0.1.100:27019")（IP和端口格式需与rs.conf()中其他成员完全一致） - 持续观察：
rs.status().members.find(m => m.name.includes("10.0.1.100"))，直到stateStr变为"SECONDARY"且optimeDate持续更新
校验config库各集合完整性
同步完成后，mongos仍可能报config servers are not in sync，因为dbHash比对的是config库下所有集合的哈希值，而某些集合（如system.sessions）可能因时间戳或内部字段差异导致哈希不等。
- 分别连接三个config server，执行
db.runCommand({dbHash: 1}) - 对比输出中的
collections、databases、shards、chunks字段哈希值，忽略system.sessions和transaction*类集合 - 若关键集合哈希一致但
mongos仍拒绝启动，检查config.version文档的lastMod时间戳是否同步，必要时手动更新version集合中_id: 1文档的lastMod字段为最新时间
最易被忽略的一点：同步完成后，不要直接重启mongos，先确认所有config server的rs.status()中每个成员的health为1、stateStr稳定为"PRIMARY"或"SECONDARY"，且optimeDate与主节点偏差小于5秒——否则mongos会因短暂不一致拒绝加载配置。
