MongoDB高可用集群配置的几种方案
时间:2017-02-06 01:08 来源:linux.it.net.cn 作者:IT
高可用集群的解决方案
高可用性即HA（High Availability）指的是通过尽量缩短因日常维护操作（计划）和突发的系统崩溃（非计划）所导致的停机时间，以提高系统和应用的可用性。
计算机系统的高可用在不同的层面上有不同的表现：
（1）网络高可用
由于网络存储的快速发展，网络冗余技术被不断提升，提高IT系统的高可用性的关键应用就是网络高可用性，网络高可用性与网络高可靠性是有区别的，网络高可用性是通过匹配冗余的网络设备实现网络设备的冗余，达到高可用的目的。
比如冗余的交换机，冗余的路由器等
（2）服务器高可用
服务器高可用主要使用的是服务器集群软件或高可用软件来实现。
（3）存储高可用
使用软件或硬件技术实现存储的高度可用性。其主要技术指标是存储切换功能，数据复制功能，数据快照功能等。当一台存储出现故障时，另一台备用的存储可以快速切换，达一存储不停机的目的。
MongoDB的高可用集群配置
高可用集群，即High Availability Cluster，简称HA Cluster。
集群（cluster）就是一组计算机，它们作为一个整体向用户提供一组网络资源。
这些单个的计算机系统 就是集群的节点（node）。
搭建高可用集群需要合理的配置多台计算机之间的角色，数据恢复，一致性等，主要有以下几种方式：
（1）主从方式 （非对称方式）
主机工作，备机处于监控准备状况；当主机宕机时，备机接管主机的一切工作，待主机恢复正常后，按使用者的设定以自动或手动方式将服务切换到主机上运行，数据的一致性通过共享存储系统解决。
（2）双机双工方式（互备互援）
两台主机同时运行各自的服务工作且相互监测情况，当任一台主机宕机时，另一台主机立即接管它的一切工作，保证工作实时，应用服务系统的关键数据存放在共享存储系统中。
（3）集群工作方式（多服务器互备方式）
多台主机一起工作，各自运行一个或几个服务，各为服务定义一个或多个备用主机，当某个主机故障时，运行在其上的服务就可以被其它主机接管。
MongoDB集群配置的实践也遵循了这几个方案，主要有主从结构，副本集方式和Sharding分片方式。
Master-Slave主从结构
主从架构一般用于备份或者做读写分离。一般有一主一从设计和一主多从设计。
由两种角色构成：
（1）主(Master)
可读可写，当数据有修改的时候，会将oplog同步到所有连接的salve上去。
（2）从(Slave)
只读不可写，自动从Master同步数据。
特别的，对于Mongodb来说，并不推荐使用Master-Slave架构，因为Master-Slave其中Master宕机后不能自动恢复，推荐使用Replica Set，后面会有介绍，除非Replica的节点数超过50，才需要使用Master-Slave架构，正常情况是不可能用那么多节点的。
还有一点，Master-Slave不支持链式结构，Slave只能直接连接Master。Redis的Master-Slave支持链式结构，Slave可以连接Slave，成为Slave的Slave。
Relica Set副本集方式
Mongodb的Replica Set即副本集方式主要有两个目的，一个是数据冗余做故障恢复使用，当发生硬件故障或者其它原因造成的宕机时，可以使用副本进行恢复。
另一个是做读写分离，读的请求分流到副本上，减轻主（Primary）的读压力。
1.Primary和Secondary搭建的Replica Set
Replica Set是mongod的实例集合，它们有着同样的数据内容。包含三类角色：
（1）主节点（Primary）
接收所有的写请求，然后把修改同步到所有Secondary。一个Replica Set只能有一个Primary节点，当Primary挂掉后，其他Secondary或者Arbiter节点会重新选举出来一个主节点。默认读请求也是发到Primary节点处理的，需要转发到Secondary需要客户端修改一下连接配置。
（2）副本节点（Secondary）
与主节点保持同样的数据集。当主节点挂掉的时候，参与选主。
（3）仲裁者（Arbiter）
不保有数据，不参与选主，只进行选主投票。使用Arbiter可以减轻数据存储的硬件需求，Arbiter跑起来几乎没什么大的硬件资源需求，但重要的一点是，在生产环境下它和其他数据节点不要部署在同一台机器上。
注意，一个自动failover的Replica Set节点数必须为奇数，目的是选主投票的时候要有一个大多数才能进行选主决策。
（4）选主过程
其中Secondary宕机，不受影响，若Primary宕机，会进行重新选主：
2.使用Arbiter搭建Replica Set
偶数个数据节点，加一个Arbiter构成的Replica Set方式：
Sharding分片技术
当数据量比较大的时候，我们需要把数据分片运行在不同的机器中，以降低CPU、内存和IO的压力，Sharding就是数据库分片技术。
MongoDB分片技术类似MySQL的水平切分和垂直切分，数据库主要由两种方式做Sharding：垂直扩展和横向切分。
垂直扩展的方式就是进行集群扩展，添加更多的CPU，内存，磁盘空间等。
横向切分则是通过数据分片的方式，通过集群统一提供服务：
（1）MongoDB的Sharding架构
（2）MongoDB分片架构中的角色
A.数据分片（Shards）
用来保存数据，保证数据的高可用性和一致性。可以是一个单独的 mongod 实例，也可以是一个副本集。
在生产环境下Shard一般是一个Replica Set，以防止该数据片的单点故障。所有Shard中有一个PrimaryShard，里面包含未进行划分的数据集合：
B.查询路由（Query Routers）
路由就是mongos的实例，客户端直接连接mongos，由mongos把读写请求路由到指定的Shard上去。
一个Sharding集群，可以有一个mongos，也可以有多mongos以减轻客户端请求的压力。
C.配置服务器（Config servers）
保存集群的元数据（metadata），包含各个Shard的路由规则。
参考：
(责任编辑：IT)
高可用集群的解决方案高可用性即HA（High Availability）指的是通过尽量缩短因日常维护操作（计划）和突发的系统崩溃（非计划）所导致的停机时间，以提高系统和应用的可用性。 计算机系统的高可用在不同的层面上有不同的表现： （1）网络高可用 由于网络存储的快速发展，网络冗余技术被不断提升，提高IT系统的高可用性的关键应用就是网络高可用性，网络高可用性与网络高可靠性是有区别的，网络高可用性是通过匹配冗余的网络设备实现网络设备的冗余，达到高可用的目的。 比如冗余的交换机，冗余的路由器等 （2）服务器高可用 服务器高可用主要使用的是服务器集群软件或高可用软件来实现。 （3）存储高可用 使用软件或硬件技术实现存储的高度可用性。其主要技术指标是存储切换功能，数据复制功能，数据快照功能等。当一台存储出现故障时，另一台备用的存储可以快速切换，达一存储不停机的目的。 MongoDB的高可用集群配置高可用集群，即High Availability Cluster，简称HA Cluster。 集群（cluster）就是一组计算机，它们作为一个整体向用户提供一组网络资源。 这些单个的计算机系统 就是集群的节点（node）。 搭建高可用集群需要合理的配置多台计算机之间的角色，数据恢复，一致性等，主要有以下几种方式： （1）主从方式 （非对称方式） 主机工作，备机处于监控准备状况；当主机宕机时，备机接管主机的一切工作，待主机恢复正常后，按使用者的设定以自动或手动方式将服务切换到主机上运行，数据的一致性通过共享存储系统解决。 （2）双机双工方式（互备互援） 两台主机同时运行各自的服务工作且相互监测情况，当任一台主机宕机时，另一台主机立即接管它的一切工作，保证工作实时，应用服务系统的关键数据存放在共享存储系统中。 （3）集群工作方式（多服务器互备方式） 多台主机一起工作，各自运行一个或几个服务，各为服务定义一个或多个备用主机，当某个主机故障时，运行在其上的服务就可以被其它主机接管。 MongoDB集群配置的实践也遵循了这几个方案，主要有主从结构，副本集方式和Sharding分片方式。 Master-Slave主从结构
主从架构一般用于备份或者做读写分离。一般有一主一从设计和一主多从设计。 由两种角色构成： （1）主(Master) 可读可写，当数据有修改的时候，会将oplog同步到所有连接的salve上去。 （2）从(Slave) 只读不可写，自动从Master同步数据。 特别的，对于Mongodb来说，并不推荐使用Master-Slave架构，因为Master-Slave其中Master宕机后不能自动恢复，推荐使用Replica Set，后面会有介绍，除非Replica的节点数超过50，才需要使用Master-Slave架构，正常情况是不可能用那么多节点的。 还有一点，Master-Slave不支持链式结构，Slave只能直接连接Master。Redis的Master-Slave支持链式结构，Slave可以连接Slave，成为Slave的Slave。 Relica Set副本集方式Mongodb的Replica Set即副本集方式主要有两个目的，一个是数据冗余做故障恢复使用，当发生硬件故障或者其它原因造成的宕机时，可以使用副本进行恢复。 另一个是做读写分离，读的请求分流到副本上，减轻主（Primary）的读压力。 1.Primary和Secondary搭建的Replica Set
Replica Set是mongod的实例集合，它们有着同样的数据内容。包含三类角色： （1）主节点（Primary） 接收所有的写请求，然后把修改同步到所有Secondary。一个Replica Set只能有一个Primary节点，当Primary挂掉后，其他Secondary或者Arbiter节点会重新选举出来一个主节点。默认读请求也是发到Primary节点处理的，需要转发到Secondary需要客户端修改一下连接配置。 （2）副本节点（Secondary） 与主节点保持同样的数据集。当主节点挂掉的时候，参与选主。 （3）仲裁者（Arbiter） 不保有数据，不参与选主，只进行选主投票。使用Arbiter可以减轻数据存储的硬件需求，Arbiter跑起来几乎没什么大的硬件资源需求，但重要的一点是，在生产环境下它和其他数据节点不要部署在同一台机器上。 注意，一个自动failover的Replica Set节点数必须为奇数，目的是选主投票的时候要有一个大多数才能进行选主决策。 （4）选主过程 其中Secondary宕机，不受影响，若Primary宕机，会进行重新选主：
2.使用Arbiter搭建Replica Set 偶数个数据节点，加一个Arbiter构成的Replica Set方式：
Sharding分片技术当数据量比较大的时候，我们需要把数据分片运行在不同的机器中，以降低CPU、内存和IO的压力，Sharding就是数据库分片技术。 MongoDB分片技术类似MySQL的水平切分和垂直切分，数据库主要由两种方式做Sharding：垂直扩展和横向切分。 垂直扩展的方式就是进行集群扩展，添加更多的CPU，内存，磁盘空间等。 横向切分则是通过数据分片的方式，通过集群统一提供服务：
（1）MongoDB的Sharding架构
（2）MongoDB分片架构中的角色 A.数据分片（Shards） 用来保存数据，保证数据的高可用性和一致性。可以是一个单独的 mongod 实例，也可以是一个副本集。 在生产环境下Shard一般是一个Replica Set，以防止该数据片的单点故障。所有Shard中有一个PrimaryShard，里面包含未进行划分的数据集合：
B.查询路由（Query Routers） 路由就是mongos的实例，客户端直接连接mongos，由mongos把读写请求路由到指定的Shard上去。 一个Sharding集群，可以有一个mongos，也可以有多mongos以减轻客户端请求的压力。 C.配置服务器（Config servers） 保存集群的元数据（metadata），包含各个Shard的路由规则。 参考： (责任编辑：IT) |