Mongodb:主数据库宕机一天,发现旧数据不同步,当前数据同步

发布于 01-10 04:54 字数 201 浏览 3 评论 0原文

我有一个 mongodb 副本集,其中一个主副本和两个辅助副本,由于一些操作系统问题,主副本已关闭一天。然后其中一个次要选举为主要。使用次要作为主要并在应用程序中使用。一天后,旧的主设备出现,目前用作辅助设备。似乎该辅助设备中仅更新当前数据,而不同步停机日的数据。有什么方法可以知道它是否在后台同步?如果不同步我该怎么办?我需要将旧的主数据库再次转换为主数据库,只有所有数据同步才能完成。

I have a mongodb replica set with one primary and two secondary, primary were down for one day, due to some os issues. Then one of the secondary elected as primary. Used that secondary as primary and used in application. After one day, old primary turned up and currently it is using as secondary. It seems only current data are updating in this secondary not synching the data of the downtime day. Is there any way to know, it is synching in background? if not synching what i have to do? I need to convert old primary again as primary, it can be done only if all data get synched.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

甜是你2025-01-17 04:54:10

如果您的旧 PRIMARY 变为 SECONDARY,这意味着它成功复制了新 PRIMARY 中丢失的数据...,只有在选举之前旧 PRIMARY 中存在的写入无法复制到新 PRIMARY 时才会出现例外。您可以在旧的 PRIMARY 中的“回滚”文件夹中以 bson 格式找到这些写入,您将需要查看这些 bson 文件并手动检查是否需要重新插入或再次考虑它们。

故障排除步骤如下:

  1. 检查当前副本集状态:

    rs.status()

  2. 如果您有 1x PRIMARY + 2x SECONDARY,则似乎一切都很好,您的成员与 PRIMARY 同步。

  3. 如果某些成员处于不同的状态,他们可能会开始同步,您将需要等待一段时间才能完成该过程,或者出现其他问题,因此您可能需要稍等一下。

  4. 如果由于某种原因成员未成功初始化同步,您可以强制执行新的初始化同步,以便他们从头开始尝试。

以下是启动 init 同步的简单步骤:

4.1。停止成员:

   mongo --p XXX
   use admin
   db.shutdownServer()

4.2。进入数据文件夹并删除其中的所有内容:

   cd /my_member_data_folder/
   rm -rf *

4.3。再次启动成员并等待 initsync 并成功转至 SECONDARY 状态。

   mongod --config my_config_file.conf
  1. 如果一切正常,您只需将副本集切换到旧的 PRIMARY,您可以通过重新配置该成员的优先级来实现,如下所示:

    newPRIMARY>var x=rs.conf()
    newPRIMARY>x.members[0].priority=10
    newPRIMARY>rs.reconfig(x)
    

假设members[0]是旧的 PRIMARY ,而其余成员则为旧的 PRIMARY 。拥有优先权< 10

If your old PRIMARY become SECONDARY this mean it successfully replicated the missed data from your new PRIMARY ... , exception is made only for the writes that exist in your old PRIMARY immediately before the election not able to replicate to your new PRIMARY. Those writes you can locate in your "rollback" folder in your old PRIMARY in bson format , you will need to review those bson files and check manually if you need to re-insert or consider them again.

Troubleshooting steps to follow:

  1. Check the current replicaSet status with:

    rs.status()

  2. If you have 1x PRIMARY + 2x SECONDARY it seems everything to be fine , your members are in sync to the PRIMARY.

  3. If some of the members are in different state they maybe init syncing and you will need to wait for some time until the process finish or there is other problem so you may need to wait abit.

  4. If for some reason the members do not init sync succesfully , you can force fresh init sync so they try from the scratch.

Here are simple steps to start init sync:

4.1. Stop the member:

   mongo --p XXX
   use admin
   db.shutdownServer()

4.2. Go the data folder and remove anything inside:

   cd /my_member_data_folder/
   rm -rf *

4.3. Start the member again and wait until init sync and successfully move to SECONDARY state.

   mongod --config my_config_file.conf
  1. In case everything is fine and you just need to switch the replicaSet to your old PRIMARY you may do so by just re-configure the priority of this member as follow:

    newPRIMARY>var x=rs.conf()
    newPRIMARY>x.members[0].priority=10
    newPRIMARY>rs.reconfig(x)
    

Supposing members[0] is the old PRIMARY , and the rest of member they have the priority < 10

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文