有什么方法可以知道 CouchDB 数据库是否是拉式连续复制的来源？答案

【问题标题】：Is there any way to know if a CouchDB database is the source of a pull continuous replication?有什么方法可以知道 CouchDB 数据库是否是拉式连续复制的来源？
【发布时间】：2013-08-16 13:59:56
【问题描述】：

对于我的示例，假设我们有两台服务器。服务器 A 使用服务器 A 上的本地数据库创建连续拉式复制。此拉式复制的源是服务器 B 上的数据库。

我知道服务器 A 可以通过 _replicator 数据库（如果以这种方式创建）或通过查询 _active_tasks 来监视复制的状态。然而，除了监控 GET 请求之外，服务器 B 有什么方法可以知道它是持续拉取复制的来源？

即便如此，我们还是使用 Cloudant 作为我们的服务器 B，通过代理进行监控不是一种选择。因此，如果 Cloudant 上的数据库是未在 Cloudant 服务器上创建的复制的一部分，那么绝对无法知道它，因为它不会出现在 Cloudant 的 _active_tasks 中，我说的对吗？

编辑：在与 Cloudant Support 的 Samantha Scharr 沟通后，她说“向我们的客户提供日志是我们正在努力解决的一个问题”。一旦完成，这将不是这样的问题。

谢谢，保罗

【问题讨论】：

标签： nosql couchdb replication database-replication cloudant

【解决方案1】：

没有这样的。对于 CouchDB 而言，复制过程并不需要跟踪。

假设您有三个实例：A、B 和 C。 CouchDB 允许您在A 上运行复制过程，以将数据从B 复制到C。例如A 复制过程将在_active_tasks 中明确定义，因为复制在单独的 Erlang 进程中运行。但是对于B 和C 实例，这将被视为某些HTTP 客户端使用一些有效负载调用其公共API 资源。他们永远不会知道有人试图让他们保持同步。

理论上，您可以编写一些日志解析或代理，通过分析基于Replication protocol 定义的HTTP 请求来了解远程复制的运行。但我担心你必须让它足够聪明，不要让他为老客户做很多假阳性匹配。

【讨论】：

我使用 Cloudant 作为云服务器，我无法分析他们的 HTTP 流量。因此，基本上，如果具有凭据的客户端启动了针对我的数据库的持续复制并忘记了它，我就无法检测到它并使用 CouchDB API 停止流量。这可能非常麻烦，我们最终可能会收到一些大笔账单。不过还是谢谢你的回答！
我认为这对 Cloudant 支持团队来说是个好问题。你给他们邮寄了吗？当然，他们有一些解决方案。至于 CouchDB 方面，是的，您必须使用第三方工具来限制来自用户的请求，并且在大多数情况下，您必须将它们放在 CouchDB 前面（如 nginx、iptables 等）。
您好，我联系了 Cloudant，我了解到他们理解这个问题，他们正在努力向用户公开日志，这是最好的消息。感谢您的帮助。