【问题标题】:How can I know when MongoDB recovering will end我怎么知道 MongoDB 恢复何时结束
【发布时间】:2015-07-04 00:59:33
【问题描述】:

根据标题,我有一个具有 1 个主数据库、1 个辅助数据库和 1 个仲裁器的副本集,我在主数据库中恢复了一个大数据库,它是一个比辅助数据库快得多的实例。 现在辅助服务器滞后了很多(小时),并且从几个小时开始就处于恢复状态。 我能做点什么吗?可以知道恢复进度吗?

【问题讨论】:

  • 附带说明:拥有在性能上有巨大差异的副本集成员是一个非常糟糕的主意™。假设使用情况保持不变,将有一个使用点,复制到较慢的成员将开始落后并且没有机会赶上。始终拥有性能大致相同的数据承载副本集成员。最好是有精确的重复。

标签: mongodb recovery replicaset


【解决方案1】:

我先回答你的第二个问题。 “我能知道恢复进度吗?” 是的,您可以连接到副本集主副本并执行rs.status() 命令以查看 RS 中每个成员的状态。请参阅输出的stateStr 字段,该字段将表示状态代码的友好名称。这表明了恢复的进展。

在你的标题中,你问你是否知道它什么时候结束。这要困难得多。没有办法“确切地”知道辅助节点何时完成与另一个成员的同步。

关于“我可以做点什么吗?”;是的,但没有什么能准确回答您想知道复制何时结束的愿望。请参阅rs.status() 输出并专门检查optime 字段并将其与次要成员和与之同步的成员进行比较,在您的情况下是主要成员。这只会提供关于两台服务器相距多远的“一些”洞察力。但是,仅此一项并不十分准确,其他因素可能会影响赶上实际所需的时间。它不会告诉您它将在特定时间完成。

还有;如果在您的用例中您的服务器质量不一样,我也会采纳 Markus Mahlberg 的建议。这个和许多其他因素可能会导致复制延迟,包括磁盘 io 问题、网络延迟(包括跨数据中心因素)。这里没有明确的答案。

【讨论】:

  • 是的,我看到了,感谢您的回答,我以二次关机、删除、删除、重新添加结束,并且在完全重新同步后一切顺利。我认为实例之间资源的巨大差距造成了差异(和问题)
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-08-29
  • 2011-12-01
  • 1970-01-01
相关资源
最近更新 更多