mongodb副本集

Mongodb副本集。

服务器配置

主机名和IP应用程序

1-81 172.16.1.81 mongodb-3.6.23

1-82 172.16.1.82 mongodb-3.6.23

1-83 172.16.1.83 mongodb-3.6.23

0副本集数据过程

(1)主节点写入数据，辅助节点通过读取主节点的oplog获取拷贝信息，开始拷贝数据并将拷贝信息写入自身。

的Oplog。如果操作失败，备份节点将停止从当前数据源复制数据。如果备份节点由于某种原因挂起，当重新启动时。

之后，它会自动从oplog的最后一次操作开始同步。同步完成后，它会将信息写入自己的oplog。因为复制操作是先复制数据，再完成复制。

完成后写入oplog，有可能同一个操作会同步成两个副本，但是MongoDB在设计之初就考虑到了这个问题，执行了oplog的同一个操作。

多次执行与执行一次效果相同。简单来说就是：

主节点完成数据操作后，次节点会做出一系列动作来保证数据同步：

1)检查本地库的oplog.rs集合，找出最新的时间戳。

2)检查主节点本地库的oplog.rs集合，找出大于此时间戳的记录。

3)将找到的记录插入到您自己的oplog.rs集合中，并执行这些操作。

(2)副本集的同步与主从同步相同，是一个异步同步过程。不同之处在于副本集具有自动故障转移功能。原则是奴隶一方。

从主端获取日志，然后在自己身上按完整的顺序执行日志中记录的各种操作(这个日志不记录查询操作)，这个日志就是。

是本地数据库中的oplog.rs表。默认情况下，该表在64位计算机上相对较大，占磁盘大小的5%。oplog.rs的大小可以在启动时用作参数。

Set' - oplogSize 1000' in m.

(3)请注意，在复制副本集环境中，如果所有辅助节点都关闭，将只剩下主节点，最后主节点将变成辅助节点。

提供服务。

(4)默认情况下，mongodb从主节点读写数据。副本节点上不允许读取和写入，因此需要将副本节点设置为读取。

1配置参数。

# cat/opt/MongoDB/conf/MongoDB . conf EOF

dbpath=/opt/mongodb/data

#数据库文件位置

bind_ip=172.16.1.81

#绑定地址，默认为127.0.0.1，只能本地连接，每个节点的绑定ip不同。

端口=27017

# port，默认为27017，MongoDB的默认服务TCP端口，监听客户端连接。

日志=真

#启用日志文件，默认情况下是启用的。

log path=/opt/MongoDB/log/MongoDB . log

#日志文件位置，日志文件必须存在，否则将报告错误。

pidfilepath=/opt/MongoDB/MongoDB . PID

#后台进程pid文件。

对数=真

#通过追加写入日志。

安静=真实

#这个选项可以过滤掉一些无用的日志信息。如果需要调试，请设置为false。

fork=true

#作为守护进程运行。

# shardsvr=真

#碎片配置

#directoryperdb=false

#是否将数据修改为目录存储模式，默认值为false。

#auth=true

# KeyFile=/opt/MongoDB/conf/MongoDB-KeyFile

#群集私钥的完整路径，仅对复制集体系结构有效，在auth=true时配置。

replSet=mongodb-replset

# mongodb副本集名称。

oplogSize=40960

#设置oplog的大小。节点操作记录存储在本地的oplog中，以便从kula中检索。

#单位mb，磁盘满后循环覆盖。默认值为磁盘大小的5%。

文件结束

2创建集群。

# mongo -主机172.16.1.81 -端口27017

使用管理员

#定义副本集配置变量，其中_ id :“MongoDB-replSet”和mongodb.conf配置参数“replSet”应保持相同。

config={ _ id : ' MongoDB-repl set '，members:[{_id:0，host : ' 172 . 16 . 1 . 81:27017 ' }，{_id:1，host : ' 172 . 16 . 1 . 82:27017 ' }，{_id:2，host : ' 1770

#初始化副本集配置。

rs.initiate(配置)

#查看集群配置。

rs.conf()

#检查集群节点的状态。

rs.status()

注：

成功配置复制副本后，172.16.1.81是复制副本的主节点，172.16.1.82/83是复制副本的辅助节点。

健康：1 1 1正常，0表示异常。

状态：1小值是主节点，大值是次节点。

#从库中设置延迟。

cfg=rs.conf()

cfg.members[2].优先级=0

cfg.members[2].隐藏的

= true
cfg.members[2].slaveDelay = 3600
rs.reconfig(cfg)
注:
这里将id为2的172.16.1.83节点作为延迟从库，延迟时间为3600s。
cfg.members[2].priority = 0 表示延迟从库永远不会变为主节点。
3 添加认证
(1) 创建管理用户(在主节点上操作)
# mongo --host 172.16.1.81 --port 27017
use admin
db.createUser({user: "root",pwd: "123456",roles: [ { role: "root", db: "admin" } ]})
exit
(2) 分发认证key(在主节点上操作)
# openssl rand -base64 741 /opt/mongodb/conf/mongodb-keyfile
# chmod 600 /opt/mongodb/conf/mongodb-keyfile
# chown mongodb:mongodb /opt/mongodb/conf/mongodb-keyfile
# scp -p /opt/mongodb/conf/mongodb-keyfile root@172.16.1.82:/opt/mongodb/conf/
# scp -p /opt/mongodb/conf/mongodb-keyfile root@172.16.1.83:/opt/mongodb/conf/
# ssh -p 22 root@172.16.1.82 "chown mongodb:mongodb /opt/mongodb/conf/mongodb-keyfile"
# ssh -p 22 root@172.16.1.83 "chown mongodb:mongodb /opt/mongodb/conf/mongodb-keyfile"
(3) 修改配置文件(在三个节点上分别操作)
# cat /opt/mongodb/conf/mongodb.conf EOF
auth=true
keyFile=/opt/mongodb/conf/mongodb-keyfile
EOF
(4) 重启mongodb服务(依次重启三个节点)
# systemctl restart mongodb.service
# systemctl status mongodb.service
(5) 测试
# 主节点
# mongo --host 172.16.1.81 --port 27017 -uroot -p'123456' admin
use master_slave_test
function add(){var i = 0;for(;i7;i++){db.persons.insert({"name":"master_slave_test"+i})}}
add()
db.persons.find()
# 从节点
# mongo --host 172.16.1.82 --port 27017 -uroot -p'123456' admin
db.getMongo().setSecondaryOk()
use master_slave_test
db.persons.find()
# mongo --host 172.16.1.83 --port 27017 -uroot -p'123456' admin
db.getMongo().setSecondaryOk()
use master_slave_test
db.persons.find()
注:
# mongodb默认是从主节点读写数据的，副本节点上不允许读写，需要设置副本节点可以读
mongodb-replset:SECONDARY db.getMongo().setSecondaryOk() = mongodb-replset:SECONDARY rs.secondaryOk()
4 副本集的工作流程
(1) mongodb的oplog.rs表记录日志是默认开启的，大小为磁盘的5%。
(2) 在MongoDB副本集中，主节点负责处理客户端的读写请求，备份节点则负责映射主节点的数据。备份节点的工作原理过程可以大
致描述为，备份节点定期轮询主节点上的数据操作，然后对自己的数据副本进行这些操作，从而保证跟主节点的数据同步。至于主节
点上的所有数据库状态改变的操作，都会存放在一张特定的系统表中。备份节点则是根据这些数据进行自己的数据更新。
(3) oplog
上面提到的数据库状态改变的操作称为oplog(operation log，主节点操作记录)。oplog存储在local数据库的"oplog.rs"表中。
副本集中备份节点异步的从主节点同步oplog，然后重新执行它记录的操作，以此达到了数据同步的作用。关于oplog有几个注意的
地方:
1) oplog只记录改变数据库状态的操作。
2) 存储在oplog中的操作并不是和主节点执行的操作完全一样，例如"$inc"操作就会转化为"$set"操作。
3) oplog存储在固定集合中(capped collection)，当oplog的数量超过oplogSize，新的操作就会覆盖就的操作。
(4) 数据同步
在副本集中，有两种数据同步方式:
1) initial sync(初始化): 这个过程发生在当副本集中创建一个新的数据库或其中某个节点刚从宕机中恢复，或者向副本集中添
加新的成员的时候，默认的副本集中的节点会从离它最近的节点复制oplog来同步数据，这个最近的节点可以是primary也可以是拥
有最新oplog副本的secondary节点。该操作一般会重新初始化备份节点，开销较大。
2) replication(复制): 在初始化后这个操作会一直持续的进行着，以保持各个secondary节点之间的数据同步。
(5) initial sync
当遇到无法同步的问题时，只能使用以下两种方式进行initial sync了
1) 第一种方式就是停止该节点，然后删除目录中的文件，重新启动该节点。这样这个节点就会执行initial sync。
注意: 通过这种方式sync的时间是根据数据量大小的，如果数据量过大，sync时间就会很长，同时会有很多网络传输，可能会影响
其他节点的工作。
2) 第二种方式是停止该节点，然后删除目录中的文件，找一个比较新的节点，然后把该节点目录中的文件拷贝到要sync的节点目录
中。
3) 通过上面两种方式中的一种，都可以重新恢复宕机的节点。
(6) 副本集管理
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时间更新了。