修改Linux主机时间对MONGO集群有什么影响？

生产环境是3分片集群，一主一从一仲裁。现在发现其中一个节点比当前时间早了几天，然后使用NTP将时间调整回副本集。

原时间为5月3日，当前日期为4月26日，已调整。

[root@cwdtest1 bin]# 日期

2023 年 CST 5 月 3 日星期五 13:20:31

[root@cwdtest1 bin]# ntpdate -u 10.205 .34.171

4月26日12:39:23 ntpdate[14568]：步骤时间服务器10.205.34.171偏移-607507.747595秒

[root@cwdtest1 bin]# hw --systohc<时钟 /p>

调整后的当前时间：

[root@cwdtest1 bin]# date

Fri Apr 26 12:39:31 CST 2023

1．回复ca set 无法同步新的oplog，导致延迟

shard2:PRIMARY> db.printSlaveReplicationInfo() ;

source: 10.3.252.231:27002

同步至：2023 年 5 月 3 日星期五 13:24:23 GMT+0800 (CST)

比主数据库晚 8 秒（0 小时）

2。 oplog tLast 时间大于当前时间

shard2:PRIMARY> db.getReplicationInfo()

{

"logSizeMB" : 1383.3396482467651,< /p>

“usedMB”：154.49，

“timeDiff”：17015711，

“timeDiffHours”：4726.59，

“tFirst”：“ 2023 年 10 月 18 日星期四 14:49:20 GMT+0800 (CST)",

"tLast" : "2023 年 5 月 3 日星期五 13:24:31 GMT+0800 (CST)",

“现在”：“2023 年 4 月 26 日星期五 13:57:01 GMT+0800 (CST)”

}

shard2:PRIMARY> db.printReplicationInfo()

配置的oplog大小：1383.3396482467651MB

日志长度开始到结束：17015711秒（4726.59小时）

oplog第一次事件时间：2023年10月18日星期四14:49:20 GMT+0800 (CST)

oplog 最后活动时间：2023 年 5 月 3 日星期五 13:24:31 GMT+0800 (CST)

现在：4 月 26 日星期五 2023 15:46:27 GMT+0800 (CST)

查看 db.getReplicationInfo，我们可以找到两次 tLast 和 now 的获取位置。 ?

shard2:PRIMARY> db.getReplicationInfofunction () { var localdb = this.getSiblingDB("local"); var 结果 = {}; var 操作日志； var localCollections = localdb.getCollectionNames(); if (localCollections.indexOf('oplog.rs') >= 0) { oplog = 'oplog .rs'; } else if (localCollections.indexOf('oplog.$main') >= 0) { oplog = 'oplog.$main'; } else { result.errmsg = "未检测到主/从或副本集复制";返回结果； var ol = localdb.getCollection(oplog); var ol_stats = ol.stats(); if (ol_stats && ol_stats.maxSize) { result.logSizeMB = ol_stats.maxSize / (1024 * 1024); } else {        result.errmsg =“无法获取本地统计信息。” + oplog + " 集合。" +       "collstats 返回：" + tojson(ol_stats);返回结果； result.usedMB = ol_stats.size / (1024 * 1024); result.usedMB = Math.ceil(result.usedMB * 100) / 100;首先是变量c = ol.find().sort({$natural: 1}).limit(1); var lastc = ol.find().sort({$natural: -1}).limit(1); if (!firstc.hasNext() || !lastc.hasNext()) { result.errmsg =   “在 local.oplog.$main 中找不到对象 - 这是一个新的空数据库实例吗？”;结果.oplogMainRowCount = ol.count();返回结果； } varfirst =firstc.next(); var 最后 = lastc.next(); var tfirst =first.ts; var tlast = 最后.ts; if (tfirst && tlast) {tfirst = DB.tsToSeconds(tfirst); tlast = DB.tsToSeconds(tlast);结果.timeDiff = tlast - tfirst;结果.timeDiffHours = Math.round(结果.timeDiff / 36) / 100; result.tFirst = (new Date (tfirst * 1000)).toString(); result.tLast = (new Date(tlast * 1000)).toString();结果.now = 日期(); } else { result .errmsg= "在 oplog 对象中找不到 ts 元素";返回结果； }

从上面可以看出：

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字段，其值为执行写操作的时间。例如，在这个例子中，它是rec排序为 t

3。 secondary从primary拉取oplog，获取刚才写操作的日志

4. secondary根据获取到的日志执行相应的写操作

5.执行完成后，Secondary再次获取新的日志，从Primary拉取oplog的条件是{ts:{$gt:t}}

6。此时Primary收到Secondary的请求，得知Secondary的请求时间大于t写入操作日志，因此知道t之前日志中的操作已经成功执行

因此，我对主设备进行了插入测试以验证怀疑。

shard2:PRIMARY> 使用shtest

切换到db shtest

shard2: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中最后一条数据的ts时间.rs集合。

Now的时间就是调用Date()函数获取当前时间。

是的，我怀疑此时副本集无法同步，因为oplog存储的日志大于当前时间，而调整时间后新生成的oplog日志记录不是最新的。因此，在比较副本集的时候，发现最新的日志一直保持不变，那么就不会被同步。

从广义上讲，mongodb同步的机制（借鉴网络）：

1.执行写语句时，写操作在primary上完成

2.在primary日志上记录了一条oplog日志。日志中包含一个ts字段，其值为执行写操作的时间。例如本例记为t

3。 secondary从primary拉取oplog，获取刚才的写操作。操作日志

4. secondary根据获取到的日志执行相应的写操作

5.执行完成后，Secondary获取新日志，并从Primary拉取oplog。条件是{ts:{$gt:t}}

6。此时Primary收到Secondary的请求，得知Secondary有一条写操作日志，其中请求时间大于t，因此知道该操作在t之前的日志已经成功执行

因此，我在主数据库上执行了插入测试以验证怀疑。

shard2:PRIMARY> 使用shtest

切换到db shtest

shard2:PRIMARY> db.coll.insert({x:3339876})

WriteResult({ "nInserted" : 1 })

查询主节点最后一次操作记录：

rs.debug.getLastOpWritten( )

查询副本节点最近一次操作记录：

发现数据可以同步到此时的replica set，说明oplog日志并没有失同步。问题是集群的同步其实是正常的。

当时发现，每个oplog中记录的ts一直保持主机时间调整前的时间，5月3日的时间，一直保持不变。其中原因还需要进一步分析。

读完这篇文章，相信您对“修改MONGO集群中Linux主机时间有什么影响”有了一定的了解。如果您想了解更多相关知识，请关注行业资讯频道，感谢您的阅读！