下面是我在CouchDB邮件列表中得到的回复：
如果我们讨论的是治疗床1.6，则属性 retries_per_request 控制当前复制在放弃前对read _changes feed进行的尝试次数。属性 max_replication_retry_count 控制复制管理器对整个复制作业进行的尝试次数。将此属性设置为“infinity”应使复制管理器永不给予。
我不认为这些尝试之间的间隔是可配置的。据我所知，它将从2.5秒开始重试，然后加倍，直到达到10分钟，这将是硬上限。
扩展回答：
根据您使用的是1.x/2.0版本还是当前的master版本，答案会略有不同。
如果您使用的是1.x或2.0版本：设置“max_replication_retry_count = infinity”，以便始终重试失败的复制。该设置控制在出现任何错误时如何重新启动整个复制作业。然后，“retries_per_request”可用于处理单个复制器HTTP请求的错误。基本上，在快速立即重试成功的情况下。“retries_per_request”的默认值为10。第一次失败后，等待时间为0.25秒。2下一次失败时，等待时间加倍为0.5秒，依此类推。3最大等待时间间隔为5分钟。4但是如果你希望经常脱机，可能不值得重试单个请求太长时间，因此将“retries_per_request”减少到6或7。因此单个请求将重试几次，每次重试时间大约为10 - 20秒，则整个复制作业将崩溃并重试。
如果您使用的是当前母版，它具有新的计划复制器：不需要设置“max_replication_retry_count”，该设置已消失，只要复制文档存在，所有复制作业将始终重试。但“retries_per_request”的工作原理与上述相同。当复制作业连续失败时，复制调度程序也会执行指数回退。第一次回退为30秒。然后加倍为1分钟，2分钟，等等。最大回退等待时间约为8小时。但如果您不希望在网络连接恢复时平均等待4小时以重新启动复制，而希望等待时间约为5分钟左右，在“replicator”配置部分中设置“max_history = 8”。max_history控制为每个复制作业保留多少过去事件的历史记录。如果连续崩溃的历史记录较少，则退避等待间隔也将更短。
因此，对于1.x/2.0版本，总结如下：
[复制器]最大复制重试计数=无限次每次请求重试次数= 6
对于当前主控形状：
[复制器]最大历史记录数= 8每次请求重试次数= 6