MongoDB Secondary同步慢问题分析-阿里云开发者社区

开发者社区> 张友东(林青)> 正文

MongoDB Secondary同步慢问题分析

简介: MongoDB Scondary同步慢问题分析 问题背景 最近生产环境出现多次Primary写入QPS太高,导致Seconary的同步无法跟上的问题(Secondary上的最新oplog时间戳比Primary上最旧oplog时间戳小),使得Secondary变成RECOVERING状态,这时需要
+关注继续查看

MongoDB Scondary同步慢问题分析

问题背景

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

同步过程

下图是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命令行来指定

    mongod --setParameter replWriterThreadCount=32

  2. 在配置文件中指定

        setParameter:
      replWriterThreadCount: 32
    

参考资料

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
数据同步框架MS Sync Framework-不同场景使用例子和简要分析
上一篇http://www.cnblogs.com/2018/archive/2011/02/22/1961654.html 对这个框架一个总体介绍,这篇通过SDK内带的例子和一个综合的例子描述一下这个框架的使用 [例子基于SDK2.
838 0
将数据从服务器端同步到手机上, 并且需要离线工作,Couchebase Mobile 也许是目前最好的解决方案:
将数据从服务器端同步到手机上, 并且需要离线工作,Couchebase Mobile 也许是目前最好的解决方案: 原文地址: https://www.infinum.co/the-capsized-eight/articles/server-client-syncing-for-mobile-a...
1367 0
【巡检问题分析与最佳实践】RDS MySQL 实例IO高问题
RDS MySQL的IO性能受到硬件层存储介质类型、软件层的DB内核架构、具体SQL语句扫描或修改数据量的影响。
345 0
logstash-output-mongodb实现Mysql到Mongodb数据同步
本文主要讲解如何通过logstash-output-mongodb插件实现Mysql与Mongodb数据的同步。源数据存储在Mysql,目标数据库为非关系型数据库Mongodb。
13 0
DLA支持分析MongoDB/RDS只读实例
在对Mysql,MongoDB等数据库系统进行分析时,经常面临的一个问题是在进行分析查询时如何避免对实时业务产生影响,也就是OLAP负载和OLTP负载隔离的问题。针对这个问题,阿里云数据湖团队一直在努力优化,提供满足不同场景的解决方案。
902 0
Java面向对象基础--类的设计及分析问题的方法---用户登录例子
<h1>1、用户登录的示例</h1> <div>首先要做的就是先把功能实现:</div> <div> <pre name="code" class="java">public class LoginDemo01{ public static void main(String args[]){ if(args.length!=2){ // 应该判断输入的参数个数是否是2
1090 0
【巡检问题分析与最佳实践】MongoDB 空间使用问题
阿里云数据库MongoDB的空间使用率是一个非常重要的监控指标,如果实例的存储空间完全打满,将会直接导致实例不可用。一般来说,当一个MongoDB实例的存储空间使用比例达到80-85%以上时,就应及时进行处理,要么降低数据库实际占用空间的大小,要么对存储空间进行扩容,以避免空间打满的风险。 然而,阿里云数据库MongoDB的空间使用情况分析并不简单,本文将由浅入深帮您查看,分析和优化云数据库MongoDB的空间使用。
238 0
今天遇到的问题分析
今天挑战自己,去认证公司的java技术开发规范,期间遇到的问题做个总结。
506 0
蚂蚁金服服务注册中心数据分片和同步方案详解 | SOFARegistry 解析
本文为《剖析 | SOFARegistry 框架》第四篇,本篇作者明不二。本篇将讲述在海量服务注册场景下,为保障 DataServer 能否无限扩容面对海量数据的业务场景,SOFARegistry 是如何进行数据分片,保障了数据的可扩展性~
650 0
+关注
张友东(林青)
阿里云高级技术专家
105
文章
18
问答
来源圈子
更多
阿里云数据库:帮用户承担一切数据库风险,给您何止是安心!支持关系型数据库:MySQL、SQL Server、PostgreSQL、PPAS(完美兼容Oracle)、自研PB级数据存储的分布式数据库Petadata、自研金融级云数据库OceanBase支持NoSQL数据库:MongoDB、Redis、Memcache更有褚霸、丁奇、德哥、彭立勋、玄惭、叶翔等顶尖数据库专家服务。
+ 订阅
文章排行榜
最热
最新
相关电子书
更多
《2021云上架构与运维峰会演讲合集》
立即下载
《零基础CSS入门教程》
立即下载
《零基础HTML入门教程》
立即下载