注册 登录
  • 欢迎访问"运维那点事",推荐使用Google浏览器访问,可以扫码关注本站的"微信公众号"。
  • 如果您觉得本站对你有帮助,那么可以扫码捐助以帮助本站更好地发展。

MongoDB复制集同步慢问题分析

MongoDB 彭东稳 7848次浏览 已收录 0个评论

案例一

一、问题背景

最近生产环境出现多次Primary写入QPS太高,导致Seconary的同步无法跟上的问题(Secondary上的最新oplog时间戳比Primary上最旧oplog时间戳小),使得Secondary变成RECOVERING状态,这时需要人工介入处理,向Secondary发送resync命令,让Secondary重新全量同步一次。

二、同步过程

下图是MongoDB数据同步的流程:

MongoDB复制集同步慢问题分析

Primary上的写入会记录oplog,存储到一个固定大小的capped collection里,Secondary主动从Primary上拉取oplog并重放应用到自身,以保持数据与Primary节点上一致。

initial sync

新节点加入(或者主动向Secondary发送resync)时,Secondary会先进行一次initial sync,即全量同步,遍历Primary上的所有DB的所有集合,将数据拷贝到自身节点,然后读取『全量同步开始到结束时间段内』的oplog并重放。全量同步不是本文讨论的重点,将不作过多的介绍。

tailing oplog

全量同步结束后,Secondary就开始从结束时间点建立tailable cursor,不断的从同步源拉取oplog并重放应用到自身,这个过程并不是由一个线程来完成的,mongodb为了提升同步效率,将拉取oplog以及重放oplog分到了不同的线程来执行。

  • producer thread,这个线程不断的从同步源上拉取oplog,并加入到一个BlockQueue的队列里保存着,BlockQueue最大存储240MB的oplog数据,当超过这个阈值时,就必须等到oplog被replBatcher消费掉才能继续拉取。
  • replBatcher thread,这个线程负责逐个从producer thread的队列里取出oplog,并放到自己维护的队列里,这个队列最多允许5000个元素,并且元素总大小不超过512MB,当队列满了时,就需要等待oplogApplication消费掉。
  • oplogApplication会取出replBatch thread当前队列的所有元素,并将元素根据docId(如果存储引擎不支持文档锁,则根据集合名称)分散到不同的replWriter线程,replWriter线程将所有的oplog应用到自身;等待所有oplog都应用完毕,oplogApplication线程将所有的oplog顺序写入到local.oplog.rs集合。

producer的buffer和apply线程的统计信息都可以通过db.serverStatus().metrics.repl来查询到,在测试过程中,向Primary模拟约10000 qps的写入,观察Secondary上的同步,写入速率远小于Primary,大致只有3000左右的qps,同时观察到producer的buffer很快就达到饱和,可以判断出oplog重放的线程跟不上。

默认情况下,Secondary采用16个replWriter线程来重放oplog,可通过启动时设置replWriterThreadCount参数来定制线程数,当提升线程数到32时,同步的情况大大改观,主备写入的qps基本持平,主备上数据同步的延时控制在1s以内,进一步验证了上述结论。

三、改进思路

如果因Primary上的写入qps很高,经常出现Secondary同步无法追上的问题,可以考虑以下改进思路

附修改replWriterThreadCount参数的方法,具体应该调整到多少跟Primary上的写入负载如写入qps、平均文档大小等相关,并没有统一的值。

1.通过mongod命令行来指定

2.在配置文件中指定

案例二

前面介绍了因Primary上写入qps过大,导致Secondary节点的同步无法追上的问题,本文再分享一个case,因oplog的写入被放大,导致同步追不上的问题。

MongoDB用于同步的oplog具有一个重要的『幂等』特性,也就是说,一条oplog在备上重放多次,得到的结果跟重放一次结果是一样的,这个特性简化了同步的实现,Secondary不需要有专门的逻辑去保证一条oplog在备上『必须仅能重放』一次。

为了保证幂等性,记录oplog时,通常需要对写入的请求做一下转换,举个例子,某文档x字段当前值为100,用户向Primary发送一条{$inc: {x: 1}},记录oplog时会转化为一条{$set: {x: 101}的操作,才能保证幂等性。

一、幂等性的代价

简单元素的操作,$inc 转化为 $set并没有什么影响,执行开销上也差不多,但当遇到数组元素操作时,情况就不一样了。

当前文档内容:

在数组尾部push 2个元素,查看oplog发现$push操作被转换为了$set操作(设置数组指定位置的元素为某个值)。

$push转换为带具体位置的$set开销上也差不多,但接下来再看看往数组的头部添加2个元素。

可以发现,当向数组的头部添加元素时,oplog里的$set操作不再是设置数组某个位置的值(因为基本所有的元素位置都调整了),而是$set数组最终的结果,即整个数组的内容都要写入oplog。当push操作指定了$slice或者$sort参数时,oplog的记录方式也是一样的,会将整个数组的内容作为$set的参数。

$pull, $addToSet等更新操作符也是类似,更新数组后,oplog里会转换成$set数组的最终内容,才能保证幂等性。

二、案例分析

当数组非常大时,对数组的一个小更新,可能就需要把整个数组的内容记录到oplog里,我们遇到一个实际的生产环境案例,用户的文档内包含一个很大的数组字段,1000个元素总大小在64KB左右,这个数组里的元素按时间反序存储,新插入的元素会放到数组的最前面($position: 0),然后保留数组的前1000个元素($slice: 1000)。

上述场景导致,Primary上的每次往数组里插入一个新元素(请求大概几百字节),oplog里就要记录整个数组的内容,Secondary同步时会拉取oplog并重放,『Primary到Secondary同步oplog』的流量是『客户端到Primary网络流量』的上百倍,导致主备间网卡流量跑满,而且由于oplog的量太大,旧的内容很快被删除掉,最终导致Secondary追不上,转换为RECOVERING状态。

MongoDB对json的操作支持很强大,尤其是对数组的支持,但在文档里使用数组时,一定得注意上述问题,避免数组的更新导致同步开销被无限放大的问题。使用数组时,尽量注意

  1. 数组的元素个数不要太多,总的大小也不要太大。
  2. 尽量避免对数组进行更新操作。
  3. 如果一定要更新,尽量只在尾部插入元素,复杂的逻辑可以考虑在业务层面上来支持。

比如上述场景,有如下的改进思路

  1. 将数组的内容放到单独的集合存储,将数组的操作转化为对集合的操作(capped collection能很好的支持$slice的功能)。
  2. 如果一定要用数组,插入数组元素时,直接放到尾部,让记录就是按时间戳升序存储,在使用时反向遍历({$natural: -1})取最新的元素。保持最近1000条的功能,则可在业务逻辑里实现掉,比如增加后台任务来检测,当数组元素超过某个阈值如2000时,就将数组截断到1000条。

三、改进思路

为了尽量避免出现Secondary追不上的场景,需要注意以下几点

  1. 保证Primary节点有充足的服务能力,如果用户的请求就能把Primary的资源跑得很满,那么势必会影响到主备同步。
  2. 合理配置oplog的大小,可以结合写入的情况,预估下oplog的大小,比如oplog能存储一天的写入量,这样即使备同步慢、故障、或者临时下线维护等,只要不超过1天,恢复后还是有希望继续同步的。
  3. 尽量避免复杂的数组更新操作,尽量避免慢更新(比如更新的查询条件需要遍历整个集合)

转摘:阿里云数据库组技术专家张友东博客

https://yq.aliyun.com/articles/57755?spm=5176.8091938.0.0.Opu19P

https://yq.aliyun.com/articles/52404?spm=5176.100239.blogcont57755.12.xZgM4j


如果您觉得本站对你有帮助,那么可以支付宝扫码捐助以帮助本站更好地发展,在此谢过。
喜欢 (1)or分享 (0)
关于作者:

您必须 登录 才能发表评论!