我正在将数据从一个Cloudant实例移动到另一个实例。作为移动数据的好方法，我创建了用于连续复制的复制文档。他们中的大多数都复制了所有文档（正如我没有使用任何过滤器那样预期），但有些文档会跳过几个文档。
有问题的2个数据库都只存储新文档（没有更新，没有删除）。在调查较大的db（> 30 Mio docs）之后，我注意到仅跳过在特定日期之后创建的文档。自此日期以来的大多数日子都错过了大约1/3的创建文档。 偶尔我注意到复制文档中的错误通常会很快消失，并且状态会切换回“触发”。
worker_died错误消息报告为{[{<<"error">>,<<"too_large">>}, {<<"reason">>,<<"the request entity is too large">>}]}。
源数据库没有问题的迹象。
如何解决此问题？
答案 0 :(得分：1)
听起来您正在从旧的，专用的或计量的Cloudant帐户复制到IBM Bluemix Public上的较新实例。在较旧的实例上，最大请求大小为64M，而在较新的实例上，此限制减少到1M。这种差异可能是问题所在。
在复制期间，文档在写入源时进行批处理。如果您的文档本身小于1M，则应该能够调整批量大小以便在1M请求限制大小下进行挤压。批量大小默认为500，但可以使用messageTestMapper参数更改;见
如果你的某些文件大于1M，那么你就不幸了。
答案 1 :(得分：0)
谢谢，xpqz，你带领我朝着正确的方向前进。 单独减少worker_batch_size并没有解决问题，因为我们有一些大于1MB的文档。 添加另一个过滤器以跳过所有大于1MB的文档后，所有较小的文档都被复制。 不幸的是，Cloudant不会跳过更大的文档并继续前进，但它会重复一遍又一遍地复制相同的大文档，以便之后的所有文档都不会被复制。
使用尺寸过滤器创建dd：
“filters”：{“doc_size”：“function（doc，req）{\ r \ n if（JSON.stringify（doc）.length＆gt; 1048575）{\ r \ n return false; \ r \ n } \ r \ n返回true; \ r \ n}“}
将过滤器添加到复制文档：
“过滤器”：“/ doc_size”，