2.1. 复制简介¶
CouchDB的优势之一是能够同步同一数据库的两个副本。这使用户能够跨多个节点或数据中心分发数据，同时也可以将数据更紧密地移动到客户端。
复制涉及一个源数据库和一个目标数据库，这两个数据库可以在同一个CouchDB实例上，也可以在不同的CouchDB实例上。复制的目的是在过程结束时，源数据库中的所有活动文档也将位于目标数据库中，而在源数据库中删除的所有文档也将在目标数据库中删除（如果它们甚至存在）。
2.1.1. 瞬时和持久复制¶
有两种不同的方法来设置复制。CouchDB中引入的第一个复制导致一个可以调用的复制 transient. Transient means that there are no documents backing up the replication. So after a restart of the CouchDB server the replication will disappear. Later, the _ 引入了replicator<replicator>`数据库，它保存包含复制参数的文档。这样的复制可以称为 `persistent . 为了向后兼容，保留了临时复制。两个复制可以有不同的 replication states .
2.1.2. 触发、停止和监视复制¶
持久性复制是通过 _replicator 数据库，其中每个文档描述一个复制过程（请参阅 复制设置 ). 用于设置临时复制的api端点 /_replicate 可以使用。通过将JSON对象发送到 _replicate 或将其作为文档存储到 _replicator 数据库。
如果复制当前正在运行，则可以通过活动任务API检查其状态（请参阅 /_active_tasks ， 复制状态 和 /_scheduler/jobs ）
对于基于文档的复制， /_scheduler/docs 可用于获取完整的状态摘要。首选此API，因为它将在复制文档成为复制作业之前显示其状态。
对于临时复制，无法在作业完成时查询其状态。
可以通过删除文档或使用其更新文档来停止复制 cancel 属性设置为 true 。
2.1.3. 复制过程¶
在复制期间，CouchDB将比较源数据库和目标数据库，以确定源数据库和目标数据库之间哪些文档不同。它通过遵循 更改订阅源 并将文档与目标进行比较。更改将成批提交到目标，在那里它们可能会引入冲突。目标上已存在的同一版本的文档不会被传输。由于文档的删除由新修订表示，在源上删除的文档也将在目标上删除。
复制任务在到达更改馈送的末尾后将完成。如果它的 continuous 属性设置为true，它将等待新的更改出现，直到任务取消。复制任务还会在目标上创建检查点文档，以确保重新启动的任务可以从它停止的位置继续，例如在它崩溃之后。
在发送节点上启动复制任务时，将调用该任务 push 复制，如果它是由接收节点启动的，则调用 pull 复制。
2.1.4. 主-主复制¶
一个复制任务将只向一个方向传输更改。为了实现主-主复制，可以设置两个相反方向的复制任务。当第一个任务将更改从数据库a复制到B时，从B到a的第二个任务将发现B上的新更改已存在于a中，并将等待进一步的更改。
2.1.5. 控制要复制的文档¶
有三个选项可用于控制哪些文档被复制，哪些文档被跳过：
不会复制本地文档（请参见 本地（非复制）文档 ）
选择器对象 可以包含在复制文档中（请参见 复制设置 ). 选择器对象包含用于测试是否应复制文档的查询表达式。
过滤器功能 可以在复制中使用(请参见 复制设置 )。复制任务评估更改提要中每个文档的过滤函数。仅当过滤返回时才会复制文档 true 。
注解
使用依赖于文档内容的复制筛选器时，删除的文档可能会带来问题，因为传递给筛选器的文档将不包含文档的任何内容。可以通过添加 _deleted:true 字段，而不是使用DELETE HTTP方法，与 validate document update 处理程序，以确保复制筛选器所需的字段始终存在。不过，请注意，删除的文档仍将包含其所有数据（包括附件）！