MongoDB--监控复制(复制，索引，oplog)

MongoDB–监控复制

一：获取复制集状态

cqsm>rs.status()
{
        "set" : "cqsm1",
        "date" : ISODate("2019-12-06T02:43:38.315Z"),
        "myState" : 1,
        "term" : NumberLong(5),
        "syncingTo" : "",
        "syncSourceHost" : "",
        "syncSourceId" : -1,
        "heartbeatIntervalMillis" : NumberLong(2000),
        "optimes" : {
                "lastCommittedOpTime" : {
                        "ts" : Timestamp(1575600215, 1),
                        "t" : NumberLong(5)
                },
                "readConcernMajorityOpTime" : {
                        "ts" : Timestamp(1575600215, 1),
                        "t" : NumberLong(5)
                },
                "appliedOpTime" : {
                        "ts" : Timestamp(1575600215, 1),
                        "t" : NumberLong(5)
                },
                "durableOpTime" : {
                        "ts" : Timestamp(1575600215, 1),
                        "t" : NumberLong(5)
                }
        },
        "members" : [
                {
                        "_id" : 0,
                        "name" : "192.168.2.101:27017",
                        "health" : 1,
                        "state" : 2,
                        "stateStr" : "SECONDARY",
                        "uptime" : 2726,
                        "optime" : {
                                "ts" : Timestamp(1575600215, 1),
                                "t" : NumberLong(5)
                        },
                        "optimeDurable" : {
                                "ts" : Timestamp(1575600215, 1),
                                "t" : NumberLong(5)
                        },
                        "optimeDate" : ISODate("2019-12-06T02:43:35Z"),
                        "optimeDurableDate" : ISODate("2019-12-06T02:43:35Z"),
                        "lastHeartbeat" : ISODate("2019-12-06T02:43:37.648Z"),
                        "lastHeartbeatRecv" : ISODate("2019-12-06T02:43:36.725Z"),
                        "pingMs" : NumberLong(0),
                        "lastHeartbeatMessage" : "",
                        "syncingTo" : "192.168.2.103:27017",
                        "syncSourceHost" : "192.168.2.103:27017",
                        "syncSourceId" : 2,
                        "infoMessage" : "",
                        "configVersion" : 3
                },
                {
                        "_id" : 1,
                        "name" : "192.168.2.102:27017",
                        "health" : 1,
                        "state" : 2,
                        "stateStr" : "SECONDARY",
                        "uptime" : 2763,
                        "optime" : {
                                "ts" : Timestamp(1575600215, 1),
                                "t" : NumberLong(5)
                        },
                        "optimeDurable" : {
                                "ts" : Timestamp(1575600215, 1),
                                "t" : NumberLong(5)
                        },
                        "optimeDate" : ISODate("2019-12-06T02:43:35Z"),
                        "optimeDurableDate" : ISODate("2019-12-06T02:43:35Z"),
                        "lastHeartbeat" : ISODate("2019-12-06T02:43:37.796Z"),
                        "lastHeartbeatRecv" : ISODate("2019-12-06T02:43:38.170Z"),
                        "pingMs" : NumberLong(0),
                        "lastHeartbeatMessage" : "",
                        "syncingTo" : "192.168.2.103:27017",
                        "syncSourceHost" : "192.168.2.103:27017",
                        "syncSourceId" : 2,
                        "infoMessage" : "",
                        "configVersion" : 3
                },
                {
                        "_id" : 2,
                        "name" : "192.168.2.103:27017",
                        "health" : 1,
                        "state" : 1,
                        "stateStr" : "PRIMARY",
                        "uptime" : 82070,
                        "optime" : {
                                "ts" : Timestamp(1575600215, 1),
                                "t" : NumberLong(5)
                        },
                        "optimeDate" : ISODate("2019-12-06T02:43:35Z"),
                        "syncingTo" : "",
                        "syncSourceHost" : "",
                        "syncSourceId" : -1,
                        "infoMessage" : "",
                        "electionTime" : Timestamp(1575597455, 1),
                        "electionDate" : ISODate("2019-12-06T01:57:35Z"),
                        "configVersion" : 3,
                        "self" : true,
                        "lastHeartbeatMessage" : ""
                }
        ],
        "ok" : 1,
        "operationTime" : Timestamp(1575600215, 1),
        "$clusterTime" : {
                "clusterTime" : Timestamp(1575600215, 1),
                "signature" : {
                        "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
                        "keyId" : NumberLong(0)
                }
        }
}

几个比较有用的字段

stateStr：描述服务器状态

uptime：此成员可达到现在所经历的时间，单位是s。

optimeDate：每个成员的oplog中最后一个操作的发送时间

“self” : true ：当前节点

errmsg：成员在心跳请求中返回的状态信息

syncingTo:表示当前节点正在那个节点复制数据

二：复制图谱

1. 查看复制源

使用replSetGetStatus命令可以弄清楚复制图谱

test1>db.adminCommand({replSetGetStatus:1})['syncingTo']
192.168.2.103:27017

test1>db.adminCommand({replSetGetStatus:1})['syncingTo']
192.168.2.103:27017

MongoDB根据ping时间选择复制源，选择同步源的时候会选择一个离自己比较近的而且数据比自己新的成员(所以不会出现循环复制的情况，每个成员要么从主节点复制，要么从数据比它新的成员处复制)

自动复制链会有一些缺点，复制链越长将数据同步到全部服务器花费的时间就越长，因为复制链中的每一个备份节点都要比它前面的备份节点稍微落后一下。可以通过replSetSyncFrom或者辅助函数rs.syncFrom()命令修改成员的复制源。

>db.adminCommand({"replSetSyncFrom":"196.128.2.101:27017"})

三：复制循环

复制链中出现了环，A从B同步数据，B从C同步数据，C又从A同步数据，这就是发生了复制循环，造成成员无法更新新的写操作，就会越来越落后。

• 如果每个成员都自动选取数据源，就不可能发生复制循环
• 手动通过replSetSyncFrom设置复制源如果选取了不比自己领先的成员就可能发生复制循环

四：禁用复制链

禁用复制链之后成员就只能从主节点复制了,默认chainingAllowed=true

>var config=rs.config()
>config.settings.chainingAllowed=false
>rs.reconfig(config)

五：主节点较备份节点的落后程度

db.getReplicationInfo()            #查看 oplog 的状态，输出信息包括 oplog 日志大小，操作日志记录的起始时间
db.printReplicationInfo()          #查看oplog的状态、总大小、使用大小、存储的时间范围、记录时长。
db.oplog.rs.stats().maxSize        #显示当前的oplog大小 maxSize

使用db.printReplicationInfo()输出oplog相关的信息

admin>db.printReplicationInfo()
configured oplog size:   1500.73974609375MB   //oplog的大小
log length start to end: 171837secs (47.73hrs)  //oplog从开始到结束的时间
oplog first event time:  Wed Dec 04 2019 11:52:23 GMT+0800 (CST) //第一次
oplog last event time:   Fri Dec 06 2019 11:36:20 GMT+0800 (CST)//最后一次
now:                     Fri Dec 06 2019 11:36:23 GMT+0800 (CST) //现在

通过db.printSlaveReplicationInfo()就可以知道备份节点比主节点落后多少

admin>db.printSlaveReplicationInfo()
source: 192.168.2.101:27017
        syncedTo: Fri Dec 06 2019 11:40:20 GMT+0800 (CST)
        0 secs (0 hrs) behind the primary 
source: 192.168.2.102:27017
        syncedTo: Fri Dec 06 2019 11:40:20 GMT+0800 (CST)
        0 secs (0 hrs) behind the primary 

六：调整oplog大小

1. MongoDB 3.6版本之前

复制集是通过oplog来同步数据的，oplog的长度可以看做维护工作的时间窗。可以将oplog的长度设定长一些，比如几天或者一个周，这样oplog就可以保存更久的数据，也预留给自己足够的时间处理各种突发情况。plogSize可以通过–oplogSize设置大小，对于Linux 和Windows 64位，oplog size默认为剩余磁盘空间的5%。

增加oplog大小的步骤：

1）如果当前节点是主节点，让它退位，便于其他成员的数据尽快同步一致

>rs.stepDown()
或者
>rs.freeze()

2）关闭当前服务器

ps -ef --port --dbpath /home/hadoop/apps/mongodb/data

3）让当前节点以单机模式启动，指定其他的端口

> ./mongod --port 24000 --dbpath /home/hadoop/apps/mongodb/data
或者
vi mongoconf.conf,将replSet=复制集名注释掉
> ./mongod -f /home/hadoop/apps/mongodb/bin/conf/mongocon.conf

4）临时将oplog中的最后一条insert操作保存到其他集合中

use local
var cursor=db.oplog.rs.find({"op":"i"})
var lastInsert=cursor.sort({"$natural":-1}).limit(1).next() //将集合里面的数据按照磁盘上的位置排序，倒叙，取第一个
db.tempLast0p.save(lastInsert)
db.tempLast0p.findOne()

5）删除当前的oplog

>db.oplog.rs.drop()

6）创建一个新的oplog

db.createCollection("oplog.rs",{"capped":true,"size":10000})

3）将纪录写回oplog

var tmp=db.tempLast0p.findOne()
db.oplog.rs.insert(tmp)

2. MongoDB 3.6版本之后

在版本3.6之后，支持动态修改oplog 的大小了

查看修改前的oplogSize

local>db.getReplicationInfo()
{
        "logSizeMB" : 1440.1064453125,
        "usedMB" : 0.86,
        "timeDiff" : 192721,
        "timeDiffHours" : 53.53,
        "tFirst" : "Wed Dec 04 2019 11:52:23 GMT+0800 (CST)",
        "tLast" : "Fri Dec 06 2019 17:24:24 GMT+0800 (CST)",
        "now" : "Fri Dec 06 2019 17:24:30 GMT+0800 (CST)"
}
local>db.oplog.rs.stats().maxSize
NumberLong(1510061056)

1）使用管理命令修改

local>db.adminCommand({replSetResizeOplog:1,size:2024})  //单位是MB
{
        "ok" : 1,
        "operationTime" : Timestamp(1575624454, 1),
        "$clusterTime" : {
                "clusterTime" : Timestamp(1575624454, 1),
                "signature" : {
                        "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
                        "keyId" : NumberLong(0)
                }
        }
}
local>db.oplog.rs.stats().maxSize  //检查
NumberLong(2122317824) 

七：从延迟备份节点中恢复

1.关闭所有其他成员

2.删除其他成员数据目录中的所有数据。确保每个成员的数据目录都是空的

3.重启所有成员，它们会自动从延迟备份节点中恢复数据

八：阻止备份节点创建索引

如果向主节点创建索引的命令，主节点会正常创建索引，然后备份节点在复制“创建索引”操作的时候也会创建索引

但是创建索引十分消耗资源，会导致成员不可用。可以只在一个成员是创建索引而不发生复制

方式一：

临时处理让某些节点无法复制索引

1.禁用复制链，将chainingAllowed=false
2.关闭一个备份节点服务器
3.将这个服务器以单机模式启动
4.在单机模式下创键索引
5.索引创建完成之后，将服务器作为副本集成员重新启动
6.对副本集的每个备份节点重复2~5步

现在除了主节点其他的复制集成员都创建了索引，现在有两个方式：
1）在主节点是创建索引（在主节点创建索引期间，不可用，可以修改读选项，在备份节点读取数据）
主节点创建索引完成之后，由于备份节点已经有了同样的索引，实际上不会再创建索引
2）让主节点退位为备份节点，也执行上面的2~5步。在主节点退位了普通节点期间，新的主节点被选出来，保证系统正常运行。创建完索引，重新添加进副本集。

注意：
与其他节点索引不同的节点，应该将优先级设置为0；
创建唯一索引的时候必须保证主节点中没有被插入重复的数据，否则备份节点备份数据会报错

方式二：

添加节点的时候指定buidIndex=false，让其无法创键索引

>conf=rs.config()
>conf.members[2].priority=0   //优先级设置为0
>conf.members[2].buildIndexes=false  //是否允许创建索引
>rs.reconfig(conf)  //重新加载

但是会报错
"errmsg" : "New and old configurations differ in the setting of the buildIndexes field for member 192.168.2.103:27017; to make this change, remove then re-add the member"

于是删除再重新添加
> rs.remove("node3:27017")
> rs.add({_id: 2, host: "node3:27017", priority: 0, buildIndexes:false})

九：备份节点只用来灾难恢复

加入复制集的时候设置如下参数：

• “priority”:0 //优先级设置为0
• “hidden”:true //设置为隐藏成员
• “buidIndexes”:false //不可创建索引
• “votes”:0 //没有投票权，只有两台服务器，如果将备份节点的投票数设置为0，那备份节点挂掉了，主节点不会退位。如果有第三台服务器，应该在第三台上运行一个仲裁者成员而不是设置vates为0