京公网安备11010502063487号hidden 和 delayed 成员有什么用?客户端看不看得到?delayed 能不能当误删的后悔药?这篇配了一个 P + S + hidden + hidden delayed 的副本集,逐个验证,并发现延迟成员有投票权时的代价。
replSetGetStatus 里的全部成员: 9901=PRIMARY, 9902=SECONDARY, 9903=SECONDARY, 9904=SECONDARY primary 的 hello.hosts(客户端能看到的成员): ['9901', '9902'];hello 里没有的: ['9903', '9904'] 配置里的每个成员: 9901: priority=2.0 votes=1 hidden=False secondaryDelaySecs=0; 9902: priority=1.0 votes=1 hidden=False secondaryDelaySecs=0; 9903: priority=0.0 votes=1 hidden=True secondaryDelaySecs=0; 9904: priority=0.0 votes=1 hidden=True secondaryDelaySecs=8 hidden 成员自己的 hello:hidden = True,secondary = True
hidden 成员不出现在 hello.hosts,驱动看不到它,读偏好永远选不到;它照常复制数据、可直连读,常用于备份和报表。priority 必须为 0,但仍可投票。
100 次 secondary 读的分布: {'9902': 100}(H=9903、D=9904 都没有出现;只有 S=9902)secondary 读偏好下 100 次读全部落在普通 secondary 上。
向 primary 写 {_id: 1}(w:3)后,直连 H 读: True配置 secondaryDelaySecs: 8 后,延迟成员比主节点晚 8 秒应用写入。
_id=2 在 primary 上写入后,普通 secondary S 上 0.00 s 就能读到;延迟成员 D 上 8.1 s 才出现(secondaryDelaySecs = 8)
误 drop 集合后,延迟窗口内延迟成员上的数据还在,读出来写回 primary 即可。
primary 上 drop 了 precious;primary 上还有 0 个文档 S 上 0 个;D 上(延迟窗口内)100 个 从 D 读出 100 个文档,写回 primary:primary 上现在有 100 个(数据救回来了)
延迟成员若有投票权,会参与多数计算:停掉普通 secondary 后 w:majority 要等延迟成员,慢了整整一个延迟时长;延迟成员通常配 votes: 0。
停掉 S 后 w:majority 的 insert 耗时 8.0 s(≈ 延迟 8 s:要等延迟成员 D 应用这次写入)
延迟成员需要比延迟时长更大的 oplog 窗口(这里没有量化)。