副本集日志
在本页
说明
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