MongoDb热备份 - 使用fsyncLock复制数据/ db VS replicaset

Question

我读到了不用停机时间进行备份的不同MongoDB设置.哪种策略最好或甚至可以比较？

1. 启用日记功能并简单地复制/data/db目录 - 我不清楚这是否足够 - 在MongoDB主页上它指出你必须"快照它"并且它在SAN和LVM上工作为例.

   问题:

   快照在此上下文中的含义是复制命令计为快照吗？是否可以使用NTFS在Windows服务器上复制日记MongoDB(2.0+)数据目录？您如何确保在您自己的文件系统和设置上安全？

2. 建立具有2个服务器和仲裁器的副本集.然后使用rs.status()和fsyncLock/解锁以确保在备份时只在辅助服务器上读取数据.

   > db.fsyncLock
   function () {
       return db.adminCommand({fsync:1, lock:true});
   }
   > db.fsyncUnlock
   function () {
       return db.getSiblingDB("admin").$cmd.sys.unlock.findOne();
   }
   

   问题:

   如果您在副本集中使用锁,那么似乎可以为整个副本集锁定写入和读取,并且此错误尚未修复？

   如果在备份进行过程中将辅助设备投票为主设备怎么办？备份过程是否会停止,或者副本集是否会停止响应写入请求,直到它被解锁？

   注意事项:

   现在我想要简单的解决方案,只需使用日志文件复制data/ db目录并等待副本集.MongoDB在64位Windows服务器(RackSpace Cloud)上运行.

Answer 1

最好的办法是在辅助设备上执行fsync +锁定,然后在磁盘或卷级别对卷进行快照(例如,使用lvm2,hyper-v,btrfs),解锁数据库,然后复制快照数据文件.这样可以最大限度地减少辅助设备的停机时间,并且易于恢复.

此上下文中的" 快照 "是指某些卷管理器,文件系统和虚拟机监控程序提供的快照功能.从本质上讲,这是块设备的"写时复制"功能:它不是在操作系统需要时覆盖数据,而是将新数据写入别处并保持旧版本和新版本的可读性.快照通常几乎没有时间,但在某些系统上,保留相同文件的许多快照是一个坏主意,因为它可能会大大减慢未来的写入速度.

为什么我认为这是完整备份的最佳策略:

1. 使用mongodump不会存储索引数据索引将被恢复,但重建索引以进行恢复可能需要数小时 - 当每个人都对你大喊大叫时,你需要的最后一件事是需要几个小时而且无法加速的操作.

2. Fsync + lock会阻止编写器并因此阻止读者,因此最好在(被动)辅助设备上执行此操作,而不是在主设备上执行此操作.

3. 暂停辅助将填充oplog,这就是为什么你应该尽可能缩短锁定时间.在锁定期间不是复制所有数据文件(可能需要数小时),仅执行快照应该只需几秒钟.因此,oplog限制不是问题.

4. 当实际副本运行时,一切都"恢复正常",让您高枕无忧.唯一的区别是备份期间辅助设备上的负载较高,这不应成为主要问题.

解决你的问题:

• 关于副本集中的锁:保持锁定时间短,并使用被动辅助(不能被选为主),因此编写器队列不能停止.

• "如果您的备份系统处于被动状态,则在备份正在进行时将辅助服务器作为主服务器进行投票会怎样？"

现在我想要简单的解决方案,只需使用日志文件复制data/db dir并等待副本集.MongoDB在64位Windows服务器(RackSpace Cloud)上运行.

你可以做到这一点.卷快照可能仍然是最好的方法,只给你几秒钟的停机时间.如果您的数据很小,简单mongodump可能更容易,但要确保恢复时间是可接受的(取决于您的索引).