副本集日志
在本页
说明
MongoDB在主节点上应用数据库操作，然后将这些操作记录到主节点的oplog上。然后从节点成员会以异步的方式复制并应用这些操作。所有副本集成员都包含一个oplog的副本，其位于local.oplog.rs 集合中，该集合可以让副本集成员维护数据库的当前状态。
- 对于Unix和Windows系统oplog大小依赖于存储引擎：存储引擎默认oplog大小下限上限In-Memory存储引擎物理内存的5%50MB50GBWiredTiger存储引擎空闲磁盘空间的5%990MB50GB
- 对于64-bit macOS系统默认的oplog大小是192MB物理内存或空闲磁盘空间，具体取决于存储引擎:存储引擎默认oplog大小In-Memory存储引擎192MB物理内存WiredTiger存储引擎192MB空闲磁盘空间
在大多数情况下，默认的oplog大小就足够了。例如，如果一个oplog是空闲磁盘空间的5%，并且可容纳24小时的操作记录，那么从节点从oplog停止复制条目的时间可以长达24小时，并且不会因oplog条目变得太陈旧而无法继续复制。但是，大多数副本集的操作容量要小得多，它们的oplog可以容纳更多的操作。
在
mongod 创建一个oplog前，您可以使用 oplogSizeMB 选项来定义oplog的大小。一旦您第一次启动副本集成员后，可使用 replSetResizeOplog 管理命令去改变oplog的大小。 replSetResizeOplog 命令允许您动态调整oplog大小而无需重新启动 mongod 进程。如果您可以预测您的副本集的工作负载与以下模式之一相似，那么您可能希望创建一个比默认值更大的oplog。相反，如果您的应用程序主要执行读操作，而写操作很少，那么更小的oplog可能就足够了。
以下工作负载可能需要大容量的oplog。
为了保持幂等性，oplog必须将多次更新转换为单个操作。这会使用大量的oplog空间，而不会相应增加数据大小或磁盘使用。
如果删除的数据量与插入的数据量大致相同，则数据库在磁盘使用方面不会显著增长，但操作日志的大小可能相当大。
如果工作负载中很大一部分是不增加文档大小的更新，那么数据库会记录大量操作，但不会更改磁盘上的数据量。
在各种异常情况下，对从节点oplog的更新可能会滞后于预期的性能时间。在从节点上使用
db.getReplicationInfo()命令，以及根据复制状态输出结果来评估复制的当前状态，并确定是否存在任何意外的复制延迟。默认情况下，流控制是启用的。
说明
为了进行流控制，副本集/分片集群必须满足：参数featureCompatibilityVersion (FCV) 设置为4.2，并启用majority读关注。也就是说，如果FCV不是4.2，或者读关注majority被禁用，那么启用流控制将不起作用。
从4.2版本开始（从4.0.6开始也是可行的），副本集的副本成员会记录oplog中应用时间超过慢操作阈值的慢操作条目。这些慢oplog信息被记录在从节点
REPL 组件的文本applied op: took ms中。2018-11-16T12:31:35.886-0500 I REPL [repl writer worker 13] applied op: command { ... }, took 112ms
记录在从节点上的慢操作应用程序有：
- 不受
logLevel/systemLog.verbosity级别的影响（或者systemLog.component.replication.verbosity的级别）；例如，对于oplog条目，从节点仅记录慢oplog条目。增加日志的冗余级别不会导致记录所有的oplog条目。 - 不会被捕获器抓取到，并且不受捕获级别的影响。
更多有关慢操作阈值设置的信息，请参见：
如果你的MongoDB部署使用的是WiredTiger存储引擎，你无法从副本集任何成员中删除
local.oplog.rs 集合。这个限制适用于单成员和多成员的副本集。如果一个节点临时宕机并试图在重启过程中重新应用oplog，那么删除oplog可能会导致副本集中的数据不一致。译者：李正洋
最近更新 1yr ago