MONGO集群修改linux主机时间后的影响有哪些

小编给大家分享一下MONGO集群修改linux主机时间后的影响有哪些，希望大家阅读完这篇文章之后都有所收获，下面让我们一起去探讨吧！生产环境是
一主一从一仲裁3分片的集群，现在发现其中一个节点比当前时间大了好几天，后使用NTP将时间往回调整副本集上。原来时间是5月3日，当前是
4月26日，对此进行了调整。[root@cwdtest1 bin]# dateFri May 3 13:20:31 CST 2019[root@cwdtest1 bin]# ntpdate -u 10.205.34.17126 Apr 12:39:23 ntpdate[14568]: step time server 10.205.34.171 offset -607507.747595 sec[root@cwdtest1 bin]# hwclock –systohc调整后当前的时间：[root@cwdtest1 bin]# dateFri Apr 26 12:39:31 CST 2019当完成调整时间之后，发现两个问题：1.副本集无法同步新的oplog，由此出现了延迟shard2:PRIMARY> db.printSlaveReplicationInfo();source: 10.3.252.231:27002syncedTo: Fri May 03 2019 13:24:23 GMT+0800 (CST)8 secs (0 hrs) behind the primary2.查看oplog的
tLast时间比当前的大shard2:PRIMARY> db.getReplicationInfo(){“logSizeMB” : 1383.3396482467651,”usedMB” : 154.49,”timeDiff” : 17015711,”timeDiffHours” : 4726.59,”tFirst” : “Thu Oct 18 2018 14:49:20 GMT+0800 (CST)”,”tLast” : “Fri May 03 2019 13:24:31 GMT+0800 (CST)”,”now” : “Fri Apr 26 2019 13:57:01 GMT+08免费主机域名00 (CST)”}shard2:PRIMARY> db.printReplicationInfo()configured oplog size: 1383.3396482467651MBlog length start to end: 17015711secs (4726.59hrs)oplog first event time: Thu Oct 18 2018 14:49:20 GMT+0800 (CST)oplog last event time: Fri May 03 2019 13:24:31 GMT+0800 (CST)now: Fri Apr 26 2019 15:46:27 GMT+0800 (CST)查看db.getReplicationInfo中，我们找出tLast和now两个时间是从哪里得到的？从以上可以看出:var ol = localdb.getCollection(oplog);var lastc = ol.find().sort({$natural: -1}).limit(1);var last = lastc.next();var tlast = last.ts;result.tLast = (new Date(tlast * 1000)).toString();result.now = Date();tLast
的时间是获取oplog.rs集合中最后一条数据的ts时间。Now
的时间是调用
Date()函数获取当前时间。于是，此时我怀疑副本集
无法同步，是因为oplog中存放比当前时间大的日志，而当调整时间后新生成的oplog日志记录并不是最新的，因此副本集在对比时发现最新的日志一直不变，便无法同步。大概说下mongodb同步的机制（借鉴网络）：1.执行写语句时，在primary上完成写操作2.在primary上记录一条oplog日志，日志中包含一个ts字段，值为写操作执行的时间，比如本例中记为t3.secondary从primary拉取oplog，获取到刚才那一次写操作的日志4.secondary按获取到的日志执行相应的写操作5.执行完成后，secondary再获取新的日志，其向primary上拉取oplog的条件为{ts:{$gt:t}}6.primary此时收到secondary的请求，了解到secondary在请求时间大于t的写操作日志，所以他知道操作在t之前的日志都已经成功执行了于是，我在primary执行一次插入测试，来验证怀疑。shard2:PRIMARY> use shtestswitched to db shtestshard2:PRIMARY> db.coll.insert( {x:3339876})WriteResult({ “nInserted” : 1 })查询主节点最后一条操作记录：rs.debug.getLastOpWritten()从以上可以看出:var ol = localdb.getCollection(oplog);var lastc = ol.find().sort({$natural: -1}).limit(1);var last = lastc.next();var tlast = last.ts;result.tLast = (new Date(tlast * 1000)).toString();result.now = Date();tLast
的时间是获取oplog.rs集合中最后一条数据的ts时间。Now
的时间是调用
Date()函数获取当前时间。于是，此时我怀疑副本集
无法同步，是因为oplog中存放比当前时间大的日志，而当调整时间后新生成的oplog日志记录并不是最新的，因此副本集在对比时发现最新的日志一直不变，便无法同步。大概说下mongodb同步的机制（借鉴网络）：1.执行写语句时，在primary上完成写操作2.在primary上记录一条oplog日志，日志中包含一个ts字段，值为写操作执行的时间，比如本例中记为t3.secondary从primary拉取oplog，获取到刚才那一次写操作的日志4.secondary按获取到的日志执行相应的写操作5.执行完成后，secondary再获取新的日志，其向primary上拉取oplog的条件为{ts:{$gt:t}}6.primary此时收到secondary的请求，了解到secondary在请求时间大于t的写操作日志，所以他知道操作在t之前的日志都已经成功执行了于是，我在primary执行一次插入测试，来验证怀疑。shard2:PRIMARY> use shtestswitched to db shtestshard2:PRIMARY> db.coll.insert( {x:3339876})WriteResult({ “nInserted” : 1 })查询主节点免费主机域名最后一条操作记录：rs.debug.getLastOpWritten()查询副本节点上的最后条操作记录：发现此时数据可以同步到副本集上，即说明oplog日志不存在不同步的问题，也就是实际上集群的同步是正常的。当时发现，每条oplog记录的ts
一直保持着调整主机时间前的时间，5月3日的时间，且一直不变。关于原因，就需要进一步分析了。看完了这篇文章，相信你对“MONGO集群修改linux主机时间后的影响有哪些”有了一定的了解，如果想了解更多相关知识，欢迎关注云技术行业资讯频道，感谢各位的阅读！

相关推荐: PostgreSQL中Failover的配置方法是什么

本篇内容介绍了“PostgreSQL中Failover的配置方法是什么”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！PostgreSQL 10+的libpq版本…