这是一个创建于 234 天前的主题，其中的信息可能已经有所发展或是发生改变。
使用腾讯云的云数据库, 一主两从 三个副本集,MongoDB 3.2 版本, 配置 2 核 4G, 用户数据 2000 条左右, 更新单个用户的数据后, 过了 2 秒左右查询操作 使用 read('secondPrefered'), read('nearest') 查到的数据大概率是 2 秒前未更新的状态.
虽然可以通过逻辑去区分读主读从, 但是业务写起来就相当的费劲了.
有使用过的朋友吗, 怎么能做到数据同步延时在 50ms-100ms 内?
4 条回复
 |
1
sunny352787 234 天前
这事你得给他们提工单了吧，这延迟肯定不对劲
|
 |
2
tencentcloud 234 天前
您好，当在副本集情况下，向节点写入数据，并记录 oplog. 从节点通过 oplog 进行数据同步，最终保证副本集中的各个节点的数据一致性，这个默认是异步同步，因此会有一定延迟。一般的主从延迟是在毫秒级别，如果出现延迟较大的情况，可以根据下面的排查思路进行分析：
1 、如果实例只是偶尔出现延迟，可以查看对应时间点实例的指标是否正常、例如 CPU 、网络流量指标等是否有跑高，主节点负载高就会导致从节点通过主节点 oplog 获取增量数据有延迟，最终反应出来落到从节点就会出现延迟。 2 、排查延迟过程，实例是否在备份过程，早期 3.2 版本没有专门设置 hidden 节点，备份过程会导致从节点负载上升，从而影响数据回放，这个建议升级到更高的实例版本，并设置 hidden 节点避免备份影响。 3 、业务是否存在大批量的写入逻辑，可以查看对应主从延迟的时间点是否是业务高峰期，从节点回放数据是有效线程回放，如果写入太大，是会导致延迟上升，这个时候建议升级更大的实例规格。 4 、如果业务自身在没有写入，或者写入很少的情况下，监控偶尔看到出现延迟毛刺，这个是由于监控拨测机制和原生的计算机制引入的，mongodb 副本集中每个节点会记录 optime ，即最后一次修改数据库操作发生的时间，延时的计算为主节点与备节点之间 optime 的差导致。 如出现非上述情况，需要根据实际情况进行分析，建议您可以提交腾讯云工单进行反馈，我们会协助您分析解决，感谢您对腾讯云支持与理解。 |
 |
3
88JackLi88 OP @sunny352787 已提工单, 配合他们跑了几次测试用例, 服务端代码 find().read('secondary') 查询, 总是在第 3 秒的时候 次才看到同步完数据. 他们那边却看不到延迟, 着实有点无语了.
也有可能是数据库版本太低了, 后面可能会考虑升级版本再看是否有这个情况 |
|
4
88JackLi88 OP @tencentcloud 已提工单, 感谢支持.
|
Select Language