Mongodb异常恢复
- 服务器断点之后,启动mongodb失败,因为是容器化部署,启动失败之后docker容器一直不断重启。(注意这只是一次经验操作,仅供借鉴)
一、环境信息
- Mongodb分片部署,只有一个分片,包括一个mongos,三个config实例,一个分片,分片由Primary,Secondary,Arbiter组成。异常情况是有一个config实例异常,Primary和Secondary都异常。
实例 | 端口 | 状态 | 备注 |
---|
mongos | 27017 | 正常 | 无 |
config Primary | 20001 | 正常 | 无 |
config Secondary | 20002 | 正常 | 无 |
config Secondary | 20003 | 异常 | 日志提示WiredTiger.wt格式异常 |
Primary | 20011 | 异常 | 日志提示sizeStorer.wt格式异常 |
Secondary | 20012 | 异常 | 日志提示WiredTiger.wt格式异常 |
Arbiter | 20013 | 正常 | 无 |
二、恢复过程
2.1 停止容器
- 先停止Primary,Secondary和config Secondary容器
2.2 修复数据
--port端口保证后面的端口保证是可以用的即可,如果不带的话默认是27017,但是27017已经被mongos占用了,因此需要指定一个可用端口
-dbpath后面跟的是数据存储路径,也就是Primary挂载在宿主机的数据路径
sudo ./mongod --port 30012 --repair -dbpath=/data/mongodb/shard_server11/data/db
- 如果修复正常,会出现类似下面的日志,看到修复成功的日志:


- 修复成功之后,重新启动容器即可。按照上面的步骤依次修复Primary,Secondary和config Secondary。
2.3 修复失败
- 如果修复过程中失败了,会出现类似下面的日志。如果是config Secondary修复失败了,那么就清除config Secondary数据路径下的文件,重新启动config Secondary容器(注意如果只有一个config Secondary故障,那么清除数据之后重启会重新从另外两个实例同步到正确的数据)

- 如果是Primary修复成功但Secondary修复失败了,那么连接Primary实例的端口查询数据是否完整(我在操作过程中发现Primary数据是完整的,但是通过mongos访问就有几个表打不开,而且Secondary修复失败),
那么就删除Secondary数据路径下面的文件,再重新启动Secondary容器,之后就可以通过mongos访问完整的数据了。(之后Secondary会从Primary同步正确的数据)
三、注意事项
- 以上操作步骤是我的操作步骤,仅供参考,有数据丢失的风险。
停止容器:docker stop 容器Id
重启容器:docker-compose -f mongo-docker-compose.yml up -d shard_server11(容器名,该命令不具备通用性)