config server高可用的怀疑(非副本集模式)

SCCC和CRCS的区别

在mongo3.4版本之前，configsvr的高可用有两种方式，一种是SCCC，即非副本集模式，一种是CSRS(副本集模式)。在mongo3.4以后已经不支持SCCC了，就我使用SCCC模式的经验看，SCCC确实太坑。个人认为，CSRS相对SCCC大概有以下优点
1 节点宕机后SCCC模式只读不可写，这时mongos无法负载均衡。而CSRS存在副本集的高可用，宕机一台的情况下不影响config本身的读写，故不影响后台负载均衡。

2 节点宕机，如果数据损坏，这时修复还得去健康的节点mongodump，mongorestore，麻烦死了，而CRCS重建副本集只是一条命令那么简单

3  SCCC的高可用不靠谱，其中一台宕机容易引发mongos连接超时，卡顿，不稳定，也就是下文提到的问题。

SCCC(非副本集模式)大概原理一般就是通过创建3个节点的config server，每个节点数据完全一致，当其中一个节点宕机后，这时config server集群禁止写入，可以读取(可以这么理解，mongos不能再做负载均衡，直到宕机的config server重新启动，但是并不影响业务读写)。不过在实际使用过程中，我发现只要有一台config server宕机，这时mongos连接基本都是超时，能连上的执行各种查询操作也非常卡

复现方法

创建了三个config server，配置成SCCC，另外新建了一个mongos

任意关闭其中一个config server   10.10.5.196，这时登陆mongos卡住

卡了很久终于登陆上了，这时执行sh.status()依然很卡

猜测原因

应该是官方客户端mongo shell的问题，应用代码访问可能问题不大