MongoDB 복제본 세트에 관한 몇 가지 문제에 대해 이야기해 보겠습니다.

                                                       

MongoDB Tutorial복제 세트를 사용해야 하는 이유 소개

권장(무료): MongoDB Tutorial

복제 세트를 사용해야 하는 이유

1. 백업하세요. data
자체 함께 제공되는 mongo_dump/mongo_restore 도구로도 백업을 구현할 수 있지만 결국 복제본 세트의 자동 동기화 백업만큼 편리하지는 않습니다. mongo_dump/mongo_restore 工具也可以实现备份，但是毕竟没有复制集的自动同步备份方便。

2.故障自动转移
部署了复制集，当主节点挂了后，集群会自动投票再从节点中选举出一个新的主节点，继续提供服务。而且这一切都是自动完成的，对运维人员和开发人员是透明的。当然，发生故障了还是得人工及时处理，不要过度依赖复制集，万一都挂了，那就连喘息的时间都没有了。

3.在某些特定的场景下提高读性能
默认情况下，读和写都只能在主节点上进行。
下面是MongoDB的客户端支持5种复制集读选项：

• primary：默认模式，所有的读操作都在复制集的 主节点 进行的。
• primaryPreferred：在大多数情况时，读操作在 主节点 上进行，但是如果主节点不可用了，读操作就会转移到 从节点 上执行。
• secondary：所有的读操作都在复制集的 从节点 上执行。
• secondaryPreferred：在大多数情况下，读操作都是在 从节点 上进行的，但是当 从节点 不可用了，读操作会转移到 主节点 上进行。
• nearest：读操作会在 复制集 中网络延时最小的节点上进行，与节点类型无关。

来源：http://docs.mongoing.com/manual-zh/core/re...

不推荐在从节点上进行读操作，因为从节点上的数据可能不是最新数据（主要原因）。
在从节点上进行读操作的场景很有限，官方手册中写明了适用的场景和不推荐从节点读操作的多个原因：http://docs.mongoing.com/manual-zh/core/re...

说说我自己的看法：复制集并不是为了提高读性能而存在的，除了个别场景，不推荐在从节点上进行读操作。如果想提升读性能，那么请使用索引和分片。插一句，如果数据规模不大，就没必要使用分片了。我们线上数据库中单个集合记录有将近 2 亿条，性能还比较 OK（当然，机器配置也不差，而且上面就只跑了一个 Redis 和一个 MongoDB）。

如何部署复制集

请看手册：http://docs.mongoing.com/manual-zh/tutoria...

如何在程序中使用 MongoDB 复制集故障自动转移的特性

以 PHP 的 mongo 驱动为例。

$client = new MongoClient('mongodb://192.168.1.2:27018,192.168.1.3:27019,192.168.1.4:27020', array('replicaSet' => 'rs0'));

这样配置后，如果只是其中一台 MongoDB 服务挂断后，剩余的节点会自动选举出新的主节点，程序还是可以继续正常运行。在选举的过程中，程序还是会抛出异常的，尽管选举过程很快，但是为了程序的健壮性，必须考虑异常的处理。当然，如果选举不出新的主节点，那么整个 MongoDB 就不可用了。（根据上面讲的，如果复制集的读选项是配置的 primaryPreferred。如果没有了主节点，但是从节点还可用的话，那么读操作将转移到从节点上去，这样整个 MongoDB 复制集还能提供读操作服务）

其实如果指定了复制集名 'replicaSet' => 'rs0'，那么就算不列出所有节点地址，仅写一个有效节点地址，mongo 驱动会自动获取到所有有效节点，$client->getHosts() 方法可以查看所有有效节点的地址。

但是如果你只写了一个节点地址，刚好是那个节点挂掉了，那就连不上了。所有我建议配置完整的节点地址列表。

同步的原理是什么

开启复制集后，会在 local 库下生成一个集合叫 oplog.rs

2. 자동 장애 조치🎜복제 세트가 배포됩니다. 마스터 노드에 장애가 발생하면 클러스터는 서비스를 계속 제공하기 위해 노드에서 새 마스터 노드를 선택하도록 자동으로 투표합니다. 그리고 이 모든 작업은 운영 및 개발자에게 자동으로 투명하게 수행됩니다. 물론, 장애가 발생하더라도 적시에 수동으로 처리해야 합니다. 복제본 세트에 너무 많이 의존하지 마십시오. 모두 실패하면 숨을 쉴 시간조차 없습니다. 🎜🎜3. 특정 특정 시나리오에서 읽기 성능 향상🎜기본적으로 읽기 및 쓰기는 모두 마스터 노드에서만 수행될 수 있습니다. 🎜다음은 MongoDB 클라이언트에서 지원하는 5가지 복제본 세트 읽기 옵션입니다. 🎜

• 기본: 기본 모드, 모든 읽기 작업은 복제본 세트의 기본 노드에서 수행됩니다.
• primaryPreferred: 대부분의 경우 읽기 작업은 기본 노드에서 수행되지만 기본 노드를 사용할 수 없는 경우 읽기 작업이 슬레이브 노드로 전송되어 실행됩니다.
• 보조: 모든 읽기 작업은 복제본 세트의 슬레이브 노드에서 수행됩니다.
• SecondaryPreferred: 대부분의 경우 읽기 작업은 슬레이브 노드에서 수행되지만 슬레이브 노드를 사용할 수 없는 경우 읽기 작업이 기본 노드로 이전됩니다.
• nearest: 노드 유형에 관계없이 복제 세트에서 네트워크 지연이 가장 작은 노드에서 읽기 작업이 수행됩니다.

🎜출처: http://docs.mongoing.com/manual-zh/core/re...🎜🎜🎜슬레이브 노드🎜에서는 읽기 작업을 수행하지 않는 것이 좋습니다. 데이터가 최신 데이터가 아닐 수도 있습니다(주된 이유). 🎜슬레이브 노드에서 읽기 작업에 대한 시나리오는 매우 제한적입니다. 공식 매뉴얼에는 적용 가능한 시나리오와 슬레이브 노드에서 읽기 작업이 권장되지 않는 여러 가지 이유가 나와 있습니다. http://docs.mongoing.com/manual-zh/core/re ...🎜🎜 내 의견을 말씀드리자면, 몇 가지 시나리오를 제외하고는 슬레이브 노드에서 읽기 작업을 수행하는 것이 권장되지 않습니다. 읽기 성능을 향상시키려면 인덱스와 샤딩을 사용하세요. 그런데 데이터 크기가 크지 않으면 샤딩을 사용할 필요가 없습니다. 우리 온라인 데이터베이스에는 거의 2억 개의 단일 컬렉션 레코드가 있으며 성능이 비교적 좋습니다(물론 시스템 구성도 나쁘지 않고 Redis와 MongoDB가 하나만 실행되고 있습니다). 🎜🎜🎜복제 세트 배포 방법🎜🎜🎜매뉴얼을 참조하세요: http://docs.mongoing.com/manual-zh/tutoria... 🎜🎜🎜MongoDB 복제본 세트의 자동 장애 조치 기능을 사용하는 방법 프로그램🎜🎜 🎜PHP의 mongo 드라이버를 예로 들어보겠습니다. 🎜

journal = false
smallfiles = true
noprealloc = true

🎜이 구성 후에 MongoDB 서비스 중 하나만 중단되면 나머지 노드는 자동으로 새 마스터 노드를 선택하며 프로그램은 계속해서 정상적으로 실행될 수 있습니다. 선택 프로세스 중에 프로그램은 여전히 ​​예외를 발생시킵니다. 선택 프로세스는 빠르지만 프로그램의 견고성을 위해 예외 처리를 고려해야 합니다. 물론, 새로운 마스터 노드를 선택할 수 없으면 전체 MongoDB를 사용할 수 없게 됩니다. (위의 설명에 따르면, 레플리카 셋의 읽기 옵션이 primaryPreferred로 구성되어 있는 경우. 기본 노드는 없지만 슬레이브 노드가 여전히 사용 가능한 경우 읽기 작업이 다음 노드로 이전됩니다. 슬레이브 노드를 사용하여 MongoDB 전체가 읽기 작업 서비스도 제공할 수 있도록 합니다)🎜🎜실제로 복제본 세트 이름 'replicaSet' => 'rs0'을 지정하면 모든 노드 주소가 나열되지 않고 하나의 유효한 노드 주소만 기록되며 mongo 드라이버는 자동으로 모든 유효한 노드를 얻고 $client->getHosts() 메소드는 모든 유효한 노드의 주소를 볼 수 있습니다. 노드. 🎜🎜그러나 노드 주소를 하나만 썼는데 해당 노드가 다운되면 연결할 수 없습니다. 🎜제가 권장하는 것은 전체 노드 주소 목록을 구성하는 것입니다🎜. 🎜🎜🎜동기화 원리는 무엇인가요? 🎜🎜🎜복제 세트를 열면 local 라이브러리 아래에 oplog.rs라는 세트가 생성됩니다. 한정세트라서 사이즈가 정해져있어요. 데이터베이스에 대한 모든 쓰기 작업은 이 컬렉션에 기록됩니다. 복제 세트의 노드는 다른 노드의 oplog를 읽어 데이터 동기화를 달성합니다. 🎜

举个例子：
用客户端向主节点添加了 100 条记录，那么 oplog 中也会有这 100 条的 insert 记录。从节点通过获取主节点的 oplog，也执行这 100 条 oplog 记录。这样，从节点也就复制了主节点的数据，实现了同步。

需要说明的是：并不是从节点只能获取主节点的 oplog。

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

还有，用一条语句批量删除 50 条记录，并不是在 oplog 中只记录一条数据，而是记录 50 条单条删除的记录。

oplog中的每一条操作，无论是执行一次还是多次执行，对数据集的影响结果是一样的，i.e 每条oplog中的操作都是幂等的。

什么情况下需要重新同步

在上一个问题中得知：oplog 大小是固定的，而且 oplog 里面的记录数不一定和节点中的数据量成正比。那么，新记录肯定会将前面的老记录给覆盖。

如果，有天一个从节点挂了，其他节点还在正常运行，继续有写操作，oplog 继续增长。而这个挂掉的节点一直不能从其他节点那里同步最新的 oplog 记录，当其他节点的 oplog 已经发生的覆盖。即使这个从节点后来恢复了正常，也不会和其他节点保持数据一致了。因为，覆盖的就永远回不来了。

那么，这个时候就得重新同步了。恩，回不去的就永远回不去了，再找个新的重新开始吧。(逃

如何重新同步

参见：复制集成员的重新同步

什么时候应该使用投票节点

当复制集中有偶数个节点时，应该再加一个投票节点，用于打破投票僵局。

比如：我线上共有3台服务器，其中1台是作为 Web 服务器；其余2台作为 DB 服务器，各部署了1个MongoDB节点，构成了2个节点的复制集。这个时候，我并没有多余的机器了。在这个情况下，如果任意一台 DB 服务器上的 MongoDB 挂了，那么另外一台的 MongoDB 必然变为 SECONDARY 节点，那么就意味着 MongoDB 是不可用的了。为了避免这种情况，提高服务的可用性，可以在 Web 服务器上部署一个投票节点。投票节点并不存储数据，因此不能升职为 PRIMARY 节点，它对于硬件资源要求很低，并不会对 Web 服务器上的其他程序产生太大影响。这种情况下，如果任意一台 DB 服务器挂了，另外一台服务器上的 MongoDB 将成为 PRIMARY 节点，此时 MongoDB 还是依旧对外提供服务的。乘此时机，赶紧排查出故障的那台服务器的原因，尽快恢复服务。

为了让投票节点可以占用更少的资源，可以在配置文件中添加以下几个配置项：

journal = false
smallfiles = true
noprealloc = true

主从复制

master-slave 复制架构已经不推荐使用了，建议使用 replica sets 复制集架构。
参见：http://docs.mongoing.com/manual-zh/core/ma...

위 내용은 MongoDB 복제본 세트에 관한 몇 가지 문제에 대해 이야기해 보겠습니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!