1

我的 MongoDB Sharded Cluster 有 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.

  • 没有主要在SHARD2
  • 副本集配置如何标记shard23.server.com为非成员

辅助shard21.server.com可用于获取转储，因此可能不会丢失数据。但是，我对如何再次稳定集群一无所知？

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

4

1 回答 1

1

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

解决方案：

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

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

删除恶意服务器后，我迅速将强制标志重新配置为 true。所以现在我有两台服务器，一台在辅助服务器，另一台在启动模式。重新配置后几秒钟！瞧！二级将自己提升为一级。

一场漫长的战斗，但很高兴地说永远不需要恢复备份或重做整个分片！

于 2019-12-06T18:49:11.667 回答