主页 / dba / 问题 / 74929
Accepted
Antonios
Asked: 2014-08-27 00:01:39 +0800 CST

延迟复制错误警报和迁移延迟

  • 772

我在 3 分片集群上运行 mongo 2.6.1。

配置为：3 个数据节点和 2 个仲裁器。

一个数据节点被隐藏并延迟3小时（slavedelay）。

我隐藏了节点以便在备份期间启动/停止，3 小时的延迟是为了新部署期间的安全。

我面临的问题是：在周末期间，集群上没有写入操作（这是应用程序的性质）。周一早上开始写入时，监控系统报告延迟数据节点滞后 40 多个小时。

我猜这是因为周末没有记录的oplog，周一有记录时，它需要3个小时才能到达延迟的slave。

请分享您对此事的看法，我的想法在这里正确还是我应该检查不同的方向？

mongodb

1 个回答

  1. Best Answer

    按照我的理解，隐藏的次级将始终落后于 slaveDelay 定义的秒数。在您的情况下，在一天中的任何时刻，隐藏的辅助节点将始终落后于最后一次写入 oplog 的三个小时。如果没有更多的写入活动，那么隐藏的次级将在三个小时内完全赶上。您可以通过连接到每个节点并运行rs.printReplicationInfo()来直接检查 Mongo 中的复制状态

    我使用 2.6.3 使用隐藏的辅助节点配置了一个 3 分片集群，该辅助节点恰好落后 180 秒

    这是两个辅助的配置，最后一个是隐藏的，落后180秒。

    {
        "_id" : 1,
        "host" : "myhost:27001"
},
{
        "_id" : 2,
        "host" : "myhost:27002",
        "priority" : 0,
        "slaveDelay" : 180,
        "hidden" : true
},

    优先级设置为 0 以防止隐藏的辅助节点参与选举。

    开始在分片上插入文档，现在正在使用 db.printReplicationInfo() 查看操作日志。

    MongoDB 关于 db.printReplicationInfo() 的文档

    如果在辅助节点上运行，该方法调用 db.printSlaveReplicationInfo()。参见 db.printSlaveReplicationInfo()

    可见Secondary mongo --port 27001

    shard2:SECONDARY> db.printReplicationInfo()
configured oplog size:   50MB
log length start to end: 592secs (0.16hrs)
oplog first event time:  Tue Aug 26 2014 08:46:45 GMT+0000 (UTC)
oplog last event time:   Tue Aug 26 2014 08:56:37 GMT+0000 (UTC)
now:                     Tue Aug 26 2014 08:58:45 GMT+0000 (UTC)

    隐藏的辅助mongo --port 27002

    shard2:SECONDARY> db.printReplicationInfo()
configured oplog size:   50MB
log length start to end: 722secs (0.2hrs)
oplog first event time:  Tue Aug 26 2014 08:43:46 GMT+0000 (UTC)
oplog last event time:   Tue Aug 26 2014 08:55:48 GMT+0000 (UTC)
now:                     Tue Aug 26 2014 08:58:48 GMT+0000 (UTC)

    180 秒后，隐藏的辅助节点追上mongo --port 27002

    shard2:SECONDARY> db.printReplicationInfo()
configured oplog size:   50MB
log length start to end: 592secs (0.16hrs)
oplog first event time:  Tue Aug 26 2014 08:46:45 GMT+0000 (UTC)
oplog last event time:   Tue Aug 26 2014 08:56:37 GMT+0000 (UTC)
now:                     Tue Aug 26 2014 09:02:18 GMT+0000 (UTC)

    因此，无论您是否正在写入 oplog，辅助节点都将继续跟上 slaveDelay 中定义的 N 秒。如果您的监控工具显示 40 小时，请首先验证您是否正在使用 mongo 的 replicationInfo 命令获取相同的信息。

    db.getReplicationInfo()

    db.printReplicationInfo()

    rs.printReplicationInfo()

    db.printReplicationInfo() 的输出与 rs.printReplicationInfo() 的输出相同

    更新

    http://docs.mongodb.org/manual/core/replica-set-delayed-member/

    关于你关于延迟块迁移的问题

    分片

    在分片集群中，延迟成员在启用平衡器时的实用性有限。因为延迟成员会延迟复制块迁移，所以如果在延迟窗口期间发生任何迁移，则分片集群中延迟成员的状态对于恢复到分片集群的先前状态没有用。

    如果我正确理解您的评论。

    如果secondaryThrottle设置为false，平衡器可以继续迁移块而无需等待延迟的成员。我不确定这是否 100% 准确，但这就是我解释他们关于 secondaryThrottle 和延迟成员的文档的方式。

    • 2

相关问题