什么是CouchDB复制协议？是不是像Git？

Question

是否有技术文档描述两个Couches之间的复制是如何工作的？

CouchDB复制的基本概述是什么？关于它的一些值得注意的特征是什么？

Answer 1

遗憾的是，没有详细的文档描述复制协议。 CouchDB中只有参考实现，Filipe Manana对其进行了重写，可能会成为未来的新实现。

然而，这是一般的想法：

要点

如果您了解Git，那么您就知道Couch复制是如何工作的。复制非常类似于推送或拉动像Git这样的分布式源管理器。

CouchDB复制没有自己的协议。复制器只是作为客户端连接到两个DB，然后从一个读取并写入另一个。推送复制是读取本地数据并更新远程数据库;拉复制反之亦然。

• 有趣的事实1 ：复制器实际上是一个独立的Erlang应用程序，在它自己的进程中。它连接到两个沙发，然后从一个读取记录并将它们写入另一个。
• 有趣的事实2 ：CouchDB 无法知道谁是普通客户端，谁是复制者（更不用说复制是推还是拉）。这看起来像客户端连接。其中一些人读了记录。他们中的一些人写了记录。

一切都来自数据模型

复制算法很简单，无趣。受过训练的猴子可以设计它。它很简单，因为聪明才是数据模型，它具有以下有用的特性：

1. CouchDB中的每条记录都完全独立于其他记录。如果你想做一个JOIN或一个事务，这很糟糕，但如果你想写一个复制器，这很棒。只需弄清楚如何复制一个记录，然后为每条记录重复。
2. 与Git一样，记录具有链表修订历史记录。记录的修订ID是其自身数据的校验和。后续修订ID是以下校验和：新数据加上前一个的修订ID。

3. 除了应用程序数据（{"name": "Jason", "awesome": true}）之外，每条记录都存储了所有先前修订版ID的进化时间轴。

   • 练习：花一点时间静静思考。考虑任何两个不同的记录，A和B.如果A的修订ID出现在B的时间轴中，那么B肯定是从A演变而来。现在考虑Git的快进合并。你听到了吗？这就是你的思绪被吹散的声音。

4. Git实际上不是一个线性列表。当一方父母有多个孩子时，它有分叉。 CouchDB也有。

   • 练习：比较两个不同的记录，A和B. A的修订ID不会出现在B的时间轴中;但是，一个修订版ID C在 A和B的时间轴中。因此A不是从B.进化而来的.B不是从A演化而来的。而是，A和B有一个共同的祖先C.在Git中，这是一个“分叉”。在CouchDB中，这是一个“冲突”。

   • 在Git中，如果两个孩子继续独立开发时间表，那很酷。福克斯完全支持这一点。

   • 在CouchDB中，如果两个孩子继续独立开发时间表，那也很酷。冲突完全支持这一点。
   • 有趣的事实3： CouchDB“冲突”与Git“冲突”不对应。 Couch冲突是一个不同的修订历史，Git称之为“分叉”。出于这个原因，CouchDB社区发布了与“无声 n ”的“冲突”：“共同点击。”

5. 当一个孩子有多个父母时，Git也有合并。 CouchDB 那种也有。

   • 在数据模型中，没有合并。客户端只是将一个时间轴标记为已删除，并继续使用唯一存在的时间轴。
   • 在应用程序中，感觉就像是合并。通常，客户端以特定于应用程序的方式合并来自每个时间轴的数据。然后它将新的数据写入时间线。在Git中，这就像复制并粘贴从分支A到分支B的更改，然后提交到分支B并删除分支A. 数据已合并，但没有git merge。
   • 这些行为是不同的，因为在Git中，时间轴本身很重要;但是在CouchDB中，数据非常重要，而且时间轴是偶然的 - 它只是支持复制。这就是为什么CouchDB的内置修订不适合存储维基页面等修订数据的原因之一。

最后的笔记

本文中至少有一个句子（可能是这个）是完整的BS。

Answer 2

感谢Jason的出色概述！正在研究TouchDB及其Couchbase复制的Jens Alfke如果您对“标准”CouchDB复制器协议如何工作的技术细节感兴趣，则（非正式地）描述the CouchDB replication algorithm本身。

总结他概述的步骤：

1. 弄清楚之前复制的程度
2. 从那时起获取源数据库_changes
3. 对一批更改使用revs_diff以查看目标
上需要哪些更改
4. 将任何缺少的修订元数据和当前文档数据+附件从源复制到目标，发布到bulk_docs进行优化，以便存储文档的方式与通常更高级别的MVCC处理{{1 }}。

我在这里略过了许多细节，并建议阅读原始解释。

Answer 3

documentation for CouchDB v2.0.0 covers the replication algorithm更为广泛。它们具有图表，示例中间响应和示例错误。他们使用IETF RFC的＆＃34; MUST＆＃34;，＃34; SHALL＆＃34;等语言。

2.0.0的具体内容（截至2016年1月仍未发布）与1.x略有不同，但基础仍为as @natevw described。

Answer 4

在Apache CouchDB Conf 2013，Benjamin Young在replication.io中介绍了Replication, FTW! talk。这是为基于HTTP的主 - 主复制定义并最终制定规范的持续努力。

Answer 5

这里也记录了：http://www.dataprotocols.org/en/latest/couchdb_replication.html，好吧，等等。