MongoDB副本集replica set五--故障排查

 

(一)查看副本集状态
要查看副本集状态及每个成员的状态，可以连接到主节点，使用 rs.status() 命令查看：

rstest:PRIMARY> rs.status()
{
"set" : rstest",date" : ISODate(2020-06-30T15:06:44.586Z),1)">myState1term" : NumberLong(15syncingTo""syncSourceHostsyncSourceId" : -heartbeatIntervalMillis2000majorityVoteCount2writeMajorityCountoptimes : {
lastCommittedOpTimets" : Timestamp(1593529598,t)
},1)">lastCommittedWallTime2020-06-30T15:06:38.972ZreadConcernMajorityOpTimereadConcernMajorityWallTimeappliedOpTimedurableOpTimelastAppliedWallTimelastDurableWallTimelastStableRecoveryTimestamp1593529578,1)">lastStableCheckpointTimestampelectionCandidateMetricslastElectionReasonpriorityTakeoverlastElectionDate2020-06-30T11:42:47.656ZelectionTermlastCommittedOpTimeAtElection1593517366,1)">14lastSeenOpTimeAtElectionnumVotesNeededpriorityAtElection3electionTimeoutMillis10000priorPrimaryMemberIdnumCatchUpOps0newTermStartDate2020-06-30T11:42:47.731ZwMajorityWriteAvailabilityDate2020-06-30T11:42:48.789ZelectionParticipantMetricsvotedForCandidate" : truelastVoteDate2020-06-30T11:42:36.235ZelectionCandidateMemberIdvoteReasonlastAppliedOpTimeAtElection1593364745,1)">12maxAppliedOpTimeInSet
},1)">members : [
{
_idname192.168.10.41:27017healthstatestateStrPRIMARYuptime12262optimeoptimeDate2020-06-30T15:06:38ZinfoMessageelectionTime1593517367,1)">electionDate2020-06-30T11:42:47ZconfigVersionselflastHeartbeatMessage192.168.10.43:27017SECONDARY12258optimeDurableoptimeDurableDatelastHeartbeat2020-06-30T15:06:43.724ZlastHeartbeatRecv2020-06-30T15:06:43.051ZpingMs192.168.10.42:27017
}
],1)">ok$clusterTimeclusterTimesignaturehash" : BinData(0,1)">JcYryJc0DU0GgX0mCKS1D86r30Y=keyId6841443127941660675)
}
},1)">operationTime)
}

View Code

 

(二)检查复制滞后
复制滞后是主节点上的操作与从节点的操作之间的延迟，复制滞后会导致读取数据不一致，次级节点跟上oplog窗口导致重新同步数据等。
要检查复制滞后，可以在主节点使用 rs.printSlaveReplicationInfo() 方法，结果如下：

rstest:PRIMARY> rs.printSlaveReplicationInfo()
source: 192.168.10.43:27017
syncedTo: Tue Jun 30 2020 23:14:59 GMT+0800 (CST)
0 secs ( hrs) behind the primary 
source: 10.42:0 hrs) behind the primary

滞后的原因：
1.网络延迟。检查副本集成员之间的网络路由，确保没有数据丢包或网络路由问题。可以使用ping或traceroute来确认。
2.磁盘吞吐量。使用iostat或vmstat评估磁盘状态。
3.大事务操作。主节点上长时间运行的操作可能会阻塞次级节点的复制。
4.合理的写关心(write concern)。如果需要对主数据库进行大量写入，执行大批量数据加载操作，则辅助数据库无法跟上主节点。

 

(三)测试所有成员之间的连接
副本集的所有成员必须能够连接到该集合的每一个其它成员以支持复制。如果节点复制异常，可以排查节点之间的连通性。
如存在3个节点的副本集：
m1.example.net
m2.example.net
m3.example.net

在节点m1.example.net上测试能否正常连接到其它2个节点

mongo --host m2.example.net --port 
mongo --host m3.example.net --port 27017 

在节点m2.example.net上测试能否正常连接到其它2个节点

mongo --host m1.example.net --port 27017

在节点m3.example.net上测试能否正常连接到其它2个节点

mongo --host m1.example.net --port 
mongo --host m2.example.net --port 27017

 

(四)检查oplog的大小
较大的oplog可以使副本集对延迟的容忍度更高，要检查oplog大小，请在当前节点执行 rs.printReplicationInfo() 方法。

rstest:SECONDARY> rs.printReplicationInfo()
configured oplog size: 2115.693359375MB
log length start to end: 634163secs (176.16hrs)
oplog first event time: Tue Jun 23 15:33:16 GMT+ (CST)
oplog last event 42:39 GMT+ (CST)
now: Tue Jun 50 GMT+ (CST)
rstest:SECONDARY> 

操作日志应该足够大，至少能够保存24小时的日志。

 

 

【完】