最近遇到一个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时，其过程类似如下
- 删除本地除local外的所有数据库
- 执行listDatabases命令，获取同步源上所有DB的列表
- 针对每个DB，调用listCollections获取所有集合信息，并遍历所有集合，同步集合内的文档并建立索引。
- ......
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
