mongodb replicaset 突发事件怎么办

  模拟最差情况

1.假如现在replica set中一共就2个节点，一个是primary member，另外一个是second    

   member
 
  如果primary出现故障，(not reachable/healthy)，这时候，second依旧是seconde，
 
  只能提供读的操作。如果重启primary member，一般情况下是按照最新数据的member作为

  primary，这个时候这个节点依旧可以作为primary member使用。replica set恢复正常。


  如果seconde出现故障，(not reachable/healthy)，这时候，primary member自动降级为

  seconde member，replica set中不存在primary member，无法提供写操作，数据会丢失。

  如果seconde故障时间比较短（oplog相关），重启后，最好指定

  config={_id:'shard1',members:[
                     {_id:1,host:'127.0.0.1:10001'},
                     {_id:0,host:'127.0.0.1:10002',priority:1}]
  }

  10002作为你需要的最新数据为primary member，这个时候，replica set恢复正常。


  如果人为rs.remove()掉seconde member，primary member依旧不变

  如果人为rs.remove()掉primary member，seconde member依旧不变。

 
  如果seconde故障时间比较短（oplog相关）：

  这句话的意思是，replica set master和slave之间的复制，是采取oplog读操作日志

  的方式进行复制数据的。所以短时间这个日志比较小的情况下，启动slave，加上

  --fastsync 启动参数，可以再原来的replication 复制的log基础上快速启动，并syn

  同步最新的master数据，否则，master上的oplog日志上一轮如果结束了，这个时候，

  slave 从master获取oplog的时候，发现和master的数据相差太远，更不上master的更新

  了，这个时候，seconde节点不能正常加入replica set中，需要删除seconde数据，进行

  冷copy master数据，然后再进行同步。

 
 
2.最少replica set中至少有2个member（primary 、seconde），一个Arb member。

  这种情况，Arb member意义不大，最差情况和上边1一样，导致replica set 瘫痪，

  所以，最有意义的配置应该是3个member（1primary、2seconde），一个 Arb member。