Mongodb集群环境下的数据备份与恢复

当mongodb在生产环境运行时,我们除了要保障运行稳定(高可用),还要尽最大可能保障数据安全。通常会思考各种可能出现问题的因素,比如: 配置服务器(configdb)数据没了 分片(shard)数据没了 集合被drop了,数据库被drop了 configdb和shard由于在集群环境下,通常会做多个副本,运行在不同的主机上。一方面提高了可用性,另一方面避免了因为某些磁盘损坏导致的数据丢失。 但是如果有人登入db,有意或无意批量删除了不该删除数据;或者十分不巧,同一shard的所有副本都同时坏的找不回数据,这时我们还需要其他措施进行补救。以下是几个常用的方案和思路。 增加延时同步的副本节点 参考官方文档-延时同步的副本节点 延时同步的副本节点在拿到oplog后不会立即执行,而是等待一段时间后才执行。在一定程度上可以避免因为

Mongodb经验小结

本篇使用Mongodb版本为3.2.6。 在mongodb里执行某些操作时,可能因为输出内容太多而难以查看。办法是先输出到文件再打开查看。 oplog保存在local库的oplog.rs表中,它是个capped collection,默认5%的可用磁盘空间。如果设置过小,且在数据更新操作繁忙的时候创建新副本,会导致新副本集变secondary失败,查看日志会看到相关内容。 mongos进程占用的内存在某些情况下可能会持续增长直到触发oom-killer,导致mongod躺枪,见/var/log/messages。 各项配置中建议使用hostname代替ip,方便组件迁移。 查看shard日志中执行时间大于1000毫秒的操作。 如果日志中提示存在大量jumbo块且需要手动切割执行以下命令。如果目标collection有chu