MongoDB-ReplicationSet

基本原理

基本构成是1主2从的结构,自带互相监控投票机制(Raft(MongoDB)) Paxos(mysql MGR 用的是变种)
如果发生主库宕机,复制集内部会进行投票选举,选择一个新的主库替代原有主库对外提供服务。同时复制集
会自动通知客户端程序,主库已经发生切换。应用会连接到新的主库

环境规划

# 三个以上的mongodb节点(或多实例)

# 多个端口:28017、28018、28019、28020

# 多套目录:
mkdir -p /mongodb/{28017,28018,28019,28020}/{conf,data,log}

# 多套配置文件:
/mongodb/28017/conf/mongod.conf
/mongodb/28018/conf/mongod.conf
/mongodb/28019/conf/mongod.conf
/mongodb/28020/conf/mongod.conf

集群架构

一主二从

一个主库,两个从库组成,主库宕机时,这两个从库都可以被选为主库。

当主库宕机后,两个从库都会进行竞选,其中一个变为主库,当原主库恢复后,作为从库加入当前的复制集群即可。

一主一从一aribiter

一个主库,一个从库,可以在选举中成为主库
一个aribiter节点,在选举中,只进行投票,不能成为主库

说明:

由于arbiter节点没有复制数据,因此这个架构中仅提供一个完整的数据副本。arbiter节点只需要更少的资源,代价是更有限的冗余和容错。

当主库宕机时,将会选择从库成为主,主库修复后,将其加入到现有的复制集群中即可。

配置文件

systemLog:
  destination: file
  path: /mongodb/28017/log/mongodb.log
  logAppend: true
storage:
  journal:
    enabled: true
  dbPath: /mongodb/28017/data
  directoryPerDB: true
  #engine: wiredTiger
  wiredTiger:
    engineConfig:
      cacheSizeGB: 1
      directoryForIndexes: true
    collectionConfig:
      blockCompressor: zlib
    indexConfig:
      prefixCompression: true
processManagement:
  fork: true
net:
  bindIp: 127.0.0.1,172.16.1.100
  port: 28017
replication:
  oplogSizeMB: 2048
  replSetName: my_repl
  
# 启动多个实例
mongod -f /mongodb/28017/conf/mongod.conf
mongod -f /mongodb/28018/conf/mongod.conf
mongod -f /mongodb/28019/conf/mongod.conf
mongod -f /mongodb/28020/conf/mongod.conf

普通复制集

# 1主2从
mongo --port 28017 admin
config = {_id: 'my_repl', members: [
	{_id: 0, host: '172.16.1.100:28017'},
	{_id: 1, host: '172.16.1.100:28018'},
	{_id: 2, host: '172.16.1.100:28019'}]
}
rs.initiate(config)

# 查询复制集状态
rs.status();
# 1主1从1arbiter
mongo --port 28017 admin
config = {_id: 'my_repl', members: [
	{_id: 0, host: '172.16.1.100:28017'},
	{_id: 1, host: '172.16.1.100:28018'},
	{_id: 2, host: '172.16.1.100:28019', "arbiterOnly": true}]
}
rs.initiate(config)
复制集管理
# 查看复制集状态
rs.status();   # 查看整体复制集状态
rs.isMaster(); # 查看当前是否是主节点
rs.conf();     # 查看复制集配置信息

# 添加删除节点
rs.remove("ip:port")  # 删除一个节点
rs.add("ip:port")     # 新增从节点
rs.addArb("ip:port")  # 新增仲裁节点

# 连接到主节点
mongo --port 28017 admin
# 添加arbiter节点
my_repl:PRIMARY> rs.addArb("172.16.1.100:28020")
# 查看节点状态
my_repl:PRIMARY> rs.isMaster()
{
	"hosts" : [
		"172.16.1.100:28017",
		"172.16.1.100:28018"
	],
	"arbiters" : [
		"172.16.1.100:28019"
	]
}
特殊从节点
arbiter节点:主要负责选主过程中的投票,但是不存储任何数据,也不提供任何服务
hidden节点:隐藏节点,不参与选主,也不对外提供服务
delay节点:延时节点,数据落后主库一段时间,因为数据是延时的,也不应该提供服务或参与选主,所有通常会配合hidden(隐藏)
一般情况下会将delay+hidden一起配置使用
延时节点
cfg=rs.conf()
cfg.members[2].priority=0
cfg.members[2].hidden=true
cfg.members[2].slaveDelay=120
rs.reconfig(cfg)

# 取消以上配置
cfg=rs.conf()
cfg.members[2].priority=1
cfg.members[2].hidden=false
cfg.members[2].slaveDelay=0
rs.reconfig(cfg)

# 配置成功后,通过一下命令查询配置后的属性
rs.conf();
其他操作
# 查看副本集的配置信息
admin> rs.conf()

# 查看副本集各成员状态
admin> rs.status()

# 副本集角色切换(不要人为随便操作)
admin> rs.stepDown()
注:
admin> rs.freeze(300) # 锁定从,使其不会转变成主库
freeze()和stepDown单位都是秒

# 设置副本节点可读:在副本节点执行
admin> rs.slaveOk()
eg:
admin> use app
switched to db app
app> db.createCollection('a')
{ "ok" : 0, "errmsg" : "not master", "code" : 10107}

# 查看副本节点(监控主从延时)
admin> rs.printSlaveReplicationInfo()
source: 172.16.1.100:28018
	syncedTo: Wed Jan 05 2022 16:22:04 GMT+0800 (CST)
	0 secs (0 hrs) behind the primary 
source: 172.16.1.100:28019
	no replication info, yet.  State: (not reachable/healthy)

posted @ 2022-02-15 11:18  Cai_HL  阅读(63)  评论(0)    收藏  举报
>