Mongo可能的数据损坏返回副本集
我试图了解一些数据损坏的来源，这些数据损坏大约是在辅助设备返回到副本集的同时发生的。
我们有一个包含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是测试副本集中的主数据时，没有新的数据添加到X
以下是可能相关的一些信息：
所有节点都是运行mongo 3.2.7的mmapv1。
将X从生产副本集中删除之后，它是/etc/hosts生产主/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.xlarge上运行辅助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: ...
这是一个不同的集合，虽然对于被损坏的集合。
链接地址: http://www.djcxy.com/p/61655.html上一篇: Mongo possible data corruption returning secondary to replica set
下一篇: MongoDB replica set with simple password authentication