MongoDB 没有主节点且只有一个辅助节点处于活动状态的集群分片

MongoDB Cluster Shard with no primary and only one secondary active

我的 MongoDB 分片集群有 3 个分片,每个分片 运行 在 3 个副本上。总结:

Config Server:
  shardcfg1.server.com:27018
  shardcfg2.server.com:27018
  shardcfg3.server.com:27018
Shard1:
  shard11.server.com:27000 (P)
  shard12.server.com:27000 (S)
  shard13.server.com:27000 (S)
Shard2:
  shard21.server.com:27000 (S)
  shard22.server.com:27000 (STARTUP)
  shard23.server.com:27000 (Unhealthy - invalidReplicaSetConfig: Our replica set configuration is invalid or does not include us)
Shard3:
  shard31.server.com:27000 (S)
  shard32.server.com:27000 (P)
  shard33.server.com:27000 (S)

如果您看到上面的状态,问题出在 SHARD2

辅助 shard21.server.com 可用于获取转储,因此可能不会丢失数据。但是,我不知道如何再次稳定集群?

如何从集群中完全删除 SHARD2?或者我应该如何再次使用相同的服务器重新初始化分片?

我错过的一个小细节后来成为解决方案的关键:集群由 Mongo-MMS 管理!

解法:

所以我有一个辅助服务器,另一个服务器处于 STARTUP 模式,第三个可笑地声明自己不是副本集的一部分!整个集群由 MMS 管理。我确实关闭了所有三台服务器。现在我只是简单地启动了独立模式下可用的辅助数据库来获取整个数据库的备份。

在此期间,我从我的集群中删除了这个分片,因为分片中没有主分片,所以排空卡住了。然而,一件奇怪的事情发生了,这些服务器上的自动化代理被删除了。备份完成后,我重新启动了辅助服务器的 mongod,上面有数据。 不幸的是,终端确实显示了 SECONDARY,但是当我检查 rs.status() 它显示了三台服务器时,我确实记得切断了其中一台流氓服务器。就在那时,让我印象深刻的是,MMS 正在管理这些副本集的配置。

删除流氓服务器后,我很快将强制标志重新配置为 true。所以现在我有两台服务器,一台处于辅助模式,另一台处于启动模式。重新配置后几秒钟!瞧!辅助节点将自己提升为主要节点。

一场漫长的战斗,但很高兴地说从来不需要恢复备份或返工整个碎片!