[mongodb翻译]分片和故障转移

zj2092

　　一个配置恰当的mongodb 分片集群不会有单点失效。
　　本章节描述了集群服务器中可能出现的故障，及相应的对策。
    1. 某个mongos路由进程故障  
        每一个mongos会运行每一台应用服务器上面，该应用服务器只能通过这个mongos进程和集群进行通信。mongos进程不是固定不变的；相反，他们在启动时从配置服务器那里获取必要的配置信息。
        这意味着任何一台应用服务器故障都不会影响到整个集群，其他的应用服务器可以照常提供服务。恢复也是很简单的，只需要重启一个新的应用服务器和mongos进程。

　　2. 一个shard内的某个mongod服务器故障
　　每一个shard由包含了N个服务器的复制组组成，如果任何复制组内的任何一台服务器故障了，该shard还是允许读和写操作的。更进一步，一台服务器故障不会造成数据丢失，这是因为复制组提供了一个选项在写操作可以在返回前将数据强制将写操作同步到备用节点。这个和Amazon's Dynamo上面设置w为2是类似的。

　　3. 一个sahrd内的所有mongod服务器全部故障
　　如果一个shard的复制组里面的服务器全部故障了，该shard上面的数据将不可访问。此时，发生在其他shard的操作时可以继续工作的。
　　如果将一个shard配置为复制组，其中至少一个节点被放置在其他的数据中心，这样整个shard出现故障的概率是很低的，在最大化冗余中这也是推荐的配置。

　　4. 一个配置服务器故障
　　一个生产环境的配置服务器可能会有3台配置服务器，每一个运行在一个独立的机器上面。写往配置服务器的操作使用了两阶段提交的机制保证原子性和shard集群元数据的复制事务性。
　　任何一台配置服务器发生故障，整个系统的元数据将变为只读。整个系统可以继续提供服务，但是一个shard内的数据块将不会被分裂或者迁移到其他shard。对于大部分的应用，这只会带来少量的问题，因为数据块的元数据很少发生变化。
　　这就是说，在一个合理的时间内将宕机的配置服务器重启是很重要的，这样shards才不会由于缺少数据迁移而变的不能平衡（再说一遍，对于大部分生产场景，这可能不是一件很着急的事）。