大量的集合为何导致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云服务。