18.副本集

Posted 2022-11-25 大数据小小罗

副本集是对主从复制的一种完善，也是推荐的MongoDB的复制策略。

主从复制和副本集使用了相同的复制机制，但副本集与主从复制不同的地方在于，它还能够保证自动故障转移。

如果主节点由于某些原因下线了，可能的话，会自动将一个从节点提升为主节点。副本集还提供了其他增强，比如更易于恢复和更高级的部署拓扑。

用一个简单的例子表明副本集的工作原理：

第一张图表明A是活跃主节点，B、C都是用于备份的从节点。
第二张图中，当A发生了故障导致下线，B、C两个节点中将选出一个节点充当新的主节点。
第三张图中，当发生故障的A节点恢复之后，它只能成为集群中的备份节点。这样，又是一个完整的集群

1.配置一个集群

3个mongod的service启动脚本：

dbpath = D:\\sortware\\mongod\\02\\A
port = 1111  #端口
bind_ip = 127.0.0.1 #服务地址
replSet = child 

dbpath = D:\\sortware\\mongod\\02\\B
port = 2222
bind_ip = 127.0.0.1
replSet = child

dbpath = D:\\sortware\\mongod\\02\\C
port = 3333
bind_ip = 127.0.0.1
replSet = child

2.初始化副本集

use admin
db.runCommand("replSetInitiate":
   
      "_id":'child',
       "members":[
            "_id":1,
        "host":"127.0.0.1:1111"
        ,
        "_id":2,
        "host":"127.0.0.1:2222"
        ,
        "_id":3,
        "host":"127.0.0.1:3333"
        ]
    
)

3.查看副本集状态

查看角色：

查看副本集中各个角色配置的详细信息：

SECONDARY> rs.status()

        "set" : "child",
        "date" : ISODate("2016-12-21T03:34:12Z"),
        "myState" : 2,
        "syncingTo" : "127.0.0.1:1111",
        "members" : [
                
                        "_id" : 1,
                        "name" : "127.0.0.1:1111",
                        "health" : 1,
                        "state" : 1,
                        "stateStr" : "PRIMARY",
                        "uptime" : 173,
                        "optime" : 
                                "t" : 1482291059000,
                                "i" : 1
                        ,
                        "optimeDate" : ISODate("2016-12-21T03:30:59Z"),
                        "lastHeartbeat" : ISODate("2016-12-21T03:34:11Z"),
                        "pingMs" : 3
                ,
                
                        "_id" : 2,
                        "name" : "127.0.0.1:2222",
                        "health" : 1,
                        "state" : 2,
                        "stateStr" : "SECONDARY",
                        "optime" : 
                                "t" : 1482291059000,
                                "i" : 1
                        ,
                        "optimeDate" : ISODate("2016-12-21T03:30:59Z"),
                        "self" : true
                ,
                
                        "_id" : 3,
                        "name" : "127.0.0.1:3333",
                        "health" : 1,
                        "state" : 2,
                        "stateStr" : "SECONDARY",
                        "uptime" : 173,
                        "optime" : 
                                "t" : 1482291059000,
                                "i" : 1
                        ,
                        "optimeDate" : ISODate("2016-12-21T03:30:59Z"),
                        "lastHeartbeat" : ISODate("2016-12-21T03:34:11Z"),
                        "pingMs" : 1
                
        ],
        "ok" : 1

4.自动故障转移测试

关闭掉端口为1111（角色为PRIMARY）的主机，再次重新启动端口为1111的service和shell，查看角色有没有切换：

可以很明显的看出，原来的1111的角色从PRIMARY转换成了SERCONDARY

5.节点和初始化高级参数

参数	释义
standard	常规节点:参与投票有可能成为活跃节点
passive	副本节点:参与投票,但是不能成为活跃节点
arbiter	仲裁节点:只是参与投票不复制节点也不能成为活跃节点

高级参数的用法

Priority 0到1000之间。0代表是副本节点，永远不会被选举为主节点；1到1000是常规节点
arbiterOnly : true 仲裁节点

用法示例：

members":[
"_id":1,
"host":"127.0.0.1:1111“,
arbiterOnly : true
]”

优先级相同时候仲裁组建的规则

ABC三个主机优先级相同，当原来的主节点A宕机的时候，B主机（1秒前更新）比C主机（5秒前更新）更新的副本集是更新，则推选B作为当前集群中的主机

6.读写分离操作 扩展读

6.1一般情况下作为副本的节点是不能进行数据库读操作的，但是在读取密集型的系统中读写分离是十分必要的

6.2设置读写分离

     slaveOkay :  true

很遗憾他在shell中无法演示,这个特性是被写到mongoDB的
驱动程序中的,在java和node等其他语言中可以完成

7.Oplog

他是被存储在本地数据库local中的,他的每一个文档保证这一个节点操作

获取oplog大小信息

SECONDARY> db.getReplicationInfo()

        "logSizeMB" : 47.6837158203125,
        "usedMB" : 0.01,
        "timeDiff" : 16351,
        "timeDiffHours" : 4.54,
        "tFirst" : "Wed Dec 21 2016 11:30:59 GMT+0800",
        "tLast" : "Wed Dec 21 2016 16:03:30 GMT+0800",
        "now" : "Wed Dec 21 2016 16:18:33 GMT+0800"

32位系统默认是50MB，64位系统上将达到1GB或者空余磁盘空间的5%

向PRIMARY节点写入一行数据

PRIMARY> db.persons.insert("name":"tom")

在端口为2222（SECONDARY）的节点上查看一下本地的oplog日志：

SECONDARY> db.oplog.rs.find()
 "ts" :  "t" : 1482291059000, "i" : 1 , "h" : NumberLong(0), "op" : "n", "ns"
 : "", "o" :  "msg" : "initiating set"  
 "ts" :  "t" : 1482307410000, "i" : 1 , "h" : NumberLong("-245061301659343255
8"), "op" : "i", "ns" : "foobar.persons", "o" :  "_id" : ObjectId("585a37521057
0e3c88dcc2db"), "name" : "tom"  

发现第二行果真是有数据插入的操作记录

改变oplog大小

如果想故障恢复可以更彻底，oplog可尽量设置大一些用来保存更多的操作信息

主库启动服务时加上参数（单位是MB，比如1G：1024）：

--oplogSize  SIZE