MongoDB 副本集管理-不定期更新(8)
发布日期:2021-08-19 21:58:24 浏览次数:14 分类:技术文章

本文共 9913 字,大约阅读时间需要 33 分钟。

简介:

      前面介绍完了的说明,那副本集搭建好该如何管理呢?现在来说明下副本集的日常查看和管理。

说明:

1)查看命令行参数db.serverCmdLineOpts()

zjy:PRIMARY> db.serverCmdLineOpts(){    "argv" : [        "mongod",        "-f",        "/etc/mongodb/mongodb_27017.conf"    ],    "parsed" : {        "config" : "/etc/mongodb/mongodb_27017.conf",        "diaglog" : 3,        "net" : {            "maxIncomingConnections" : 50,            "port" : 27017,            "unixDomainSocket" : {                "pathPrefix" : "/tmp"            }        },        "processManagement" : {            "fork" : true,            "pidFilePath" : "/var/run/mongo_27017.pid"        },        "replication" : {            "replSet" : "zjy/127.0.0.1:27018"        },        "storage" : {            "dbPath" : "/usr/local/mongo1/",            "mmapv1" : {                "nsSize" : 16            }        },        "systemLog" : {            "destination" : "file",            "logAppend" : true,            "path" : "/var/log/mongodb/mongodb1.log"        }    },    "ok" : 1}

 

2)查看副本集状态rs.status()

zjy:PRIMARY> rs.status(){    "set" : "zjy",  #副本集名称    "date" : ISODate("2015-06-30T04:07:29.380Z"), #执行时间    "myState" : 1,     "members" : [  #成员        {            "_id" : 1,            "name" : "127.0.0.1:27017", #成员名称            "health" : 1,            "state" : 1,   #成员状态,1:Primary            "stateStr" : "PRIMARY", #状态描述            "uptime" : 27104, #副本集运行时间,Primary为MongoDB运行时间,单位秒            "optime" : Timestamp(1435301307, 10),  #最近一次更改数据库的时间:1435301307;每秒执行操作数据库的次数:10            "optimeDate" : ISODate("2015-06-26T06:48:27Z"),#最后一个操作发生的时间            "electionTime" : Timestamp(1435610150, 1),            "electionDate" : ISODate("2015-06-29T20:35:50Z"),#最后选举时间            "configVersion" : 31300,            "self" : true    #执行该命令函数的成员        },        {            "_id" : 2,            "name" : "127.0.0.1:27018",            "health" : 1,            "state" : 2, #成员状态,2:Secondary            "stateStr" : "SECONDARY",            "uptime" : 27098,            "optime" : Timestamp(1435301307, 10),            "optimeDate" : ISODate("2015-06-26T06:48:27Z"),            "lastHeartbeat" : ISODate("2015-06-30T04:07:28.589Z"), #最后一次收到其他成员心跳时间            "lastHeartbeatRecv" : ISODate("2015-06-30T04:07:27.784Z"),            "pingMs" : 0,  #心跳发送到达时间,根据其选择从哪个成员进行同步            "syncingTo" : "127.0.0.1:27017", #同步成员地址            "configVersion" : 31300        },        {            "_id" : 3,            "name" : "127.0.0.1:27019",            "health" : 1,            "state" : 2,            "stateStr" : "SECONDARY",            "uptime" : 27094,            "optime" : Timestamp(1435301307, 10),            "optimeDate" : ISODate("2015-06-26T06:48:27Z"),            "lastHeartbeat" : ISODate("2015-06-30T04:07:28.521Z"),            "lastHeartbeatRecv" : ISODate("2015-06-30T04:07:28.521Z"),            "pingMs" : 0,            "syncingTo" : "127.0.0.1:27017",            "configVersion" : 31300        }    ],    "ok" : 1}

mongod实例每隔两秒就会向其他成员发送一个心跳包,并且通过rs.status()中返回的成员的health来判断成员的状态。如果primary节点不可用了,那么复制集中的所有secondary节点都会触发一次选举操作。选出新的primary节点。如果secondary节点有多个,则会选举拥有最新oplog时间戳记录的或者有较高权限的节点成为primary(注意:如果secondary停止时间过长,导致primary节点的oplog内容被循环写覆盖掉,则需要手动同步secondary节点)。

3)添加、删除副本集成员rs.add,rs.addArb(),rs.remove(),rs.reconfig()

1,添加成员rs.add('127.0.0.1:27020')在添加成员之前,需要在目标成员里加上repset参数。2,添加复杂的成员:rs.add({
"_id":4,"host":"192.168.200.252:27017","priority":0,"hidden":true,"slaveDelay":60})不会成为主节点(被动节点),隐藏节点、延迟60s同步数据。适用于当作备份;rs.add({
"_id":4,"host":"192.168.200.252:27017","votes":0})没有选举权限的节点,即使只剩下单个服务器的副本集,也不会成为Secondaryrs.add({
"_id":4,"host":"192.168.200.252:27017","buildIndexes":false})不会同步索引的创建rs.add({
"_id":4,"host":"192.168.200.252:27017","arbiterOnly":true}) rs.addArb()只选举,不会同步数据以上都可以通过rs.reconfig()来实现。3,删除成员rs.remove('127.0.0.1:27020')

4)查看副本集的配置rs.config()

zjy:PRIMARY> rs.config(){    "_id" : "zjy",      #副本集名称    "version" : 31300,    "members" : [       #各成员的配置选项        {            "_id" : 1,            "host" : "127.0.0.1:27017",            "arbiterOnly" : false,            "buildIndexes" : true,            "hidden" : false,            "priority" : 3,            "tags" : {                            },            "slaveDelay" : 0,            "votes" : 1        },.........    ],    "settings" : {        "chainingAllowed" : false,        "heartbeatTimeoutSecs" : 10,        "getLastErrorModes" : {                    },        "getLastErrorDefaults" : {            "w" : 1,            "wtimeout" : 0        }    }}

 

5)修改任一Secondary的同步源replSetSyncFrom(rs.syncFrom()),需要在Secondary上执行。

查看其中的一个Secondary的同步源zjy:SECONDARY> db.adminCommand({
"replSetGetStatus":1}).syncingTo127.0.0.1:27017# 本机是27019实例,暂时需要把这个实例从27018上同步:zjy:SECONDARY> db.adminCommand({
"replSetSyncFrom":"127.0.0.1:27018"}) <==> rs.syncFrom("127.0.0.1:27018"){ "syncFromRequested" : "127.0.0.1:27018", "prevSyncTarget" : "127.0.0.1:27017", "ok" : 1}zjy:SECONDARY> db.adminCommand({
"replSetGetStatus":1}).syncingTo127.0.0.1:27018也可以通过rs.status()来查看其同步源zjy:SECONDARY> rs.status().syncingTo127.0.0.1:27018

6)让任一Secondary进入维护模式replSetMaintenance,必须在Secondary里的admin下运行,之后会进入状态。

在副本集上执行某个耗时的操作,会让成员进入recovering模式,不会有读请求发送给他,如何一个成员远落后主,可以强制让其进入维护模式。

zjy:SECONDARY> rs.status().members[......    {        "_id" : 3,        "name" : "127.0.0.1:27019",        "health" : 1,        "state" : 2,        "stateStr" : "SECONDARY",        "uptime" : 39275,        "optime" : Timestamp(1435301307, 10),        "optimeDate" : ISODate("2015-06-26T06:48:27Z"),        "syncingTo" : "127.0.0.1:27018",        "configVersion" : 31300,        "self" : true    }]zjy:SECONDARY> db.adminCommand({
"replSetMaintenance":true}){ "ok" : 1 }zjy:RECOVERING> rs.status().members[...... { "_id" : 3, "name" : "127.0.0.1:27019", "health" : 1, "state" : 3, "stateStr" : "RECOVERING", "uptime" : 39313, "optime" : Timestamp(1435301307, 10), "optimeDate" : ISODate("2015-06-26T06:48:27Z"), "syncingTo" : "127.0.0.1:27018", "maintenanceMode" : 1, "configVersion" : 31300, "self" : true }]看到127.0.0.1:27019 进入了RECOVERING

 

当进入维护模式之后,该节点的数据就不能读取了:

zjy:RECOVERING> db.aoe.find()Error: error: {    "$err" : "not master or secondary; cannot currently read from this replSet member",    "code" : 13436}

退出维护模式:

zjy:RECOVERING> db.adminCommand({
"replSetMaintenance":false}){ "ok" : 1 }zjy:SECONDARY> rs.status().members[...... { "_id" : 3, "name" : "127.0.0.1:27019", "health" : 1, "state" : 2, "stateStr" : "SECONDARY", "uptime" : 39425, "optime" : Timestamp(1435301307, 10), "optimeDate" : ISODate("2015-06-26T06:48:27Z"), "syncingTo" : "127.0.0.1:27017", "configVersion" : 31300, "self" : true }]

7)限制副本集自动寻找数据源的功能chainingAllowed

由于配置好的副本集都是自动的对同步源进行分配,根据pingMS来寻找最新的数据源,可能某个Secondary是另一个Secondary的同步源。下面就可以关闭自动分配,同步源指到Primary上:

zjy:PRIMARY> rs.config().settings{    "chainingAllowed" : true,    "heartbeatTimeoutSecs" : 10,    "getLastErrorModes" : {            },    "getLastErrorDefaults" : {        "w" : 1,        "wtimeout" : 0    }}zjy:PRIMARY> var cfg=rs.config()zjy:PRIMARY> cfg.settings.chainingAllowedtruezjy:PRIMARY> cfg.settings.chainingAllowed=falsefalsezjy:PRIMARY> cfg.settings.chainingAllowedfalsezjy:PRIMARY> rs.reconfig(cfg){ "ok" : 1 }zjy:PRIMARY> rs.config().settings{    "chainingAllowed" : false,    "heartbeatTimeoutSecs" : 10,    "getLastErrorModes" : {            },    "getLastErrorDefaults" : {        "w" : 1,        "wtimeout" : 0    }}

取消自动数据源分配的功能,可以有效的防止复制链的出现。但在一定的程度上会加大对Primary的压力。

8)主节点变成备份节点:rs.stepDown(time),rs.freeze(time) 

rs.stepDown(time) 可以让主节点退成备份节点,timie单位是秒,默认60s。60s内主被副本集的其他成员获得,时间到后,会重新进行选举,一般都会重新成为主(优先级)。

rs.freeze(time):阻止选举,始终出于备份节点状态。比如主节点需要做一些维护,不希望其他成员选举为主节点,可以在每个备份节点上执行。强制他们出于备份节点状态。

zjy:PRIMARY> rs.stepDown()    #退位60秒,60秒内成为备份节点。......2015-06-30T12:04:01.670-0400 I NETWORK  trying reconnect to 127.0.0.1:27017 (127.0.0.1) failed2015-06-30T12:04:01.671-0400 I NETWORK  reconnect 127.0.0.1:27017 (127.0.0.1) okzjy:SECONDARY> zjy:SECONDARY> rs.freeze(10)    #10秒内保持备份节点状态。{ "ok" : 1 }

9)复制延迟状态查看

zjy:PRIMARY> db.printReplicationInfo()  #主上执行,configured oplog size:   2823.249984741211MB   #oplog大小log length start to end: 4086845secs (1135.23hrs) #oplog使用的时间长度oplog first event time:  Thu May 14 2015 03:13:36 GMT-0400 (EDT) #最先一次操作时间oplog last event time:   Tue Jun 30 2015 10:27:41 GMT-0400 (EDT) #最后一次操作时间now:                     Tue Jun 30 2015 13:31:30 GMT-0400 (EDT) #当前时间zjy:SECONDARY> db.printSlaveReplicationInfo() #从上执行,各个从的落后时间source: 127.0.0.1:27018    syncedTo: Tue Jun 30 2015 10:27:41 GMT-0400 (EDT)    0 secs (0 hrs) behind the primary    #落后时间source: 127.0.0.1:27019    syncedTo: Tue Jun 30 2015 10:27:41 GMT-0400 (EDT)    0 secs (0 hrs) behind the primary

10)副本集优先级修改及参数配置

在设置mongodb副本集时,Primary节点,second节点,仲裁节点,有可能资源配置(CPU或者内存)不均衡,所以要求某些节点不能成为Primary

我们知道mongodb的设置:
除了仲裁节点,其他每个节点都有个优先权,可以手动设置优先权来决定谁的成为primay的权重最大。
副本集中通过设置priority的值来决定优先权的大小,这个值的范围是0--100,值越大,优先权越高。
默认的值是1,rs.conf是不显示的;
如果值是0,那么不能成为primay。
1.规划时直接设置,这个就略过了
2.在线加入的节点配置:
配置过程:
通过修改priority的值来实现(默认的优先级是1(0-100),priority的值设的越大,就优先成为主)

PRIMARY> config=rs.conf()PRIMARY>config.members[3].priority = 3PRIMARY> rs.reconfig(config)

注意:第2步members大括号里面的成员和_id是没有关系的,而是rs.conf查出来节点的数值的顺序;

这些操作必须在Primary上进程。

11)MongDB读写分离secondary可读

mongodb的读写分离使用Replica Sets来实现

 

对于replica set 中的secondary 节点默认是不可读的。在写多读少的应用中,使用Replica Sets来实现读写分离。通过在连接时指定或者在主库指定slaveOk,由Secondary来分担读的压力,Primary只承担写操作。

如果通过shell访问mongo,要在secondary进行查询。会出现如下错误:

imageSet:SECONDARY> db.fs.files.find()
error: { "$err" : "not master and slaveOk=false", "code" : 13435 }
有两种方法实现从机的查询:
第一种方法:db.getMongo().setSlaveOk();
第二种方法:rs.slaveOk();
但是这种方式有一个缺点就是,下次再通过mongo进入实例的时候,查询仍然会报错,为此可以通过下列方式
vi ~/.mongorc.js
增加一行rs.slaveOk();
这样的话以后每次通过mongo命令进入都可以查询了

......

转载于:https://www.cnblogs.com/Easonlou/p/6604386.html

转载地址:https://blog.csdn.net/weixin_30955341/article/details/98156353 如侵犯您的版权,请留言回复原文章的地址,我们会给您删除此文章,给您带来不便请您谅解!

上一篇:yii2在ubuntu下执行定时任务
下一篇:NIO与传统IO的区别

发表评论

最新留言

表示我来过!
[***.240.166.169]2024年12月24日 10时40分15秒