如何搭建 MongoDB 副本集以实现高可用性？

副本集概述 副本集（Replica Set）是一组带有故障转移的 MongoDB 实例组成的集群，由一个主（Primary）服务器和多个从（Secondary）服务器构成。通过Replication，将数据的更新由Primary推送到其他实例上，在一定的延迟之后，每个MongoDB实例维护相同的数据集副本。通过维护冗余的数据库副本，能够实现数据的异地备份，读写分离和自动故障转移。 MongoDB 副本集中没有固定的主节点，在启动后，多个服务节点间将自动选举产生一个主节点。该主节点被称为primary，一个或多个从节点被称为secondaries。primary基本上就是master节点，不同之处在于primary节点在不同时间可能是不同的服务器。如果当前的主节点失效了，副本集中的其余节点将会试图选出一个新的主节点。 节点说明 MongoDB副本集架构通过部署多种节点来达到高可用和读写分离的效果，每个副本集实例包含一个主节点（Primary节点）、一个或多个从节点（Secondary节点）、隐藏节点（Hidden节点）、仲裁节点（Arbiter节点）和可选的一个或多个只读节点（ReadOnly节点）。其中主节点、从节点和隐藏节点合起来统称为“主备节点”。各节点的说明如下： 主节点（Primary节点） 负责执行和响应数据读写请求。每个副本集实例中只能有一个主节点。主节点将其数据集的所有更改记录在其操作日志（即oplog小于50 GB）中。 从节点（Secondary节点） 通过操作日志（oplog）同步主节点的数据，可在主节点故障时通过选举成为新的主节点，保障高可用。 通过从节点的连接地址进行连接时，只能读取数据不能写入数据。 从节点具有高可用保障，即某个从节点故障时，系统会自动将其与隐藏节点切换，若未自动切换，您可以自行切换，从节点的连接地址保持不变。 触发节点的角色切换后，会产生1次30秒内的连接闪断，建议您在业务低峰期操作或确保应用具备重连机制。 隐藏节点（Hidden节点） 通过操作日志（oplog）同步主节点的数据，可在从节点故障时接替该故障节点成为新的从节点，也可在只读节点故障时接替该故障节点成为新的只读节点，保障高可用。 隐藏节点仅用作高可用，对客户端不可见。 隐藏节点不在“主节点的备用列表”中，不会被选举为主节点，但会参与投票选举主节点。 每个副本集实例中只能有一个隐藏节点。 仲裁节点（Arbiter节点） 仲裁节点，只是用来投票，且投票的权重只能为1，不复制数据，也不能提升为primary。 仲裁节点常用于节点数量是偶数的副本集中。 通常将Arbiter部署在业务服务器上，切忌将其部署在Primary节点或Secondary节点服务器上。 只读节点（ReadOnly节点） 通过操作日志（oplog）从延迟最低的主节点或从节点同步数据，应用于有大量读请求的场景，以减轻主节点和从节点的访问压力。两个或以上只读节点可以使用ReadOnly Connection String URI连接实现读请求负载均衡。 只读节点具有高可用保障，即某个只读节点故障时，系统会自动将其与隐藏节点切换，若未自动切换，您可以自行切换，只读节点的连接地址保持不变。 触发节点的角色切换后，会产生1次30秒内的连接闪断，建议您在业务低峰期操作或确保应用具备重连机制。 只读节点具有独立的连接地址，适合独立系统直连访问，与已有主从节点的连接互不干扰。 只读节点不在“主节点的备用列表”中，不会被选举为主节点，也不会参与投票选举主节点。 副本集部署架构 MongoDB 6.x 官方介绍副本节点最少为3台，建议副本集成员为奇数，最多50个副本节点，最多7个节点参与选举。 限制副本节点的数量，主要是因为一个集群中过多的副本节点，增加了复制的成本，反而拖累了集群的整体性能。 太多的副本节点参与选举，也会增加选举的时间。而官方建议奇数的节点，是为了避免脑裂的发生。