MongoDB多数据中心部署方案（二）

（草稿）

目录

第二章 维护服务的延续性

在正常工作条件下，一个MongoDB的部署将根据系统的性能和功能目标来运行。不过，不时地某些不可避免的失败或意外动作可能会以不利的方式影响系统。

图1：具有持续可用性的自修复MongoDB复制集

存储设备，网络连接，电源和其他硬件组件失效。通过冗余硬件组件的方法这些风险会被减轻。同样，一个MongoDB提供可配置冗余遍及其软件组件和数据存储。

复制集

MongoDB维护多个数据复制，称为复制集，使用本地复制。用户应该部署复制集以帮助防止数据库宕机。复制集是自动修复的，因为故障迁移和恢复是完全自动的，所以不必在系统发生故障时通过手动干预来恢复。

复制集还通过执行系统维护的方法（也就是说:更新硬件和软件）提供操作灵活性同时保持服务延续性。这是一个重要的功能，因为这些操作在传统系统中能占三分之一的宕机时间。一个复制集由多个数据库副本组成。在任何给定时间，一个成员充当主复制集成员，其他成员充当次复制集成员。如果主复制集遭受中断（例如：电力中断，硬件故障，网络中断），其中一个从复制集自动选举为主复制集，通常在几秒内，客户端连接自动故障迁移到新的主复制集。在一个新的主复制集选举的过程中，从复制集可以继续提供读操作服务。

MongoDB复制集中的集数是可配置的，大量复制集成员在数据库宕机时提供了更高的数据耐久性和防范性。（例如：在多机故障，机架故障，数据中心故障，或网络中断情况下）最多可配置50个成员复制集，通过操作灵活性和广泛的数据分布在多个地理位置。

复制集选举

在主副本集抛出故障事件时，由扩展实现了基于一致性Raft算法协议的选举进程控制。这不仅允许快速迁移实现最大化服务可用性，算法确保评估最合适的从成员被选举至主成员并减少不必迁移的风险（也称为“误报”）。在次复制集成员被升级前，选举算法会验证一些参数，包括：

1.选举Id,时间戳和持久化的日志以识别这些复制集成员已经从主复制集上应用了最新更新。

2.心跳和与大多数其他复制集成员的连接状态。

3.用户定义的优先级分配给复制集成员。例如，如果主数据中心失败时，管理员能将所有的位于次级数据中心的复制集作为候选。

一旦选举进程确定了新的主复制集，所有次成员自动开始复制它。如果原主复制集回归在线状态，选举进程会识别它的状态变化并自动承担次要角色。

以下提供一个最佳实践和指导教程 戳

下一章 扩展MongoDB持续可用性

本文译者：吴锦晟 R&D Director@MFG

原文链接：http://www.jianshu.com/p/633f545362ee

版权归译者所有，转载请注明出处