自建 MongoDB 实践：MongoDB 复制集

​期内容：MongoDB 复制集的介绍及搭建,复制集是一组 mongod​ 进程一起维护相同的数据集。复制集提供了冗余及高可用。下面的几幅图是 MongoDB 复制集的工作原理：,,Diagram of default routing of reads and writes to the primary.,,Diagram of a 3 member replica set that consists of a primary and two secondaries.,,Diagram of a replica set that consists of a primary, a secondary, and an arbiter.,主服务器是唯一可以随时写入的节点。从节点处于热待机状态，如果主节点发生故障，从节点可以接管主节点。一旦主节点失败，从节点将会竞选主节点角色。,我们也可以有仲裁节点。仲裁员节点不保存任何数据，其唯一目的是参与选举过程。,我们的复制集集群必须始终有奇数节点（包括仲裁节点）。三、五和七个节点是推荐的数量，所以如果初选（或更多服务器）失败，我们在选举过程中拥有多数选票。,当复制集的其他节点在超过 10 秒（可配置）内没有收到主节点的消息时，符合条件的从节点将开始进行投票选举。第一个选举并赢得多票数的节点将成为新的主节点。所有剩余的服务器现在都将从新的主节点复制，保持其作为从节点的角色，继续从新的主节点同步。,从 MongoDB 3.6 开始，如果客户端驱动程序检测到主操作已关闭，则可以一次重试写操作。复制集最多可以有 50 名节点，但其中最多只能有 7 名节点可以在选举过程中投票。,复制集中的所有服务器都通过心跳与所有其他节点保持定期通信。心跳是一个小包，会定期进行发送，以验证所有节点是否正常运行。,从节点与主节点通信，以从 oplog 获取最新的变更（增、删、改），并将其应用于自己的数据库中。,当主节点不可用时，所有从节点都会丢失心跳。其余节点将等到设置 electionTimeoutMillis 时间（默认时间为 10 秒）后，然后从节点将开始一轮或多轮选举，以选举产生新的主节点。,要从从节点中选择为主节点，它必须具有如下两个属性：,在三个服务器各一票的简单例子中，一旦主节点不可用，其他两台服务器将各有一票（总共三分之二），那么谁拥有最新 oplog 的服务器将被选为主节点。,通过选举完成故障恢复：,MongoDB 复制集的大部分优势，其中一些列出如下：,介绍了复制集的优势，那么有没其他缺憾呢？答案是肯定有的，因为完美是不存在的。,在上述优势的列表中缺少的最值得注意的是写扩展。这是因为，在 MongoDB 中，我们只能有一个主节点，只有这个主节点负责数据的写入。,当我们想扩展写入性能时，我们通常会设计和使用分片集群，这是下一章要分享的话题，敬请期待。,演示环境：,由于我们启用了认证，所以需要为每个节点使用 Keyfile（当然还有其他方式）：,设置合适的权限：,把 keyfile 复制到剩余的两个节点上：,我们使用默认的数据目录：/var/lib/mongo​。确保三台机器的配置一样，只有 bind_ip​ 不一样。配置分别如下（仅以第一台配置为例，其他节点的配置需要按需修改 bindIp 配置参数）：,接下来分别启动三个节点上的服务：,接下来配置 Primary、slave 及 arbiter 节点。客户端连接到 Primary：,配置之前的提示符是 “>​”，进行了复制集的初始化后，提示变成了 rs0:SECONDARY​，这个时候所有的节点都是从节点角色，因为要进行一轮或多轮的投票选举。过了一段时间，有一个节点（mongo01）经过投票选举被选为了主节点，所以它的提示符变成了 rs0:PRIMARY。,查看复制集的状态信息：,我们看一下 members 信息：,通过输出我们可以看到两个从节点 mongo02.tyun.cn:27017​ 及 mongo03.tyun.cn:27017​ 分别从主节点 mongo01.tyun.cn:27017 上进行数据的同步。,至此，我们的复制集已经设置完成。虽然复制集已经创建完成，但是我们的工作才刚刚开始。,默认情况下，所有写入和读取都来自主节点。从节点复制数据，但不用于查询。MongoDB 官方驱动程序支持五个级别的数据读首选项：,通过上述提供的选项，可以很方便地配置读写分离、就近读取等策略，细分控制读取策略。上述的这些选项该怎么用呢？,复制集搭建完成后，该怎么连接使用呢？,连接复制集与连接单个节点是没有什么区别的。,配置完成就可以做数据同步的测试了，在 Primary 上创建数据，然后查看数据，然后登录其他从节点查看数据。操作如下：,我们再次创建一个新的测试表：,这时登录到从节点：,当我们执行命令的时候，报错了。主要是因为设置了从节点不能进行读操作，只需简单设置下即可：,,再次插入一条数据：,,复制集的管理可能比单服务器部署所需的要复杂得多。在本节中，我们将重点关注复制集中一些最常见的管理及维护性的操作。,MongoDB 允许我们为每个节点设置不同的优先级，设置如下：,要在设置集群后更改优先级，我们必须使用 mongo shell 连接到主服务器并获取配置对象：,然后，我们可以将节点优先级属性更改为我们想要的值：,当主节点宕机并再次发生选举时，这些高优先级的节点将会进行选举，也是最有可能赢得选举的节点。,在某些情况下（例如，如果我们有多个数据中心），我们希望一些节点永远无法成为主服务器。,在具有多个数据中心复制的场景中，我们的主数据中心（位于英国）可能有一个主节点和一个从节点，以及一台节点位于俄罗斯。在这种情况下，我们不希望我们位于俄罗斯的服务器成为主节点，因为它会给位于英国的应用程序服务器产生延迟。在这种情况下，我们将设置位于俄罗斯的服务器的优先级为 0。,隐藏的复制集节点通常用于特殊任务。客户端看不到它们，不会显示在 db.isMaster() mongo shell 命令和类似的管理命令中，并且出于所有目的，客户端不会考虑（即读取首选项）。,隐藏节点可以投票支持选举，但永远不会成为主服务器。隐藏的复制集节点只会同步到主服务器，不会被客户端读取数据。因此，它具有与主服务器相同的写入负载（用于复制目的），但本身没有读取负载。,设置隐藏节点的操作如下：,在大多数情况下，我们希望有一个节点在较早的时间点保存我们数据的副本。这有助于从大量人为错误中恢复过来，例如手滑或不在状态而误删数据。,一个延迟复制节点必须要设置的两个配置为：priority = 0​ 及 hidden = true。延迟复制节点可以参加选举，但是对客户端不可见并且不会被选举为主节点。设置如下：,MongoDB 中的复制通常发生在主从节点之间。在某些情况下，我们可能想从另一个从节点复制，而不是从主节点复制。链式复制有助于减轻主节点读负载。设置如下：,当我们有大多数节点不可用并且我们仍然有足够的服务器来启动复制集时，我们可以强制仅对已存在的节点进行重新配置。这是一种临时解决方案和最后的手段。,首先，我们获取复制集的配置：,我们可以使用 printjson(cfg) 打印上面的配置信息。假设现存的集群中还剩余节点 1、2、3 的话：,通过使用 force: true 选项，我们使其重新配置。当然，我们的复制集中至少需要三名幸存的节点才能发挥作用。,关于复制集就介绍到这里，我们在此进行一个小结。建议一开始就使用复制集，因为我们不知道数据的增长如何、及未来会发生什么，算是未雨绸缪吧。建议一个集群至少要有三个节点，而且集群的节点的数量必须为奇数。复制集不仅仅只是数据的同步，我们还可以在从节点上执行读操作，来分摊主节点的压力。,最后生产部署的一些考量：,下一节我们将介绍 MongoDB 的分片集群。分片集群要比复制集复杂一些、所需的维护成本及费用都要高些。​