Question

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

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

问题：

快照在此上下文中的含义是将复制命令计为快照吗？是否可以使用NTFS在Windows服务器上复制日记MongoDB（2.0+）数据目录？您如何确保在您自己的文件系统和设置上安全？
建立包含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 +锁定，然后在磁盘或卷级别对卷进行快照（例如使用lvm2，hyper-v，btrfs），解锁数据库，然后复制快照数据文件。这样可以最大限度地减少辅助设备的停机时间，并且易于恢复。

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

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

使用mongodump不会存储索引数据索引将被恢复，但重建索引以进行恢复可能需要数小时 - 当每个人都对你大吼大叫时，你需要的最后一件事就是需要数小时且无法加速的操作。
Fsync + lock会阻止编写者并阻止读者因此，最好在（被动）辅助设备上执行此操作，而不是在主设备上执行此操作。
停止辅助将填充oplog ，这就是为什么你应该尽可能缩短锁定时间。在锁定期间不是复制所有数据文件（可能需要数小时），仅执行快照应该只需几秒钟。因此，oplog限制不是问题。
当实际副本正在运行时，一切都“恢复正常”，让您高枕无忧。唯一的区别是备份期间辅助设备的负载较高，这不应成为主要问题。

解决您的问题：

关于副本集中的锁定：保持锁定时间短，并使用被动辅助（不能被选为主），因此编写器队列不能停止。
“如果您的备份系统处于被动状态，则在备份正在进行时，辅助服务器被选为主服务器会怎样？”

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

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

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

1 个答案: