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. 控制要复制的文档

有三个选项可用于控制哪些文档被复制,哪些文档被跳过:

  1. 将文档定义为本地文档。

  2. 使用 选择器对象 .

  3. 使用 过滤器功能 .

不会复制本地文档(请参见 本地(非复制)文档

选择器对象 可以包含在复制文档中(请参见 复制设置 ). 选择器对象包含用于测试是否应复制文档的查询表达式。

过滤器功能 可以在复制中使用(请参见 复制设置 ). 复制任务评估更改源中每个文档的筛选器功能。只有在筛选器返回时才会复制文档 true .

注解

与使用 过滤器功能 . 你应该用 选择器对象 在可能的情况下。

注解

使用依赖于文档内容的复制筛选器时,删除的文档可能会带来问题,因为传递给筛选器的文档将不包含文档的任何内容。可以通过添加 _deleted:true 字段,而不是使用DELETE HTTP方法,与 validate document update 处理程序,以确保复制筛选器所需的字段始终存在。不过,请注意,删除的文档仍将包含其所有数据(包括附件)!

2.1.6. 将数据迁移到客户端

复制对于使数据更接近客户端尤其有用。 PouchDB 在JavaScript中实现CouchDB的复制算法,使CouchDB数据库中的数据在脱机浏览器应用程序中可用,并将更改同步回CouchDB。