【存储中央件】MongoDB最热门NoSql数据库（三）：MongoDB高级进阶（复制集 ...

个人主页：道友老李
欢迎加入社区：道友老李的学习社区
3. MongoDB高级进阶

3.1. MongoDB的复制集

3.1.1. 复制集及原理

MongoDB复制集的重要意义在于实现服务高可用
复制集的现实依赖于两个方面的功能:

• 数据写入时将数据敏捷复制到另一个独立节点上
  
• 在接受写入的节点发生故障时自动推举出一个新的替代节点
  

复制集在实现高可用的同时，另有以下作用:

• 数据分发:将数据从一个区域复制到另一个区域，减少另一个区域的读延迟
  
• 读写分离:不同范例的压力分别在不同的节点上执行
  
• 异地容灾:在数据中央故障时间快速切换到异地
  

一个典型的复制集由3个以上具有投票权的节点构成:

• 一个主节点（PRIMARY)︰接受写入操作和推举时投票
  
• 两个（或多个)从节点(SECONDARY)∶复制主节点上的新数据和推举时投票
  
• 不推荐利用Arbiter（投票节点)
  

数据是怎样复制的

• 当一个修改操作，无论是插入、更新或删除，到达主节点时，它对数据的操作将被记录下来（经过一些须要的转换），这些记录称为oplog。
  
• 从节点通过在主节点上打开一个tailable游标不断获取新进入主节点的oplog，并在自己的数据上回放，以此保持跟主节点的数据一致。不推荐利用Arbiter（投票节点)
  

通过推举完成故障规复

• 具有投票权的节点之间两两互相发送心跳（2s）
  
• 当5次心跳未收到时判断为节点失联
  
• 如果失联的是主节点，从节点会发起推举，选出新的主节点
  
• 如果失联的是从节点则不会产生新的推举
  
• 推举基于 RAFT一致性算法实现，推举乐成的须要条件是大多数投票节点存活
  
• 复制会合最多可以有50个节点，但具有投票权的节点最多7个
  

推举的因素
整个集群必须有大多数节点存活
被推举为主节点的节点必须：

• 能够与多数节点创建毗连
  
• 具有较新的 oplog
  
• 具有较高的优先级（如果有配置）
  

复制集的常见选项
复制集节点有以下常见的选配项：

• 是否具有投票权（v 参数）：有则参与投票
  
• 优先级（priority 参数）：优先级越高的节点越优先成为主节点。优先级为0的节点无法成为主节点
  
• 隐藏（hidden 参数）：复制数据，但对应用不可见。隐藏节点可以具有投票仅，但优先级必须为0
  
• 延迟（slaveDelay 参数）：复制 n 秒之前的数据，保持与主节点的时间差
  

复制集的注意事项
关于硬件：

• 因为正常的复制集节点都有大概成为主节点，它们的职位是一样的，因此硬件配置上必须一致；
  
• 为了保证节点不会同时宕机，各节点利用的硬件必须具有独立性。
  

关于软件：

• 复制集各节点软件版本必须一致，以制止出现不可预知的标题
  

增加节点不会增加系统写性能
3.1.2. 复制集的搭建过程

我们通过在一台机器上运行3个实例来搭建一个最简朴的复制集。
• 怎样启动一个 MongoDB 实例
• 怎样将3个 MongoDB 实例搭建成一个复制集
• 怎样对复制集运行参数做一些常规调解
1、准备
● 安装最新的 MongoDB 版本
● Windows 系统请事先配置好 MongoDB 可执行文件的环境变量
● Linux 和 Mac 系统请配置 PATH 变量
● 确保有 10GB 以上的硬盘空间
2、创建数据目录
MongoDB 启动时将利用一个数据目录存放所有数据文件。我们将为3个复制集节点创建各自的数据目录。
● Linux/MacOS:
mkdir -p /data/db{1,2,3}
● Windows:
md c:\data\db1
md c:\data\db2
md c:\data\db3
3、准备配置文件
复制集的每个mongod进程应该位于不同的服务器。我们现在在一台机器上运行3个进程，因此要
为它们各自配置：
● 不同的端口。示例中将利用28017/28018/28019
不同的数据目录。示例中将利用：
/data/db1或c:\data\db1
/data/db2或c:\data\db2
/data/db3或c:\data\db3
不同日志文件路径。示例中将利用：
/data/db1/mongod.log或c:\data\db1\mongod.log
/data/db2/mongod.log或c:\data\db2\mongod.log
/data/db3/mongod.log或c:\data\db3\mongod.log
Linux/MacOS
/data/db1/mongod.conf

1. systemLog:
2.   destination: file
3.   path: /data/db1/mongod.log # log path
4.   logAppend: true
5. storage:
6.   dbPath: /data/db1 # data directory
7. net:
8.   bindIp: 0.0.0.0
9.   port: 28017 # port
10. replication:
11.   replSetName: rs0
12. processManagement:
13.   fork: true

复制代码

Windows
c:\data\db1\mongod.conf

1. systemLog:
2. destination: file
3. path: c:\data1\mongod.log # 日志文件路径
4. logAppend: true
5. storage:
6. dbPath: c:\data1 # 数据目录
7. net:
8. bindIp: 0.0.0.0
9. port: 28017 # 端口
10. replication:
11. replSetName: rs0

复制代码

4、启动 MongoDB 进程
Linux/Mac:
mongod -f /data/db1/mongod.conf
mongod -f /data/db2/mongod.conf
mongod -f /data/db3/mongod.conf
注意：如果启用了 SELinux，大概制止上述进程启动。简朴起见请关闭 SELinux。
Windows:
mongod -f c:\data1\mongod.conf
mongod -f c:\data2\mongod.conf
mongod -f c:\data3\mongod.conf
因为 Windows 不支持 fork，以上命令须要在3个不同的窗口执行，执行后不可关闭窗口否则
进程将直接结束。
5、配置复制集
方法1

1. # mongo --port 28017
2. > rs.initiate()
3. > rs.add("centosvm:28018")
4. > rs.add("centosvm:28019")

复制代码

注意：此方式hostname 须要能被剖析
方法2

1. # mongo --port 28017
2. > rs.initiate({_id: "rs0",members: [{_id: 0,host: "localhost:28017"}
3.                 ,{_id: 1,host: "localhost:28018"}
4.                 ,{_id: 2,host: "localhost:28019"}]})

复制代码

6、验证
MongoDB 主节点举行写入

1. # mongo localhost:28017
2. > db.test.insert({ a:1 })
3. > db.test.insert({ a:2 });

复制代码

MongoDB 从节点举行读

1. # mongo localhost:28018
2. > rs.slaveOk()
3. > db.test.find()
4. > db.test.find()

复制代码

3.2.复制集的写战略

3.2.1 什么是 writeConcern ？

writeConcern 决定一个写操作落到多少个节点上才算乐成。writeConcern 的取值包括：
• 0：发起写操作，不关心是否乐成；
• 1~n(n为集群最大数据节点数）：写操作须要被复制到指定节点数才算乐成；
• majority：写操作须要被复制到大多数节点上才算乐成。
发起写操作的程序将阻塞到写操作到达指定的节点数为止
默认行为
w: “1”
默认的writeConcern，数据写入到Primary就向客户端发送确认

w: “majority”
大多数节点确认模式

w: “all”
全部节点确认模式

j:true
类似于关系数据库中的事件日志。Journaling能够使MongoDB数据库由于意外故障后快速规复。MongoDB2.4版本后默认开启了Journaling日志功能,mongod实例每次启动时都会检查journal日志文件看是否须要规复。由于提交journal日志会产生写入阻塞,所以它对写入的操作有性能影响,但对于读没有影响。在生产环境中开启Journaling是很有须要的。
journal 则定义怎样才算乐成。取值包括：
• true: 写操作落到 journal 文件中才算乐成；
• false: 写操作到达内存即算作乐成。

3.2.2 writeConcern的意义

对于5个节点的复制集来说，写操作落到多少个节点上才算是安全的？
至少3个节点大概配置majority
3.2.3 writeConcern的实战

在复制集测试writeConcern参数

1. db.test.insert( {count: 1}, {writeConcern: {w: "majority"}})
2. db.test.insert( {count: 1}, {writeConcern: {w: 3 }})
3. db.test.insert( {count: 1}, {writeConcern: {w: 4 }})

复制代码

配置延迟节点，模仿网络延迟（复制延迟）

1. conf=rs.conf()
2. conf.members[2].secondaryDelaySecs = 5   //老版本可能是conf.members[2].slaveDelay = 5
3. conf.members[2].priority = 0
4. rs.reconfig(conf)

复制代码

观察复制延迟下的写入，以及timeout参数

1. db.test.insert( {count: 1}, {writeConcern: {w: 3}})
2. db.test.insert( {count: 1}, {writeConcern: {w: 3, wtimeout:3000 }})

复制代码

注意事项
• 虽然多于半数的 writeConcern 都是安全的，但通常只会设置 majority，因为这是等待写入延迟时间最短的选择；
• 不要设置 writeConcern 等于总节点数，因为一旦有一个节点故障，所有写操作都将失败；
• writeConcern 虽然会增加写操作延迟时间，但并不会显着增加集群压力，因此无论是否等待，写操作最终都会复制到所有节点上。设置 writeConcern 只是让写操作等待复制后再返回而已；
• 应对告急数据应用 {w: “majority”}，平凡数据可以应用 {w: 1} 以确保最佳性能。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。