09-Mongodb异常恢复

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(容器名，该命令不具备通用性)