Mongodb, 只能定时触发二次复制还是手动触发？
Mongodb, can i trigger secondary replication only at the given time or manually?
我不是 mongodb 专家，所以我现在对服务器设置有点不确定。
我有一个带有 wiredtiger 的实例 运行 mongo3.0.2，同时接受读写操作。它从客户端收集日志，所以写负载是体面的。每天一次，我想处理这些日志并使用聚合框架计算一些指标，要处理的数据集类似于上个月的所有日志，所有计算大约需要 5-6 小时。
我正在考虑拆分写入和读取以避免锁定我的集合（服务器在我读取时继续写入日志，新写入的日志可能与我的查询匹配，但我可以跳过它们，因为我不需要 100% 的准确性).
换句话说，我想设置一个用于读取的辅助设备，其中复制不是连续执行，而是在配置的时间或更好的时间内启动，然后再开始所有读取操作。
我正在从 node.js 进行所有处理，所以我在这里看到的一个选项是导出在某个时期创建的数据，例如 [昨天，今天]，然后导入它以自己读取实例并在之后进行计算导入完成。我一直在寻找副本集和 master/slave 复制作为可能的设置，但我不知道如何配置它以实现所描述的场景。
所以也许我错了，在这里错过了什么？是否还有其他选择可以实现此目的？
出于多种原因，您使用副本集的想法存在缺陷。
首先，副本集总是复制整个 mongod 实例。您不能为单个集合启用它，当然不能只为集合的特定文档启用它。
其次，在开始生成报告之前停用复制并启用它也不是一个好主意。当您启用复制时，新的从站不会立即更新。它需要一段时间才能处理完自上次与 master 联系以来的更改。没有办法知道这需要多长时间（您可以使用 rs.status() 并将辅助 optimeDate 与其 lastHeartbeat 日期进行比较来检查次要落后于主要多远。
但是当您想对按时间跨度选择的文档子集执行数据挖掘时，还有另一种解决方案。
将您要分析的文档转移到新的集合中。您可以使用仅包含 $match 的聚合管道来执行此操作，该 $match 与上个月的文档相匹配，后跟 $out。 out-operator 指定聚合的结果不发送到 application/shell，而是写入一个新的集合（在此之前它会自动清空）。然后，您可以在不锁定实际集合的情况下对新集合执行报告。它还具有您现在操作的集合小得多的优势，因此查询会更快，尤其是那些不能使用索引的查询。此外，您的数据不会在聚合之间发生变化，因此您的报告之间不会因为数据发生变化而出现任何不一致。
当您确定需要第二台服务器来生成报告时，您仍然可以使用复制并在辅助服务器上执行聚合。但是，我真的建议您 build a proper replica-set (consisting of primary, secondary and an arbiter) 并始终保持复制处于活动状态。这不仅可以确保您的数据在生成报告时不会过时，还可以在您的主服务器由于某种原因出现故障时为您提供自动故障转移的重要好处。
我不是 mongodb 专家，所以我现在对服务器设置有点不确定。
我有一个带有 wiredtiger 的实例 运行 mongo3.0.2，同时接受读写操作。它从客户端收集日志，所以写负载是体面的。每天一次，我想处理这些日志并使用聚合框架计算一些指标，要处理的数据集类似于上个月的所有日志，所有计算大约需要 5-6 小时。 我正在考虑拆分写入和读取以避免锁定我的集合（服务器在我读取时继续写入日志，新写入的日志可能与我的查询匹配，但我可以跳过它们，因为我不需要 100% 的准确性).
换句话说，我想设置一个用于读取的辅助设备，其中复制不是连续执行，而是在配置的时间或更好的时间内启动，然后再开始所有读取操作。
我正在从 node.js 进行所有处理，所以我在这里看到的一个选项是导出在某个时期创建的数据，例如 [昨天，今天]，然后导入它以自己读取实例并在之后进行计算导入完成。我一直在寻找副本集和 master/slave 复制作为可能的设置，但我不知道如何配置它以实现所描述的场景。 所以也许我错了，在这里错过了什么？是否还有其他选择可以实现此目的？
出于多种原因，您使用副本集的想法存在缺陷。
首先，副本集总是复制整个 mongod 实例。您不能为单个集合启用它，当然不能只为集合的特定文档启用它。
其次，在开始生成报告之前停用复制并启用它也不是一个好主意。当您启用复制时，新的从站不会立即更新。它需要一段时间才能处理完自上次与 master 联系以来的更改。没有办法知道这需要多长时间（您可以使用 rs.status() 并将辅助 optimeDate 与其 lastHeartbeat 日期进行比较来检查次要落后于主要多远。
但是当您想对按时间跨度选择的文档子集执行数据挖掘时，还有另一种解决方案。
将您要分析的文档转移到新的集合中。您可以使用仅包含 $match 的聚合管道来执行此操作，该 $match 与上个月的文档相匹配，后跟 $out。 out-operator 指定聚合的结果不发送到 application/shell，而是写入一个新的集合（在此之前它会自动清空）。然后，您可以在不锁定实际集合的情况下对新集合执行报告。它还具有您现在操作的集合小得多的优势，因此查询会更快，尤其是那些不能使用索引的查询。此外，您的数据不会在聚合之间发生变化，因此您的报告之间不会因为数据发生变化而出现任何不一致。
当您确定需要第二台服务器来生成报告时，您仍然可以使用复制并在辅助服务器上执行聚合。但是，我真的建议您 build a proper replica-set (consisting of primary, secondary and an arbiter) 并始终保持复制处于活动状态。这不仅可以确保您的数据在生成报告时不会过时，还可以在您的主服务器由于某种原因出现故障时为您提供自动故障转移的重要好处。