城的灯

MongoDB磁盘整理

虽然mongodb作为一个款明星级的NoSql数据库,但是它的磁盘回收却让很多人较为头痛。

说明

  1. 下面的方案只适用于replica sets模式的mongodb集群。
  2. 我们线上的mongodb版本为2.0.0,但是也适合于其他的版本。

自动同步方案

依赖于mongodb的同步方案,即不采用fastsync方式。这种方案比较简单,但是只能针对数据量和新增数据量不多的情况。因为如果你的数据量太大而新增数据又太多,可能就会出现同步时间太长,而oplog已经把你还没有同步的日志给覆盖了,从而导致集群数据不一致的情况。具体操作步骤如下:

1
2
3
4
5
6
7
8
9
10
1.首先在primary将需要整理的secondary下线:rs.remove(“172.16.1.153:10000”)。
2.将下线的secondary关闭,并且删除所有数据文件。
3.将配置文件中fastsync=true修改为false,重启该节点。
4.在primary将该节点加入集群,等待数据同步:rs.add({_id:需根据情况设定,host:“172.16.1.153:10000”})。
5.一定要将fastsync修改成true,防止以后重启又全量同步,除非你真的就是这样设计的。
6.等secondary同步完成之后,会自动上线,只需要通过命令观察该节点状态。
7.该节点上线之后,进行数据对比,如果数据没有问题,就对别的secondary节点进行操作。
8.等各个secondary节点全搞定之后,将primary降级,让secondary节点升级为primary 。
9.primary降级成secondary之后,重复1-6步骤。
10.如果你原来的primary上线之后,你还是想让它成为primary,那么就进行升级操作,升级操作跟降级操作一样,只是设置的值不一样而已。

特别说明

  1. 检查数据是否跟主节点一致非常重要,因为如果数据不一致,肯定会造成数据丢失情况。
  2. 降级操作图见下图:

Mou icon


RepairDatabase方案

由于repairDatabase命令,会锁住整个库,并且在2.0.0不能运行在secondary节点,但是在2.6之后就可以在secondary节点运行了。

1
2
3
4
5
6
1. 先将secondary节点下线
2. 将下线的节点通过standalone的模式运行。
3. 然后运行mongod --repair或者mongod --repair --repairpath /opt/vol2/data命令来compacts all collections。
4. 等待紧缩完了之后,再将该节点作为一个secondary添加到集群。
5. 等待通过oplog将数据同步完成之后,进行数据检查。
6. 剩余的步骤可以参考自动同步方案的做法。
1
2
3
1. RepairDatabase和自动同步方案的效率,我没有比较过,并且我在线都使用的是自动同步方案,不是因为第二种方案不好,因为我刚开始就选择了该方案,并且没有出过问题,为了线上数据的安全,因此一直采用此种方案。
2. 2.6之后,是否可以不将secondary下线,直接在线压缩,没有测试过,如果能这样做,那就非常爽。
3. 最后提醒大家,这种一定要经过大量测试,切实可行,再操作,否者数据丢了可以不是小事。