1

我试图了解在将辅助节点返回到副本集的同时发生的一些数据损坏的来源。

我们有一个包含 4 个节点的生产副本集 - 3 个数据承载节点和一个仲裁器。

我从生产副本集中取出了一个次要副本（称为它X），并用它来播种一个新的测试副本集以进行一些性能基准测试。播种新副本集后，我放回X生产副本集。在大约 10 小时内，我们收到了客户的投诉，称他们丢失了大约 2 天的数据。X也停产了2天。所以我们想知道重新引入是否会X导致一些数据反转。

时间安排非常紧密，我们无法找到任何合理的替代理论 - 因此这篇文章。

奇怪的是，只有一些mongo 集合被“还原”。我们的数据库似乎是主数据库和X.

更详细地说，这就是我所做的：

  • 跑了rs.remove(X)
  • 从中删除了所有副本集信息mongod.conf
  • 重新启动X
  • 连接到local数据库并运行db.dropDatabase()以清理生产副本集信息
  • 恢复了副本信息，mongod.conf但使用了新的副本集名称
  • 重新启动X
  • 提出 3 个空 mmapv1 节点和一个仲裁器并将它们连接到X新副本集中
  • 让他们复制大约 48 小时
  • 跑rs.stepDown()和rs.remove(X)
  • 从中删除了所有副本集信息mongod.conf
  • 像上面一样，连接和删除local数据库
  • 恢复了副本信息，mongod.conf但使用生产副本集名称
  • 用于rs.add(X)添加X回生产副本集

澄清一下 -X当它是测试副本集中的主要数据时，没有添加新数据。

以下是一些可能相关的信息：

所有节点都是运行 mongo 3.2.7 的 mmapv1。

X从生产副本集中删除后，生产主副本的条目意外/etc/hosts被删除。它能够直接与其他辅助节点和仲裁器通信，但不能与主节点通信。有很多心跳错误日志。

我发现这些日志似乎表明X's 的数据在重新进入生产副本集时被丢弃：

2017-01-13T10:00:59.497+0000 I REPL     [ReplicationExecutor] syncing from: (other secondary)
2017-01-13T10:00:59.552+0000 I REPL     [rsSync] initial sync drop all databases 
2017-01-13T10:00:59.554+0000 I STORAGE  [rsSync] dropAllDatabasesExceptLocal 3 
2017-01-13T10:00:59.588+0000 I JOURNAL  [rsSync] journalCleanup... 
2017-01-13T10:00:59.588+0000 I JOURNAL  [rsSync] removeJournalFiles

在此之前，开发人员也一直在报告主节点有时在较高负载下无响应的问题。这些是来自 reactivemongo 驱动程序的一些错误：

No primary node is available!
The primary is unavailable, is there a network problem?
not authorized for query on [db]:[collection]

节点在 aws 上：主要运行在 上m3.xlarge，次要运行在 上m3.large，仲裁器在 上m3.medium。

在我们收到客户投诉大约 30 小时后，我们的副本集举行了选举并X成为主要副本。这些是日志：

2017-01-15T16:00:33.332+0000 I REPL     [ReplicationExecutor] Starting an election, since we've seen no PRIMARY in the past 10000ms 
2017-01-15T16:00:33.333+0000 I REPL     [ReplicationExecutor] conducting a dry run election to see if we could be elected 
2017-01-15T16:00:33.347+0000 I REPL     [ReplicationExecutor] dry election run succeeded, running for election 
2017-01-15T16:00:33.370+0000 I REPL     [ReplicationExecutor] election succeeded, assuming primary role in term 2 
2017-01-15T16:00:33.370+0000 I REPL     [ReplicationExecutor] transition to PRIMARY 
2017-01-15T16:00:33.502+0000 I REPL     [rsSync] transition to primary complete; database writes are now permitted

这发生在我意识到/etc/hosts文件被破坏之前X。

在复制一个非常大的集合（2.6 亿个文档）时，我还在日志中发现了很多这样的错误：

2017-01-13T13:01:35.576+0000 E REPL     [repl writer worker 9] update of non-mod failed: { ts: Timestamp 1484301755000|10, t: 1, h: -7625794279778931676, v: 2, op: "u", ns: ...

这是一个不同的集合，但与已损坏的集合不同。

4

0 回答 0