MongoDb 热备份 - 使用 fsyncLock 复制数据/数据库 VS 副本集

Question

我了解了用于在不停机的情况下进行备份的不同 MongoDB 设置。哪种策略最好，甚至可以进行比较？

1. 启用日志并简单地复制 /data/db 目录 - 我不清楚这是否足够 - 在 MongoDB 主页上它声明你必须“快照它”它适用于 SAN 和 LVM 作为示例。

   问题:

   snapshot 是什么意思，在这种情况下，复制命令是否算作快照？在具有 NTFS 的 Windows 服务器上复制日志记录 MongoDB(2.0+)数据目录是否可以保存？您如何确保在您自己的文件系统和设置上进行操作是安全的？

2. 建立一个包含 2 个服务器和一个仲裁器的副本集。然后使用 rs.status() 和 fsyncLock/unlock 确保备份时数据在辅助服务器上只读。

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

   问题:

   如果您在副本集中使用锁，似乎可以锁定整个副本集的写入和读取，this bug还没修好？

   如果在备份过程中将辅助节点选为主节点会怎样？备份过程会停止还是副本集会停止响应写入请求，直到它被解锁？

   注意事项:

   现在我想要一个简单的解决方案，只需复制带有日志文件的 data/db 目录，然后等待副本集。 MongoDB 在 64 位 Windows 服务器(RackSpace Cloud)上运行。

Answer 1

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

“Snapshotting”在此上下文中指的是某些卷管理器、文件系统和虚拟机管理程序提供的快照功能。本质上，这是 block 设备的“写入时复制”功能:不是在操作系统需要时覆盖数据，而是将新数据写入其他地方并保持旧版本和新版本可读。快照通常几乎不需要时间，但在某些系统上，保留同一文件的许多快照是个坏主意，因为这可能会大大减慢 future 的写入速度。

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

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

2. Fsync + lock 会阻塞写入器并可能阻塞读取器因此，最好在(被动)辅助服务器上执行此操作，而不是在主服务器上。

3. 停止二级节点会填满 oplog，这就是为什么你应该尽可能短的锁定时间。与其在锁定期间复制所有数据文件(可能需要数小时)，不如仅执行快照只需几秒钟。因此，oplog 限制不是问题。

4. 在实际副本运行时，一切都“恢复正常”，让您高枕无忧。唯一的区别是备份期间辅助节点的负载较高，这不是主要问题。

解决您的问题:

• 关于副本集中的锁:保持锁定时间短，并使用被动辅助(不能被选为主)，这样写队列就不会停顿。

• 如果您的备份系统是被动的，则不会发生“如果在备份过程中将辅助节点选为主节点会怎样”

For now I would like the simple solution and simply copy the data/db dir with journal files and wait with the replica set. The MongoDB runs on a 64 bit Windows server (RackSpace Cloud).

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