时间：2021-07-01 10:21:17 帮助过：12人阅读
转自：https://www.cnblogs.com/nulige/p/7613721.html
一、mongodb主从复制配置
主从复制是MongoDB最常用的复制方式,也是一个简单的数据库同步备份的集群技术,这种方式很灵活.可用于备份,故障恢复,读扩展等.
最基本的设置方式就是建立一个主节点和一个或多个从节点,每个从节点要知道主节点的地址。采用双机备份后主节点挂掉了后从节点可以接替主机继续服务。所以这种模式比单节点的高可用性要好很多。
配置主从复制的注意点
| 1 2 3 |
1）在数据库集群中要明确的知道谁是主服务器,主服务器只有一台.
2）从服务器要知道自己的数据源也就是对应的主服务是谁.
3）--master用来确定主服务器,--slave 和 --source 来控制从服务器
|
可以在mongodb.conf配置文件里指明主从关系，这样启动mongodb的时候只要跟上配置文件就行，就不需要通过--master和--slave来指明主从了。
下面简单记录下Mongodb主从复制的部署过程
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 |
1）机器环境
182.48.115.238 master-node
182.48.115.236 slave-node
两台机器都关闭防火墙和selinux
mongodb的安装参考：http://www.cnblogs.com/kevingrace/p/5752382.html
2）主从配置
.............master－node节点配置.............
[root@master-node ~]# vim /usr/local/mongodb/mongodb.conf
port=27017
bind_ip = 182.48.115.238
dbpath=/usr/local/mongodb/data
logpath=/usr/local/mongodb/log/mongo.log
logappend=true
journal = true
fork = true
master = true //确定自己是主服务器
[root@master-node ~]# nohup /usr/local/mongodb/bin/mongod --config /usr/local/mongodb/mongodb.conf &
[root@master-node ~]# ps -ef|grep mongodb
root 15707 15514 23 16:45 pts/2 00:00:00 /usr/local/mongodb/bin/mongod --config /usr/local/mongodb/mongodb.conf
root 15736 15514 0 16:45 pts/2 00:00:00 grep mongodb
[root@master-node ~]# lsof -i:27017
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
mongod 15707 root 7u IPv4 153114 0t0 TCP 182.48.115.238:27017 (LISTEN)
由于mongodb.conf里绑定了本机的ip地址182.48.115.238，所以连接mongodb的时候必须用这个ip地址，不能使用默认的127.0.0.1，也就是说：
[root@master-node ~]# mongo 182.48.115.238:27017 //这样才能连接mongodb
[root@master-node ~]# mongo 或者 mongodb 127.0.0.1:27017 // 这样不能连接mongodb
.............slave－node节点配置.............
[root@slave-node ~]# vim /usr/local/mongodb/mongodb.conf
port=27017
dbpath=/usr/local/mongodb/data
logpath=/usr/local/mongodb/log/mongo.log
logappend=true
journal = true
fork = true
bind_ip = 182.48.115.236 //确定主数据库端口
source = 182.48.115.238:27017 //确定主数据库端口
slave = true //确定自己是从服务器
[root@slave-node ~]# nohup /usr/local/mongodb/bin/mongod --config /usr/local/mongodb/mongodb.conf &
[root@slave-node ~]# ps -ef|grep mongo
root 26290 26126 8 16:47 pts/0 00:00:00 /usr/local/mongodb/bin/mongod --config /usr/local/mongodb/mongodb.conf
root 26316 26126 0 16:47 pts/0 00:00:00 grep mongo
[root@slave-node ~]# lsof -i:27017
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
mongod 26290 root 7u IPv4 663904 0t0 TCP slave-node1:27017 (LISTEN)
mongod 26290 root 25u IPv4 663917 0t0 TCP slave-node1:51060->slave-node2:27017 (ESTABLISHED)
在slave-node测试连接master-node的mongodb数据库是否正常
[root@slave-node ~]# mongo 182.48.115.236:27017
MongoDB shell version v3.4.4
connecting to: 182.48.115.236:27017
MongoDB server version: 3.4.4
Server has startup warnings:
2017-06-03T16:47:31.200+0800 I STORAGE [initandlisten]
2017-06-03T16:47:31.200+0800
I STORAGE [initandlisten] ** WARNING: Using the XFS filesystem is
strongly recommended with the WiredTiger storage engine
2017-06-03T16:47:31.200+0800 I STORAGE [initandlisten] ** See http://dochub.mongodb.org/core/prodnotes-filesystem
2017-06-03T16:47:32.472+0800 I CONTROL [initandlisten]
2017-06-03T16:47:32.472+0800 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
2017-06-03T16:47:32.472+0800
I CONTROL [initandlisten] ** Read and write access to data
and configuration is unrestricted.
2017-06-03T16:47:32.472+0800 I CONTROL [initandlisten] ** WARNING: You are running this process as the root user, which is not recommended.
2017-06-03T16:47:32.472+0800 I CONTROL [initandlisten]
2017-06-03T16:47:32.473+0800 I CONTROL [initandlisten]
2017-06-03T16:47:32.473+0800 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/enabled is ‘always‘.
2017-06-03T16:47:32.473+0800 I CONTROL [initandlisten] ** We suggest setting it to ‘never‘
2017-06-03T16:47:32.473+0800 I CONTROL [initandlisten]
2017-06-03T16:47:32.473+0800 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is ‘always‘.
2017-06-03T16:47:32.473+0800 I CONTROL [initandlisten] ** We suggest setting it to ‘never‘
2017-06-03T16:47:32.473+0800 I CONTROL [initandlisten]
>
3）主从数据同步测试
在master-node节点数据库里创建master_slave库，并插入20条数据
[root@master-node ~]# mongo 182.48.115.238:27017
MongoDB shell version v3.4.4
connecting to: 182.48.115.238:27017
MongoDB server version: 3.4.4
Server has startup warnings:
2017-06-03T16:45:07.406+0800 I STORAGE [initandlisten]
2017-06-03T16:45:07.407+0800
I STORAGE [initandlisten] ** WARNING: Using the XFS filesystem is
strongly recommended with the WiredTiger storage engine
2017-06-03T16:45:07.407+0800 I STORAGE [initandlisten] ** See http://dochub.mongodb.org/core/prodnotes-filesystem
2017-06-03T16:45:08.373+0800 I CONTROL [initandlisten]
2017-06-03T16:45:08.373+0800 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
2017-06-03T16:45:08.373+0800
I CONTROL [initandlisten] ** Read and write access to data
and configuration is unrestricted.
2017-06-03T16:45:08.373+0800 I CONTROL [initandlisten] ** WARNING: You are running this process as the root user, which is not recommended.
2017-06-03T16:45:08.373+0800 I CONTROL [initandlisten]
2017-06-03T16:45:08.374+0800 I CONTROL [initandlisten]
2017-06-03T16:45:08.374+0800 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/enabled is ‘always‘.
2017-06-03T16:45:08.374+0800 I CONTROL [initandlisten] ** We suggest setting it to ‘never‘
2017-06-03T16:45:08.374+0800 I CONTROL [initandlisten]
2017-06-03T16:45:08.374+0800 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is ‘always‘.
2017-06-03T16:45:08.374+0800 I CONTROL [initandlisten] ** We suggest setting it to ‘never‘
2017-06-03T16:45:08.374+0800 I CONTROL [initandlisten]
> use master_slave
switched to db master_slave
> function add(){var i = 0;for(;i<20;i++){db.persons.insert({"name":"wang"+i})}}
> add()
> db.persons.find()
{ "_id" : ObjectId("593278699a9e2e9f37ac4dbb"), "name" : "wang0" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dbc"), "name" : "wang1" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dbd"), "name" : "wang2" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dbe"), "name" : "wang3" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dbf"), "name" : "wang4" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dc0"), "name" : "wang5" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dc1"), "name" : "wang6" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dc2"), "name" : "wang7" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dc3"), "name" : "wang8" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dc4"), "name" : "wang9" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dc5"), "name" : "wang10" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dc6"), "name" : "wang11" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dc7"), "name" : "wang12" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dc8"), "name" : "wang13" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dc9"), "name" : "wang14" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dca"), "name" : "wang15" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dcb"), "name" : "wang16" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dcc"), "name" : "wang17" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dcd"), "name" : "wang18" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dce"), "name" : "wang19" }
Type "it" for more
然后在slave-node节点数据库里查看，是否将master-node写入的新数据同步过来了
[root@slave-node log]# mongo 182.48.115.236:27017
MongoDB shell version v3.4.4
connecting to: 182.48.115.236:27017
MongoDB server version: 3.4.4
Server has startup warnings:
2017-06-03T16:56:28.928+0800 I STORAGE [initandlisten]
2017-06-03T16:56:28.928+0800
I STORAGE [initandlisten] ** WARNING: Using the XFS filesystem is
strongly recommended with the WiredTiger storage engine
2017-06-03T16:56:28.928+0800 I STORAGE [initandlisten] ** See http://dochub.mongodb.org/core/prodnotes-filesystem
2017-06-03T16:56:29.883+0800 I CONTROL [initandlisten]
2017-06-03T16:56:29.883+0800 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
2017-06-03T16:56:29.883+0800
I CONTROL [initandlisten] ** Read and write access to data
and configuration is unrestricted.
2017-06-03T16:56:29.883+0800 I CONTROL [initandlisten] ** WARNING: You are running this process as the root user, which is not recommended.
2017-06-03T16:56:29.883+0800 I CONTROL [initandlisten]
2017-06-03T16:56:29.884+0800 I CONTROL [initandlisten]
2017-06-03T16:56:29.884+0800 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/enabled is ‘always‘.
2017-06-03T16:56:29.884+0800 I CONTROL [initandlisten] ** We suggest setting it to ‘never‘
2017-06-03T16:56:29.884+0800 I CONTROL [initandlisten]
2017-06-03T16:56:29.884+0800 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is ‘always‘.
2017-06-03T16:56:29.884+0800 I CONTROL [initandlisten] ** We suggest setting it to ‘never‘
2017-06-03T16:56:29.884+0800 I CONTROL [initandlisten]
> show dbs
2017-06-03T17:10:32.136+0800 E QUERY [thread1] Error: listDatabases failed:{
"ok" : 0,
"errmsg" : "not master and slaveOk=false",
"code" : 13435,
"codeName" : "NotMasterNoSlaveOk"
} :
_getErrorWithCode@src/mongo/shell/utils.js:25:13
Mongo.prototype.getDBs@src/mongo/shell/mongo.js:62:1
shellHelper.show@src/mongo/shell/utils.js:769:19
shellHelper@src/mongo/shell/utils.js:659:15
@(shellhelp2):1:1
> rs.slaveOk();
> show dbs
admin 0.000GB
local 0.000GB
master_slave 0.000GB
wangshibo 0.000GB
> use master_slave
switched to db master_slave
> db.persons.find()
{ "_id" : ObjectId("593278699a9e2e9f37ac4dbb"), "name" : "wang0" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dbc"), "name" : "wang1" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dbd"), "name" : "wang2" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dbe"), "name" : "wang3" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dbf"), "name" : "wang4" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dc0"), "name" : "wang5" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dc1"), "name" : "wang6" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dc2"), "name" : "wang7" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dc3"), "name" : "wang8" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dc4"), "name" : "wang9" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dc5"), "name" : "wang10" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dc6"), "name" : "wang11" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dc7"), "name" : "wang12" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dc8"), "name" : "wang13" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dc9"), "name" : "wang14" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dca"), "name" : "wang15" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dcb"), "name" : "wang16" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dcc"), "name" : "wang17" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dcd"), "name" : "wang18" }
{ "_id" : ObjectId("593278699a9e2e9f37ac4dce"), "name" : "wang19" }
Type "it" for more
........................................................................................
如果在slave-node节点上的数据库中查看，有报错："errmsg" : "not master and slaveOk=false"！！！
首先这是正常的，因为SECONDARY是不允许读写的， 在写多读少的应用中，使用Replica Sets来实现读写分离。
通过在连接时指定或者在主库指定slaveOk，由Secondary来分担读的压力，Primary只承担写操作。
对于replica set 中的secondary 节点默认是不可读的。
解决办法：
在slave-node节点数据库中执行"rs.slaveOk();"命令即可
........................................................................................
在slave-node节点数据库中发现已经同步过来了master_slave库的20条数据，说明mongodb的主从复制环境已经成功了！当配置完主从服务器后，一但主服务器上的数据发生变化，从服务器也会发生变化
|
主从复制的原理
| 1 2 3 4 5 6 7 8 9 |
在主从结构中，主节点的操作记录成为oplog（operation log）。oplog存储在一个系统数据库local的集合oplog.$main中，这个集合的每个文档都代表主节点上执行的一个操作。
从服务器会定期从主服务器中获取oplog记录，然后在本机上执行！对于存储oplog的集合，MongoDB采用的是固定集合，也就是说随着操作过多，新的操作会覆盖旧的操作！
主从复制的其他设置项
--only 从节点指定复制某个数据库,默认是复制全部数据库
--slavedelay 从节点设置主数据库同步数据的延迟(单位是秒)
--fastsync 从节点以主数据库的节点快照为节点启动从数据库
--autoresync 从节点如果不同步则从新同步数据库(即选择当通过热添加了一台从服务器之后，从服务器选择是否更新主服务器之间的数据)
--oplogSize 主节点设置oplog的大小(主节点操作记录存储到local的oplog中)
|
在上面slave-node从节点的local数据库中，存在一个集合sources。这个集合就保存了这个服务器的主服务器是谁
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
[root@slave-node mongodb]# mongo 182.48.115.236:27017
......
> show dbs
admin 0.000GB
local 0.000GB
master_slave 0.000GB
wangshibo 0.000GB
> use local
switched to db local
> show collections
me
sources
startup_log
> db.sources.find()
{ "_id" : ObjectId("593277a5105051e5648605a3"), "host" : "182.48.115.238:27017", "source" : "main", "syncedTo" : Timestamp(1496481652, 1) }
>
|
二、Mongodb副本集（Replica Sets） （可以参考：搭建高可用mongodb集群）
mongodb 不推荐主从复制,推荐建立副本集(Replica
Set)来保证1个服务挂了,可以有其他服务顶上,程序正常运行,几个服务的数据都是一样的,后台自动同步。主从复制其实就是一个单副本的应用，没有很好的扩展性饿容错性。然而副本集具有多个副本保证了容错性，就算一个副本挂掉了还有很多个副本存在，并且解决了"主节点挂掉后，整个集群内会自动切换"的问题。副本集比传统的Master-Slave主从复制有改进的地方就是它可以进行故障的自动转移,如果我们停掉复制集中的一个成员,那么剩余成员会再自动选举一个成员,作为主库。
Replica
Set 使用的是 n 个 mongod
节点,构建具备自动的容错功能(auto-failover),自动恢复的(auto-recovery)的高可用方案。使用 Replica Set
来实现读写分离。通过在连接时指定或者在主库指定 slaveOk,由Secondary 来分担读的压力,Primary 只承担写操作。对于
Replica Set 中的 secondary 节点默认是不可读的。
1）关于副本集的概念
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
副本集是一种在多台机器同步数据的进程，副本集体提供了数据冗余，扩展了数据可用性。在多台服务器保存数据可以避免因为一台服务器导致的数据丢失。
也可以从硬件故障或服务中断解脱出来，利用额外的数据副本，可以从一台机器致力于灾难恢复或者备份。
在一些场景，可以使用副本集来扩展读性能，客户端有能力发送读写操作给不同的服务器。也可以在不同的数据中心获取不同的副本来扩展分布式应用的能力。
mongodb副本集是一组拥有相同数据的mongodb实例，主mongodb接受所有的写操作，所有的其他实例可以接受主实例的操作以保持数据同步。
主实例接受客户的写操作，副本集只能有一个主实例，因为为了维持数据一致性，只有一个实例可写，主实例的日志保存在oplog。
Client Application Driver
Writes Reads
| |
Primary
|Replication|Replication
Secondary Secondary
二级节点复制主节点的oplog然后在自己的数据副本上执行操作，二级节点是主节点数据的反射，如果主节点不可用，会选举一个新的主节点。
默认读操作是在主节点进行的，但是可以指定读取首选项参数来指定读操作到副本节点。
可以添加一个额外的仲裁节点（不拥有被选举权），使副本集节点保持奇数，确保可以选举出票数不同的直接点。仲裁者并不需要专用的硬件设备。
仲裁者节点一直会保存仲裁者身份
........异步复制........
副本节点同步直接点操作是异步的，然而会导致副本集无法返回最新的数据给客户端程序。
........自动故障转移........
如果主节点10s以上与其他节点失去通信，其他节点将会选举新的节点作为主节点。
拥有大多数选票的副节点会被选举为主节点。
副本集提供了一些选项给应用程序，可以做一个成员位于不同数据中心的副本集。
也可以指定成员不同的优先级来控制选举。
|
2）副本集的结构及原理
MongoDB 的副本集不同于以往的主从模式。
在集群Master故障的时候,副本集可以自动投票,选举出新的Master,并引导其余的Slave服务器连接新的Master,而这个过程对于应用是透明的。可以说MongoDB的副本集
是自带故障转移功能的主从复制。
相对于传统主从模式的优势
传统的主从模式,需要手工指定集群中的 Master。如果 Master 发生故障,一般都是人工介入,指定新的 Master。 这个过程对于应用一般不是透明的,往往伴随着应用重
新修改配置文件,重启应用服务器等。而
MongoDB 副本集,集群中的任何节点都可能成为 Master 节点。一旦 Master 节点故障,则会在其余节点中选举出一个新的
Master 节点。 并引导剩余节点连接到新的 Master 节点。这个过程对于应用是透明的。
一个副本集即为服务于同一数据集的多个 MongoDB 实例,其中一个为主节点,其余的都为从节点。主节
点上能够完成读写操作,从节点仅能用于读操作。主节点需要记录所有改变数据库状态的操作,这些记录 保存在 oplog 中,这个文件存储在 local
数据库,各个从节点通过此 oplog 来复制数据并应用于本地,保持 本地的数据与主节点的一致。oplog
具有幂等性,即无论执行几次其结果一致,这个比 mysql 的二进制日 志更好用。
集群中的各节点还会通过传递心跳信息来检测各自的健康状况。当主节点故障时,多个从节点会触发一次 新的选举操作,并选举其中的一个成为新的主节点(通常谁的优先级更高,谁就是新的主节点),心跳信 息默认每 2 秒传递一次。
客户端连接到副本集后，不关心具体哪一台机器是否挂掉。主服务器负责整个副本集的读写，副本集定期同步数据备份。一旦主节点挂掉，副本节点就会选举一个新的主服务器。这一切对于应用服务器不需要关心。
| 1 2 3 4 5 6 7 8 9 10 |
心跳检测：
整个集群需要保持一定的通信才能知道哪些节点活着哪些节点挂掉。mongodb节点会向副本集中的其他节点每两秒就会发送一次pings包，如果其他节点在10秒钟
之内没有返回就标示为不能访问。每个节点内部都会维护一个状态映射表，表明当前每个节点是什么角色、日志时间戳等关键信息。如果是主节点，除了维护映射表
外还需要检查自己能否和集群中内大部分节点通讯，如果不能则把自己降级为secondary只读节点。
数据同步
副本集同步分为初始化同步和keep复制。初始化同步指全量从主节点同步数据，如果主节点数据量比较大同步时间会比较长。而keep复制指初始化同步过后，节点
之间的实时同步一般是增量同步。初始化同步不只是在第一次才会被处罚，有以下两种情况会触发：
1）secondary第一次加入，这个是肯定的。
2）secondary落后的数据量超过了oplog的大小，这样也会被全量复制。
|
副本集中的副本节点在主节点挂掉后通过心跳机制检测到后，就会在集群内发起主节点的选举机制，自动选举出一位新的主服务器。
副本集包括三种节点:主节点、从节点、仲裁节点。
| 1 2 3 4 5 6 |
1）主节点负责处理客户端请求,读、写数据, 记录在其上所有操作的 oplog;
2）从节点定期轮询主节点获取这些操作,然后对自己的数据副本执行这些操作,从而保证从节点的数据与主节点一致。默认情况下,从节点不支持外部读取,但可以设置;
副本集的机制在于主节点出现故障的时候,余下的节点会选举出一个新的主节点,从而保证系统可以正常运行。
3）仲裁节点不复制数据,仅参与投票。由于它没有访问的压力,比较空闲,因此不容易出故障。由于副本集出现故障的时候,存活的节点必须大于副本集节点总数的一半,
否则无法选举主节点,或者主节点会自动降级为从节点,整个副本集变为只读。因此,增加一个不容易出故障的仲裁节点,可以增加有效选票,降低整个副本集不可用的
风险。仲裁节点可多于一个。也就是说只参与投票，不接收复制的数据，也不能成为活跃节点。
|
官方推荐MongoDB副本节点最少为3台， 建议副本集成员为奇数，最多12个副本节点,最多7个节点参与选举。限制副本节点的数量,主要是因为一个集群中过多的副本节点,增加了复制的成本,反而拖累了集群
的整体性能。 太多的副本节点参与选举,也会增加选举的时间。而官方建议奇数的节点,是为了避免脑裂 的发生。
3）副本集的工作流程
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 |
在 MongoDB 副本集中,主节点负责处理客户端的读写请求,备份节点则负责映射主节点的 数据。备份节点的工作原理过程可以大致描述为,备份节点定期轮询主节点上的数据操作,
然后对 自己的数据副本进行这些操作,从而保证跟主节点的数据同步。至于主节点上的所有 数据库状态改变 的操作,都会存放在一张特定的系统表中。备份节点则是根据这些数据进
行自己的数据更新。
oplog
上面提到的数据库状态改变的操作,称为 oplog(operation log,主节点操作记录)。oplog 存储在 local 数据库的"oplog.rs"表中。副本集中备份节点异步的从主节点同步 oplog,然后重新 执行它记录的操作,以此达到了数据同步的作用。
关于 oplog 有几个注意的地方:
1）oplog 只记录改变数据库状态的操作
2）存储在 oplog 中的操作并不是和主节点执行的操作完全一样,例如"$inc"操作就会转化为"$set"操作
3）oplog 存储在固定集合中(capped collection),当 oplog 的数量超过 oplogSize,新的操作就会覆盖就的操作
数据同步
在副本集中,有两种数据同步方式:
1）initial sync(初始化):这个过程发生在当副本集中创建一个新的数据库或其中某个节点刚从宕机中恢复,或者向副本集中添加新的成员的时候,默认的,副本集中的节点会从离 它最近
的节点复制 oplog 来同步数据,这个最近的节点可以是 primary 也可以是拥有最新 oplog 副本的 secondary 节点。该操作一般会重新初始化备份节点,开销较大。
2）replication(复制):在初始化后这个操作会一直持续的进行着,以保持各个 secondary 节点之间的数据同步。
initial sync
当遇到无法同步的问题时,只能使用以下两种方式进行 initial sync 了
1）第一种方式就是停止该节点,然后删除目录中的文件,重新启动该节点。这样,这个节 点就会执行 initial sync
注意:通过这种方式,sync 的时间是根据数据量大小的,如果数据量过大,sync 时间就 会很长
同时会有很多网络传输,可能会影响其他节点的工作
2）第二种方式,停止该节点,然后删除目录中的文件,找一个比较新的节点,然后把该节点目 录中的文件拷贝到要 sync 的节点目录中
通过上面两种方式中的一种,都可以重新恢复"port=33333"的节点。不在进行截图了。
副本集管理
1）查看oplog的信息 通过"db.printReplicationInfo()"命令可以查看 oplog 的信息
字段说明:
configured oplog size: oplog 文件大小
log length start to end: oplog 日志的启用时间段
oplog first event time: 第一个事务日志的产生时间
oplog last event time: 最后一个事务日志的产生时间
now: 现在的时间
2）查看 slave 状态 通过"db.printSlaveReplicationInfo()"可以查看 slave 的同步状态
当插入一条新的数据,然后重新检查 slave 状态时,就会发现 sync 时间更新了
|
4）副本集选举的过程和注意点
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
Mongodb副本集选举采用的是Bully算法，这是一种协调者(主节点)竞选算法,主要思想是集群的每个成员都可以声明它是主节点并通知其他节点。
别的节点可以选择接受这个声称或是拒绝并进入主节点竞争，被其他所有节点接受的节点才能成为主节点。
节点按照一些属性来判断谁应该胜出，这个属性可以是一个静态 ID,也可以是更新的度量像最近一次事务ID(最新的节点会胜出)
副本集的选举过程大致如下:
1）得到每个服务器节点的最后操作时间戳。每个 mongodb 都有 oplog 机制会记录本机的操作,方便和主服 务器进行对比数据是否同步还可以用于错误恢复。
2）如果集群中大部分服务器 down 机了,保留活着的节点都为 secondary 状态并停止,不选举了。
3）如果集群中选举出来的主节点或者所有从节点最后一次同步时间看起来很旧了,停止选举等待人来操作。
4）如果上面都没有问题就选择最后操作时间戳最新(保证数据是最新的)的服务器节点作为主节点。
副本集选举的特点：
选举还有个前提条件,参与选举的节点数量必须大于副本集总节点数量的一半（建议副本集成员为奇数。最多12个副本节点,最多7个节点参与选举）
如果已经小于一半了所有节点保持只读状态。集合中的成员一定要有大部分成员(即超过一半数量)是保持正常在线状态,3个成员的副本集,需要至少2个从属节点是正常状态。
如果一个从属节点挂掉,那么当主节点down掉 产生故障切换时,由于副本集中只有一个节点是正常的,少于一半,则选举失败。
4个成员的副本集,则需要3个成员是正常状态(先关闭一个从属节点,然后再关闭主节点,产生故障切换,此时副本集中只有2个节点正常,则无法成功选举出新主节点)。
|
5）副本集数据过程