Config数据库损坏必须从健康config server副本集同步修复，不可用repair命令；需确保3节点副本集、清空损坏节点数据目录、以相同参数加入副本集，并校验config库各集合完整性。
Config数据库损坏不能靠db.repairDatabase()或mongod --repair恢复——这些命令对config server无效，且可能破坏分片集群元数据一致性。必须从健康的config server节点同步。
确认config server是否为副本集模式
分片集群的config server必须是3节点副本集（自MongoDB 3.4起强制要求）。如果当前config server是单节点或主从结构，修复前先升级为副本集，否则无法安全同步。
- 连接任意config server节点，执行
rs.status()，检查members数组长度是否≥3、状态是否包含"stateStr" : "PRIMARY"或"SECONDARY" - 若返回
"errmsg" : "not master and slaveOk=false"，说明未启用读取从节点，需先在shell中运行rs.slaveOk() - 若只有1个成员或状态为
"STARTUP2"/"RECOVERING"，说明副本集未正常初始化，不能直接同步
停止损坏节点并清空其data目录
损坏的config server节点不能参与选举或数据同步，必须彻底隔离。直接复用旧数据目录会导致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
以副本集成员身份启动损坏节点
不能用--configsvr单独启动，必须加入现有副本集。启动参数必须与健康节点完全一致（尤其--replSet名称、端口、--bind_ip），否则会创建孤立的副本集。
- 使用和健康config server相同的配置启动：
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 - 在shell中执行
rs.add("10.0.1.100:27019")（注意：IP和端口必须与rs.conf()中其他成员格式一致） - 观察同步状态：
rs.status().members.find(m => m.name.includes("10.0.1.100"))，直到stateStr变为"SECONDARY"且syncingTo指向主节点
验证config数据库完整性
同步完成后，不能只看rs.status()就认为修复完成。config库中的关键集合（如shards、databases、collections）必须逐条校验，因为WiredTiger可能跳过损坏块导致静默丢失。
- 连接到config server主节点，切换数据库：
use config - 检查核心集合文档数是否与其它健康节点一致：
db.shards.countDocuments({})、db.databases.countDocuments({}) - 对每个集合运行验证：
db.shards.validate({full:true})，重点看valid字段是否为true，以及errors数组是否为空 - 若发现
"nInvalidDocuments" : 1，说明该集合仍含损坏文档，此时需从最近一次mongodump备份中手动恢复对应集合（config库不支持mongorestore直接覆盖，需先db.shards.drop()再插入）
config server同步看似自动，但WiredTiger的块级恢复机制不会校验逻辑一致性。最易被忽略的是config.chunks集合——它记录所有分片数据块位置，一旦缺失或错乱，查询会返回空结果或随机报错，而rs.status()却显示一切正常。
