mongodb备份
逻辑备份恢复工具mongoimport和mongoexport 略.可以导出databases或者collection为一个文件( JSON/CSV/TSV).备份策略:一般备份应选择闲时,以免资源严重争用.由于mongodb的数据一般不是非常重要,一般部署多个节点,备份不考虑上传到ftp服务器. 本地会保留一个星期.目前生产环境使用的是 基于时间点的 dump备份../mongodump –host 192.168.22.90 –oplog以下内容讲述备份普通库(没有分片)1. 备份恢复1.1 冷备,copy文件即可;1.2 mongodump备份,加–oplog可以做基于时间点的备份(但没有文档确认是否可以基于时间点恢复?) , 不加oplog参数,数据可能不一致;./mongodump –host 192.168.22.90 –oplog #注意恢复的时候要加参数ongorestore –oplogReplay ,这样会到一个一致性的状态备份单个库./mongodump -d test -o backup./mongorestore -d test88 –drop backup/test/ ##导入test88库(可不存在),drop选项是表示每次导入前先drop表,因为恢复数据都是insert语句,如果已经存在,那么不会覆盖原来的数据,可能与恢复的预期目的不符.mongorestore 恢复的时候,只是insert语句,不会替换已经存在的语句.参考: http://www.mongodb.org/display/DOCS/Import+Export+Tools1.3 使用fsync and Lock 在从库上备份db.fsyncLock()OS备份(LVM等镜像技术做备份)db.fsyncUnlock()1.4 mongodb的灾难恢复参考Journaling ,mongodb为了改进数据持久化功能和灾难恢复性,增加了 write-ahead 日志(journaling)记录功能.类似传统数据库的write-ahead redo logs. 在dbpath/journal/ 目录下,如果干净关闭,会清除这个目录下的所有文件.启用–journal后在实例崩溃后重启,mongodb会自动应用journal目录下的日志记录,如果没有启用–journal,那么异常崩溃后,需要带–repair参数启动.如果从库失去同步,那么重新同步或者用另外的从库恢复会更好点(对比repairt数据库), 不过生产环境如果可以自动修复的话,就让它自动repairt吧.验证数据的完整性 db.users.validate();——————-略 start——-<1.8版本, 如果没有启用jounal日志,则需要repair,如果启用了jounal日志,那么会自动repair—————————————数据文件可能由于电源故障宕机或者实例崩溃损坏,mongodb提供了一个修复选项,–repair修复的原理是:导出所有数据,再导入,所以会验证所有的数据,重建所有的索引,可能丢失微小的数据,因为无效的数据被忽略没有重新导入.修复库只做为最后的解决手段,一般使用从库定时备份,冗余切换.如果非干净关闭的话,再次启动,我们会遇到以下报警,ST_LIB_VERSION=1_41**************old lock file: /home/mongodb/data/db/mongod.lock. probably means unclean shutdownrecommend removing file and running –repairsee: http://dochub.mongodb.org/core/repair for more information*************处理步骤:添加–repair 选项启动,以此选项启动后,修复完毕后,会自动关闭实例.然后我们再去掉参数–repair参数重新启动实例.for example:./mongod –repair &———————–略 end ———————————————修复单个数据库.> use testswitched to db test> db.repairDatabase(){ “ok” : 1 }关于备份Sharded Cluster 略.