我正在尝试了解在辅助服务器返回到副本集的同时发生的某些数据损坏的来源。
我们有一个包含4个节点的生产副本集--3个数据承载节点和一个仲裁器。
我从生产副本集中取出了一个辅助（称为X），并使用它来为一些性能基准测试设置一个新的测试副本集。播种新副本集后，我将X放回到生产副本集中。在大约10个小时内，我们收到客户的投诉，称他们已经丢失了大约2天的数据。 X也已停产2天。所以我们想知道重新引入X是否会导致一些数据恢复。
时间紧密排列，我们未能找到任何合理的替代理论 - 因此这篇文章。
奇怪的是只有一些 mongo集合被“还原”了。我们的数据库似乎是主要和X的混合。
更详细地说，这就是我所做的：
rs.remove(X) mongod.conf X local数据库并运行db.dropDatabase()以清除生产副本集信息mongod.conf中恢复了副本信息，但使用了新的副本集名称X X rs.stepDown()和rs.remove(X) mongod.conf local数据库mongod.conf中恢复了副本信息，但使用了生产副本集名称rs.add(X)将X添加回生产副本集澄清一点 - 当X成为测试副本集中的主要数据时，没有新数据添加到其中。
以下是一些可能相关的信息：
所有节点都是mmapv1，运行mongo 3.2.7。
从生产副本集中删除X后，/etc/hosts中生产主数据库的条目被意外删除。它能够直接与其他辅助和仲裁者通信，但不能与主要通信者进行通信。有很多心跳错误日志。
我发现这些日志似乎表明X的数据在重新进入生产副本集时被删除了：
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: ...
这是一个不同的集合，但对于那个被破坏的集合。