大量的集合为何导致Secondary无法同步?

最近遇到一个user case,因为集合数量太多,导致Secondary节点无法进行initial sync(主备同步的第一步,可理解为从Primary上全量拷贝数据)。

副本集使用wiredtiger存储引擎,一共60,000+集合,平均每个集合4个索引,wiredtiger的集合及每个索引都对应一个单独的文件来存储,数据目录下总共300,000+文件,listDatabases命令执行时,会遍历所有DB的每个集合,获取集合及其索引文件占用的存储空间信息,实现类似如下的伪代码。

listDatabases() {
    dbNames = getAllDatabaseNames();
    for db in dbNames {
        sizeOnDisk = 0;
        for coll in db.getAllColletions() {
                size += coll.size();
                for index in coll.getAllIndexes() {
                    size += index.size();
                }    
        }
        addToOutput(db, size);
    }      
}

使用wiredtiger引擎时,获取集合及索引文件大小信息时,需要打开一个特殊的cursor来读取,整个listDatabases需要遍历300,000+个文件来逐个获取大小信息,导致整个命令的执行开销很大,总耗时在30s以上。

Secondary在执行initial sync时,其过程类似如下

  1. 删除本地除local外的所有数据库
  2. 执行listDatabases命令,获取同步源上所有DB的列表
  3. 针对每个DB,调用listCollections获取所有集合信息,并遍历所有集合,同步集合内的文档并建立索引。
  4. ……

initial sync执行时,设置了socket timeout为30s,而listDatabases的执行时间是超过30s的,导致同步在listDatabases时就一直超时失败,10次重试后仍然失败,Secondary进程就直接退出了。

2016-06-27T20:59:46.494+0800 I REPL     [rsSync] ******
2016-06-27T20:59:46.495+0800 I REPL     [rsSync] initial sync pending
2016-06-27T20:59:46.499+0800 I REPL     [rsSync] no valid sync sources found in current replset to do an initial sync
2016-06-27T20:59:47.499+0800 I REPL     [rsSync] initial sync pending
2016-06-27T20:59:47.517+0800 I REPL     [rsSync] initial sync drop all databases
2016-06-27T20:59:47.517+0800 I STORAGE  [rsSync] dropAllDatabasesExceptLocal 1
2016-06-27T20:59:47.517+0800 I REPL     [rsSync] initial sync clone all databases
2016-06-27T21:00:17.517+0800 I NETWORK  [rsSync] Socket recv() timeout  10.182.4.106:27017
2016-06-27T21:00:17.517+0800 I NETWORK  [rsSync] SocketException: remote: (NONE):0 error: 9001 socket exception [RECV_TIMEOUT] server [10.1.1.6:27017] 
2016-06-27T21:00:17.519+0800 E REPL     [rsSync] 6 network error while attempting to run command 'listDatabases' on host '10.1.1.6:27017' 
2016-06-27T21:00:17.519+0800 E REPL     [rsSync] initial sync attempt failed, 9 attempts remaining

问题已反馈给官方团队,详情见SERVER-24948,在3.4版本里会去掉socket timeout来解决这个问题。

实际上,同步过程中listDatabases只需要获取所有DB的名称即可,并不需要size信息,所以我们的想法是给listDatabases命令加一个 {nameOnly: true}的选项,让命令只返回所有DB的名称信息,这样整个开销会很小,SERVER-3181也遇到类似问题,提了相同的解决思路,我们会在MongoDB云数据库里加上这个选项用于主备同步,github pull request

使用MongoDB时,建议用户还是合理的控制下集合数量(集合数量太多,很可能存储设计上也有问题,得好好review下),集合数量一旦大了,有可能面临各种问题,就如同上述的场景listDatabases耗时长,想监控数据库的容量使用情况都难。

上述问题其他的解决方案

  • Primary(同步源)上使用mmapv1引擎,内存足够的情况下,listDatabases的开销要更小些。
  • Secondary同步时不设置或设置更长的socket超时时间
  • 加新节点上,将Primary的数据拷贝到新的节点,跳过initial sync

作者简介

张友东,阿里巴巴技术专家,主要关注分布式存储、Nosql数据库等技术领域,先后参与TFS(淘宝分布式文件系统)Redis云数据库等项目,目前主要从事MongoDB云数据库的研发工作,致力于让开发者用上最好的MongoDB云服务。

发表评论