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

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

 

(一)查看副本集状态
要查看副本集状态及每个成员的状态，可以连接到主节点，使用 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:27017syncedTo: 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.693359375MBlog 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小时的日志。

 

 

【完】

总结

以上是内存溢出为你收集整理的MongoDB副本集replica set（五）--故障排查全部内容，希望文章能够帮你解决MongoDB副本集replica set（五）--故障排查所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。