MongoDB集群中副本集节点状态一直是recovering问题处理

前言

测试环境MongoDB出现部分库无法写入（只能读），但有大部分库又读写正常。

一、排查问题过程

1. mongo命令行登录config，使用rs.status()查看config集群状态情况（无异常）；
2. mongo命令行登录mongos，使用sh.status()查看状态情况（Could not find member to sync from）；
3. mongo命令行登录各个shard，使用rs.status()查看状态情况（其中rs3中一个SECONDARY节点状态是recovering）
4. 重启rs3，同时查看rs3的日志信息，得到提示信息："We are too stale to use candidate as a sync source. Denylisting this sync source because our last fetched timestamp is before their earliest timestamp"。这就提示可能是因为恢复所需要的OPLOG已经被清理，找不到OPLOG导致。

二、解决方案

1.临时更改rs3下数据库的主节点

例如将test库的主节点移动到rs2：db.adminCommand({ movePrimary: "test", to: "rs2" })

使用movePrimary命令前，执行db.adminCommand({ replSetFreeze: 600 })进行冻结复制集选举功能，停止副本集的数据同步（600是只600秒后自行恢复）。

2.清空rs3故障shard节点的data目录后重启shard

删除故障shard节点的data目录重启后，发rs3已经恢复正常，之前的recovering状态消失，所有数据库读写也正常了。

3.使用movePrimary命令将之前临时更改rs的数据库更改回去

考虑到数据库的性能均衡，最后需要将之前更改了主rs的数据库再变更回去，例如：

db.adminCommand({ movePrimary: "test", to: "rs3" })

技术能力有限，欢迎各位技术大佬斧正。