【MongoDB】复制集群与特殊从节点(3)
一、MongoDB复制集介绍
MongoDB的复制集由至少一主两从构成,集群节点之间依靠监控投票机制(Raft)进行高可用。如果主库宕机,复制集群内部会进行投票选举出一个新的主库替代原主库,同时复制集群会告知客户端主库发生切换,类似Redis的哨兵。各节点之间的数据依靠oplog来实现数据同步,oplog类似于binlog,但是它存在于一张表里。
二、MongoDB复制集部署
1、正常部署好3个节点的MongoDB,注意配置文件新增的内容
cat > /data/mongodb/conf/mongo.conf << EOF systemLog: destination: file path: "/data/mongodb/log/mongodb.log" logAppend: true storage: journal: enabled: true dbPath: "/data/mongodb/data/" processManagement: fork: true net: port: 27017 bindIp: 192.168.10.110,127.0.0.1 security: authorization: enabled replication: oplogSizeMB: 2048 #oplog大小,超过则覆盖,相当于MySQL的binlog replSetName:my_repl #集群名字,初始化会用到这个名字 EOF ./mongod -f /data/mongodb/conf/mongo.conf #启动mongodb
2、选择一个节点作为主节点,执行操作
mongo --port 28017 admin #定义集群到config变量 config = { _id: 'my_repl', members: [ {_id:0, host: '192.168.10.101:28017'}, {_id:1, host: '192.168.10.102:28017'}, {_id:2, host: '192.168.10.103:28017'}, ] } #初始化集群,成功后命令提示符会发生变化 rs.initaite(config) #查询复制集状态 rs.status() #查看主节点信息 rs.isMaster() #查看节点配置信息,包括特殊节点、优先级 rs.conf
3、复制集部署完成后可以关闭主库进行测试
三、MongoDB复制集中特殊从库配置
1、arbiter:主要负责选主过程中的投票,不会与主库进行数据同步,也不提供服务
· 方法1:在搭建初期定义为arbiter
mongo --port 28017 admin #定义集群到config变量 config = { _id: 'my_repl', members: [ {_id:0, host: '192.168.10.101:28017'}, {_id:1, host: '192.168.10.102:28017'}, {_id:2, host: '192.168.10.103:28017',"arbiterOnly": true}, ] } #初始化集群,成功后命令提示符会发生变化 rs.initaite(config)
· 方法2:将现有集群的某节点修改为arbiter
rs.remove("192.168.10.102:28017") #先将节点踢出集群,同样rs.add可以增加一个节点 rs.addArb("192.168.10.102:28017") #重新加入集群并作为arbiter,这个时候节点的health是不正常的 mongod -f /mongodb/conf/mongod.conf #在10.102节点重启服务 rs.status() #查看节点health恢复正常
2、hidden:隐藏节点,不参与选主,也不提供服务。
3、delay:延迟从库,和MySQL中的延迟从库是一个作用。由于有延迟,通常也会将delay节点配置为hidden
cfg=rs.conf() #获取配置信息 cfg.members[3].priority=0 #定义权重为0,也就是不参与选主。这里members[3]里的3并不是re.conf()里看到的id值,而是按顺序从0数出来的 cfg.members[3].hidden=true #隐藏节点 cfg.members[3].slaveDelay=3600 #延迟1小时 cfg.members[3].votes=0 #持有票数为0 rs.reconfig(cfg) #重新加载配置 rs.conf() #查看检查配置
版权声明:本文章版权归数据库运维网(www.ywdba.cn)所有。如需引用本站内容,请注明来源及作者。
评论