mongodb 3.4复制集详解

1关闭数据库，打开三个mongodb数据库数据库实例

rs.printReplicationInfo()

2:原理

主库能够进行读写操作，一个复制集群只能有一个活跃的主库

一般情况下复制可以分为好几种架构，比如：

一主一从，一主多从。上个笔记我们已经来做了这种架构

下面看一下mongodb数据库集群配置的三种节点

主节点：

在复制集中，主节点是唯一能够接收写请求的节点。MongoDB在主节点上进行写操作，并会将这些操作记录到主节点的 oplog中。从节点会将oplog复制到其本机并将这些操作应用到其自己的数据集上。

从节点：

从节点的数据集与主节点中的一致。从节点将主节点上的oplog复制到本机，并异步的将这些操作记录应用在其自己的数据集上。每个复制集可以拥有多个从节点。

投票节点：

投票节点 并不含有 复制集中的数据集副本，且也无法升职为主节点。复制集中可能会有多个投票节点来为 选举出新的主节点进行投票。投票节点的存在使得复制集可以以偶数个节点存在，而无需为复制集再新增节点。

复制集合的异步复制：

（1）初始同步

初始同步会将完整的数据集复制到各个节点上。当一个节点没有数据的适合，就会进行初始同步，比如，当它是新加的节点，或者它的数据已经无法通过复制追上最新的数据了，也会进行初始同步。

一个新节点的话就会进行初始同步：

复制所有的数据库。 mongod会查询所有的表和数据库，然后将所有的数据插入这些表的备份中，同时也会建立_id的索引。

当 mongod 完成了所有的索引的建立，该节点将会变为正常的状态i.e. secondary。

允许通过多线程进行批量写操作来提高并发能力。MongoDB将批操作通过命名空间来分组

3：自动仲裁

当主节点10S内没有和从节点进行通信，从节点就会发起仲裁，将自己提升为主节点

复制集成员每两秒向复制集中其他成员进行心跳检测。如果某个节点在10秒内没有返回，那么它将被标记为不可用

如果复制集中的某个节点不能连接上其他多数节点，那么它将不能升职为主节点。在选举中，多数是指多数 投票 而不是多数节点个数。

选举触发的条件：

一个从节点无法与主节点进行连接。当从节点们无法与主节点进行沟通的时候将会触发选举。

设置权重：

我们可以通过设定 priority来加重某个或者某些特殊的节点在选举中获得选票的优先级。比如，当我们有一个 异地分布式架构的复制集，我们可以通过设置优先级来使只有特定数据中心中的节点能够升职为主节点。

节点的 state 也讲决定其是否能够进行投票。只有在以下状态的节点，才能参与投票： PRIMARY（主节点） , SECONDARY（从节点） , RECOVERING(恢复中) , ARBITER（投票节点） 和 ROLLBACK（回滚）

复制集合的读选项：

在此之前我们要确定一点问题，那就是mongodb数据库的复制是异步的，读取的数据不会是很及时的数据，肯定是会有延迟的，所以来说。我们要选择好是不是要在副本上进行读操作。这是一个很严肃的问题。达成以上共识以后我们才能看下集群的只读的配置：

复制集读选项与单实例的 mongod 连接无关。然而，在复制集中如果我们希望在从节点上执行读操作，我们就需要设定复制集读选项，如 secondary 。

为地理分布式架构的应用提供了本地读。

如果应用程序服务器分布在多个数据中心，那么我们可以考虑使用 异地分布式架构的复制集 并使用非主节点读取或是 nearest 模式的复制集读选项。这让客户端从最近、延时最低的节点上去读取，而不是在主节点上读取。

在故障切换过程中保持可用性。

我们可以使用 primaryPreferred 让应用程序正常情况下在主节点上进行读取，但是在紧急情况下在从上进行读取。这会让应用程序在故障切换后处于只读状态。

Sharding 是个很好的策略来提升性能，因为它将读写请求分散到多组服务器，并因此提高了读写性能。

除了 primary 模式以外的复制集读选项都有可能返回非最新的数据，因为复制过程是异步的， 从节点 上应用操作可能会比主节点有所延后。如果我们不使用 primary 模式，请确保业务允许数据存在可能的不一致。

mongodb数据库复制集群一般有以下几种方式：

复制集读选项模式	详细说明
primary	默认模式，所有的读操作都在复制集的 主节点 进行的。
primaryPreferred	在大多数情况时，读操作在 主节点 上进行，但是如果主节点不可用了，读操作就会转移到 从节点 上执行。
secondary	All operations read from the secondary members of the replica set.
secondaryPreferred	在大多数情况下，读操作都是在 从节点 上进行的，但是当 从节点 不可用了，读操作会转移到 主节点 上进行。
nearest	读操作会在 复制集 中网络延时最小的节点上进行，与节点类型无关。

复制集读选项对通过 mongos 来对 分片集群 进行连接也有效 。当通过 mongos 对 分片 的 复制集 进行连接时，我们也可以使用复制集选项来指定连接对象。

在 mongo shell中，通过游标 readPref() 来指定复制集读选项。

 

标签设置

标签设置可以让我们将

复制集读选项与安全写级别获取标签的方式是不同的。当需要选择从哪个节点进行读操作的时候，复制集读选项会参考的是标签的值。安全写级别在选择节点的时候只考虑标签的值是否为唯一，与标签的具体数值无关。

你可以通过标签来指定如下的复制集读选项：

primaryPreferred

secondary

secondaryPreferred

nearest

标签一般而言只适用于在 从节点 上进行 查询 请求的复制集读选项，而不适用于 primary 模式。当 nearest 模式与标签结合使用的时候，就会匹配最低网络延时的节点。这个节点可能是从节点也可能是主节点。

所有的交互都是基于复制集读选项模式与标签的，且使用了同样的 用户选择逻辑 来将选择分发读请求的节点。

 

 

mongodb数据库的复制集成员：

MongoDB的 复制集 是由一组 mongod 实例所组成的，并提供了数据冗余与高可用性。复制集中的成员有以下几种：

Primary.

主节点接受所有的写操作。

Secondaries.

从节点通过应用主节点传来的数据变动操作来保持其数据集与主节点的一致。从节点也可以通过增加额外的参数配置来对应特殊的需求。例如，从节点可以是 non-voting 或是 priority 0 。

我们也可以为复制集设置一个 投票节点 。投票节点其本身并不包含数据集。但是，一旦当前的主节点不可用时，投票节点就会参与到新的主节点选举的投票中。

一个复制集至少需要这几个成员：一个 主节点 ，一个 从节点 ，和一个 投票节点 。但是在大多数情况下，我们会保持3个拥有数据集的节点：一个 主节点 和两个 从节点 。

主节点：

在主从复制的集群当中，所有的节点都可以接受读操作，不过默认情况下是所有的读写操作都会在主节点进行。

从节点：

从节点是从主节点拉取数据，初始化数据以后，会从主节点的 oplog拉取数据进行同步。一个复制集群可以有多个从节点。看一下下面的结构：

从节点可以接受读选项，而且一个复制集群可以有多个从节点。

对于从节点，我们可以做以下的配置：

将从节点指定为mongodb数据库的一个冷备份，也就是优先级为0的复制成员

阻值应用程序读取，将节点设置为隐藏节点。

将从节点设置为延迟复制的节点，可以用来作为镜像，用来恢复数据。这个时间点可以从复制参数进行配置。

Arbiter节点：

仲裁节点不会包含有主节点的数据集合，而且也不可能会在选举的时候成为主节点

 

下面详细看一下从节点的几个示例：

1：优先级为0的复制集成员

一旦将优先级设置为0，那么该从节点将 不能 升职为 主节点 。 优先级为0 的成员不会 触发 选举 。除此之外该节点与其他从节点没有区别，优先级为0 的从节点拥有与主节点一致的数据集，能接受读请求，同时也能参与投票。通过将从节点的 优先级设置为0 来防止其升职为主节点可以在分布式数据中心的结构中起到很好的作用。

在下述这样的拥有三个成员的复制集中，一个主节点和一个从节点坐落在某一个数据中心中，另一个不能升职为主节点的 优先级为0 的从节点则在另一个数据中心。

从节点参与投票的节点不能超过七个，所以来说。如果节点超过七个就要设置为隐藏节点

2：隐藏节点

对于隐藏节点来说：客户端将不会把读请求分发到隐藏节点上，即使我们设定了 复制集读选项 。这些隐藏节点将不会收到来自应用程序的请求。我们可以将隐藏节点专用于报表节点或是备份节点。 延时节点 也应该是一个隐藏节点。在分片集群中， mongos 将不与隐藏节点进行交流。

隐藏节点必须是优先级为0的节点，而且也不可能会被选举成为主节点，有一点是要特别注意的，那就是隐藏节点虽然不会被选为主节点，但是也是参加投票的。

3：延迟节点

延时节点也将从 复制集 中主节点复制数据，然而延时节点中的数据集将会比复制集中主节点的数据延后。举个例子，现在是09：52，如果延时节点延后了1小时，那么延时节点的数据集中将不会有08：52之后的操作。

由于延时节点的数据集是延时的，因此它可以帮助我们在人为误操作或是其他意外情况下恢复数据。举个例子，当应用升级失败，或是误操作删除了表和数据库时，我们可以通过延时节点进行数据恢复。

可以通过以下方式加入一个延迟节点：

{ "_id" : <num>, "host" : <hostname:port>, "priority" : 0, "slaveDelay" : <seconds>, "hidden" : true }

4：投票节点

投票节点 并不含有 复制集中的数据集副本，且也 无法 升职为主节点。复制集中可能会有多个投票节点来为 选举出新的主节点 进行投票。投票节点的存在使得复制集可以以偶数个节点存在，而无需为复制集再新增节点。

仅仅在复制集成员为偶数个的时候加入投票节点。如果在拥有奇数个复制集成员的复制集中新增了一个投票节点，复制集可能会遇到 选举 僵局。关于如何新增一个投票节点请参考 为复制集添加投票节点 。

投票节点与其他复制集节点的交流仅有：选举过程中的投票，心跳检测和配置数据。这些交互都是不加密的。

如果开启了 authorization ，投票节点通过证书的形式与复制集中其他节点进行认证。MongoDB的身份认证过程是加密的。MongoDB的认证交互是通过密码进行的。

5：复制集Oplog

为了提高复制的效率，复制集中所有节点之间会互相进行心跳检测（通过ping）。每个节点都可以从任何其他节点上获取oplog。

大多数情况下，默认的oplog大小是足够的。举个例子，如果Oplog是大小是可用空间的5%，且可以存储24小时内的操作，那么从节点就可以在停止复制24小时后仍能追赶上主节点，而不需要重新获取全部数据。然而，大多数复制集中的操作没有那么频繁，oplog可以存放远不止上述的时间的操作记录。

在 mongod 建立oplog之前，我们可以通过设置 oplogSizeMB 选项来设定其大小。但是，如果已经初始化过复制集，已经建立了Oplog了，我们需要通过 修改Oplog大小 中的方式来修改其大小。

主节点的话rs.printReplicationInfo()可以查询日志的详细信息。

从节点的话通过db.getReplicationInfo() 和 db.getReplicationInfo 可以获得现在复制集的状态与，也可以知道是否有意外的复制延时。