如何在使用各种快照技术时测试MongoDB的相对性能

Question

我想设置一个实验来评估Mongo是如何使用各种技术实现快照的。

• R1Soft HotCopy on ext3
• R1Soft HotCopy on xfs
• LVM与ext3
• LVM

它需要绑定磁盘IO，因此我需要确保所有写操作本质上都是同步的，否则我将需要创建一个数据集，该数据集将违反RAM和交换约束，但我相信在每个插入上启用文件系统刷新将确保每个操作在下一个操作之前被刷新。

> db.runCommand({getlasterror:1,j:true})

我还能做些什么来真正实现MongoDB过程的IO特性呢？

• I可以交织读写。

我将测试类似常量插入率之类的内容，并观察进程在以下期间的行为。

没有快照相关的活动或presence.

• When快照正在被获取，并且committed.

• When是由备份脚本读取的。当快照是冗余的，但是是活动的。当快照是decommissioned.

时，是

• 。

我希望确保在活动和硬件保持不变的同时，也会遇到性能的相对基准。

谢谢你的建议。

Answer 1

罗伯，这太棒了。这样做的结果应该对每个人都有益。

在测试MongoDB的生产部署的典型快照操作时，我想指出一些可能有帮助的事情。

快照

正如您已经指出的，在活动服务器上获取快照的主要问题是IO争用。为了避免这种情况，大多数人将部署一个带有3+成员的副本集。

通常，在这种情况下，第二个程序之一要么是fsync，然后在快照期间锁定，要么配置为隐藏成员，要么干脆脱机。这允许在热备份(另一个辅助备份)仍可用于自动故障转移时拍摄快照。

这也确保了另外两件事。首先，快照可以及时完成(生产负载不影响备份时间)；第二，获取快照所需的负载不影响生产读取(在允许从次要文件读取的情况下-- slaveOk)。

备份机制

关于快照策略的上述要点很重要，因为大多数人忽略了一个事实，即次要代码具有与主服务器相同的写负载。

MongoDB不具有多主复制。在给定的时间内，只有一个服务器(在集合/碎片中)处于活动状态，用于写操作(主服务器或主服务器)。

但是，当主程序正在接收写和读时，次要程序会跟踪该主服务器的oplog (一个有上限的集合)。次要程序发出定期请求，以查看是否有更多的数据等待从这个可裁剪的游标中读取。当有，这些oplog条目从主读和写入(是的-这需要一个写锁)到次要。

然后，次要程序将oplog中的新条目应用到它们自己的数据副本中(是的--这需要一个写锁)。

你可能知道所有这些，但是在做这个很棒的研究时要记住这一点。

祝好运!