关于配置的若干疑问（所有打算使用的人都很关心~）

[shiftyman]

1.context.storage.url这个配置，注释写如果shard类型，要配置到config server，这个是不是有问题？config server貌似是不允许写入的，应该配置到mongos或者某个mongod吧？

• if source database is replica, context will store in the source mongodb.
• if source database is sharding, context must be given to point the config server address.
• context.storage.url is only used in sharding. When source mongodb type is replicaSet,
• checkpoint will write into source mongodb as default. context.storage = database *context.storage.url = mongodb://127.0.0.1:20070

2.syncer.reader.buffer_time 这个时间是指syncer往worker发送数据的时间间隔？syncer抓取到oplog先缓存一定时间再一批发送到worker？

3.worker和worker.batch_queue_size 测试过程中发现，worker在shard模式需要和shard数量保持一致，为什么呢？？ worker.batch_queue_size 这个参数的意义是什么？调整它会有什么影响？

4.system_profile何用？ http_profile是获取统计信息和配置的restful端口，但是system_profile是干什么的呢？

5.checkpoint.interval 这个是指checkpoint持久化的时间间隔吧？注释写的batch_size是什么意思？

• save checkpoint every ${batch_size}. reduce the number
• of batch_size will saving the checkpoint with higher frequency
• default size is 16 * 1024 checkpoint.interval = 5000

6.log_file能否用绝对路径？

[vinllen]

1. 这个只是标识存储checkpoint的位置，甚至可以是一个无关的mongodb。
2. syncer为了保证发送的qps，有缓存机制，这个时间是强制刷缓存进行发送。
3. 对于sharding来说，是一个worker绑定一个shard，此处是程序设计考虑，本身shard模式下并发度已经较高，在并发度高的情况下，再一个shard对应多个work并发不是有特别强的必要。 batch_queue_size是内部发送队列长度，调整大小会影响内存的使用率以及发送的效率。
4. 这个是用于做go pprof调试的，比如查看cpu，内存，堆栈信息
5. 这里注释写的有点问题，忽略，我之后改改
6. 这个你可以试试，我有点忘了，默认应该是相对的

[shiftyman]

第二点，是指syncer会先缓存oplog，等到达到一定的数量，再发送给worker，如果没达到，等到syncer.reader.buffer_time这个时间间隔，也会发送给worker，是这样理解吗？

[shiftyman]

再补充几个配置问题： 1.replayer.executor 每个worker对应的executor数量，worker不是并发的最小粒度了吗？为何一个worker中的任务又可以再并发执行呢，不会搞乱时序？

2.tunnel.address 这个目标地址，如果是mongos，可以填多个做HA吗？多个mongos应该怎么填写，可否给出例子？

3.collector.id 这个id，有什么实际用途没有？

[vinllen]

关于syncer.reader.buffer_time，你的理解正确 补充问题：

1. executor的具体含义请参考文档，在目前开源版本，这个字段可以忽略，默认1就可以
2. 多个mongos会roundrobin写入
3. 如果启动多个，相同路径下相同id不能相同

[shiftyman]

对于mongos，是用逗号分隔？例如，20040和20041是两个mongos，是这样配置吗：

mongodb://username:password@127.0.0.1:20040,127.0.0.1:20041

[vinllen]

封号;

[shiftyman]

mongodb://username:password@127.0.0.1:20040;127.0.0.1:20041

or

mongodb://username:password@127.0.0.1:20040;mongodb://username:password@127.0.0.1:20041

?

[vinllen]

第二个

[shiftyman]

context.storage.url用第二个不可以，因为定义的变量是string不是数组，只能写一个。

另外： tunnel.address和context.storage.url，我用 mongodb://username:password@127.0.0.1:20040,127.0.0.1:20041 这种配置也是可以正常使用的哦，会有什么问题不？？

[shiftyman]

亲测，多mongos的场景。

1.目标address配置用mongodb://username:password@127.0.0.1:20040,127.0.0.1:20041 能达到高可用的目的！！

2.目标配置mongodb://username:password@127.0.0.1:20040;mongodb://username:password@127.0.0.1:20041

只会看20041这个是不是挂了，20040没有什么作用，20041挂了就不可用了~~~

[vinllen]

对于context.storage.url，是mongodb://username:password@127.0.0.1:20040,127.0.0.1:20041这种模式，连接的时候连接串中一个挂了应该会触发另外一个连接。对于tunnel.address，一般分号分割不同shard，同一个shard内的不同实例用逗号分割，逗号分割是做高可用，但不能做负载均衡。

[shiftyman]

分片集群，tunnel.address不是配置的mongos吗？

对于20040和20041两个mongos： mongodb://username:password@127.0.0.1:20040;mongodb://username:password@127.0.0.1:20041 只会看20041这个是不是挂了，20040没有什么作用，20041挂了就不可用了~~~

然后测试配置为： mongodb://username:password@127.0.0.1:20040,127.0.0.1:20041 是可行的~

[vinllen]

这块理论上封号分隔是会做负载均衡的，我完了看一下

[vinllen]

这个是会做roundrobin的负载均衡，具体请查看direct_writer代码，不同的worker id会分配不同的目的端进行写入

[shiftyman]

不是说executor开源版本只能填1吗?

而且，这种方式亲测达到了高可用的需求： tunnel.address=mongodb://username:password@127.0.0.1:20040,127.0.0.1:20041

这么配置会有坑吗？

[vinllen]

1. 开源版本是只有1
2. 这样配置是可以的