处理 Couchbase 中的耐久性要求失败
Handling durability requirements failure in Couchbase
最近我开始调查 Couchbase Server 作为该项目的候选者。我现在正在研究的一个特定场景是如何让 Couchbase 充当 "source of truth"，这就是我深入研究耐用性方面的原因。
所以这里是 ACID Properties and Couchbase 的片段：
If the durability requirements fail, then Couchbase may still save the
document and eventually distribute it across the cluster. All we know
is that it didn’t succeed as far as the SDK knows. You can choose to
act on this information to introduce more ACID properties into your
application.
接下来想象一下。我 insert/update 文档和主节点失败，直到数据到达任何副本。假设 primary 已经消失很长时间了。现在，我不知道此时数据是否已写入磁盘...所以这里的一个可怕部分是 "Couchbase may still save the document and eventually distribute it across the cluster"。意思是，据客户所知，数据没有成功，因此用户会看到一个错误，但如果主服务器重新联机，它可能会突然出现在系统中。
我是否正确阅读了此声明？如果是，使用 Couchbase 处理它的最佳做法是什么？
简答：
打开自动故障转移，你会没事的。
更长的答案：
听起来您担心这里的边缘情况非常狭窄。这是我的理解：
- 您使用 SDK 保存文档并为其设置 persists_to 持久性要求。
- Couchbase 确认文档已保存到内存中。
- SDK 开始检查以确保它已持久保存到磁盘and/or 已复制。
- 在极短的 window 时间内，节点关闭。文档保存到磁盘但没有复制到另一个节点并且主节点没有故障转移.
- SDK运行会return报错，提示不满足持久化要求。 （我对此可能是错误的，它可能 return 一个不同的错误，这意味着你可以采取不同的行动）。
- 您通知用户某事失败了。
- 节点重新启动，重新加入集群，文档就在那里。
- 困惑的用户？
如果这是正确的，关键是第 4 步。首先，这似乎是一个非常罕见的极端情况。所有这三件事都必须是真的才能担心这种情况。我的 Couchbase 内部知识并不坚如磐石，因此这种情况可能无法实现（但我会继续这样做）。
如果您 运行 Couchbase 的网络和机器都很好，那么网络 splits/nodes 宕机应该不会经常发生。因此，您可以打开自动故障转移。请记住，我们的文档没有写入磁盘。因此，当发生故障转移时，该文档仅在 RAM 中，因此它永远消失了（既然你告诉了用户，就不会混淆）。
再次声明，我不是 Couchbase 内部结构方面的专家，所以这一切都是我所知道的，但听起来您需要做的就是打开自动故障转移，您会没事的。默认关闭；这个想法是你应该首先了解它是什么并选择加入。但对于大多数系统，使用自动故障转移。
下面是我与 Couchbase 人员交谈后发现的内容：
场景 #1
One scenario could be that after it has been acknowledged as
persisted, but before it’s been replicated, the node fails. In that
case, if you do not failover the node, when it comes back online, that
item will be replicated.
场景 #2
One other scenario is that you could have autofailover enabled and
after it’s received by the primary but before it’s replicated or
persisted, autofailover kicks in and brings a replica to primary. In
this case, your application will have seen the failure to achieve the
durability requirement requested. If the previous primary does come
back online, before it rejoins the cluster it will resync with the
state of the current cluster meaning the location where the item is
active is now the current state.
所以我问过“当以前的主服务器重新联机并带有本地保留但未复制的项目并开始重新同步时，这些项目会被擦除吗？” -
Yes, and that’s really intentional. You could look at those previously
persisted items as an “alternate history” that didn’t play out. When
the failure occurred, the cluster picked a new starting place, got
everyone to agree, and started the universe moving forward from there.
When the old node recovers and tries to join this universe, it has to
do so with a shared understanding of that universe, which potentially
means dropping data that wasn’t passed along.
Of course, in practice, since replication is memory-to-memory and Disk
IO tends to be higher latency (the replication of an item and the
persistence of items are both scheduled concurrently), things will
tend to be replicated more than persisted, but there is no guarantee.
Also, the app (through the SDK) has some ability to influence outcomes
too with the Durability Requirements features we were talking about.
完整的对话是here。
这个问题的更新：
Couchbase 6.5 引入了对事务的支持：
transactions.run((txnctx) -> {
// get the account documents for Andy and Beth
TransactionJsonDocument andy = txnctx.getOrError(collection, "Andy");
JsonObject andyContent = andy.contentAsObject();
int andyBalance = andyContent.getInt("account_balance");
TransactionJsonDocument beth = txnctx.getOrError(collection, "Beth");
JsonObject bethContent = beth.contentAsObject();
int bethBalance = bethContent.getInt("account_balance");
// if Beth has sufficient funds, make the transfer
if (bethBalance > transferAmount) {
andyContent.put("account_balance", andyBalance + transferAmount);
txnctx.replace(andy, andyContent);
bethContent.put("account_balance", bethBalance - transferAmount);
txnctx.replace(beth, bethContent);
}
else throw new InsufficientFunds();
// Commit transaction - if omitted will be automatically committed
txnctx.commit();
});
耐用性也得到了提升，现在您可以在 3 个级别之间进行选择：多数、persistToActive、persistToMajority
阅读更多：
最近我开始调查 Couchbase Server 作为该项目的候选者。我现在正在研究的一个特定场景是如何让 Couchbase 充当 "source of truth"，这就是我深入研究耐用性方面的原因。
所以这里是 ACID Properties and Couchbase 的片段：
If the durability requirements fail, then Couchbase may still save the document and eventually distribute it across the cluster. All we know is that it didn’t succeed as far as the SDK knows. You can choose to act on this information to introduce more ACID properties into your application.
接下来想象一下。我 insert/update 文档和主节点失败，直到数据到达任何副本。假设 primary 已经消失很长时间了。现在，我不知道此时数据是否已写入磁盘...所以这里的一个可怕部分是 "Couchbase may still save the document and eventually distribute it across the cluster"。意思是，据客户所知，数据没有成功，因此用户会看到一个错误，但如果主服务器重新联机，它可能会突然出现在系统中。
我是否正确阅读了此声明？如果是，使用 Couchbase 处理它的最佳做法是什么？
简答：
打开自动故障转移，你会没事的。
更长的答案：
听起来您担心这里的边缘情况非常狭窄。这是我的理解：
- 您使用 SDK 保存文档并为其设置 persists_to 持久性要求。
- Couchbase 确认文档已保存到内存中。
- SDK 开始检查以确保它已持久保存到磁盘and/or 已复制。
- 在极短的 window 时间内，节点关闭。文档保存到磁盘但没有复制到另一个节点并且主节点没有故障转移.
- SDK运行会return报错，提示不满足持久化要求。 （我对此可能是错误的，它可能 return 一个不同的错误，这意味着你可以采取不同的行动）。
- 您通知用户某事失败了。
- 节点重新启动，重新加入集群，文档就在那里。
- 困惑的用户？
如果这是正确的，关键是第 4 步。首先，这似乎是一个非常罕见的极端情况。所有这三件事都必须是真的才能担心这种情况。我的 Couchbase 内部知识并不坚如磐石，因此这种情况可能无法实现（但我会继续这样做）。
如果您 运行 Couchbase 的网络和机器都很好，那么网络 splits/nodes 宕机应该不会经常发生。因此，您可以打开自动故障转移。请记住，我们的文档没有写入磁盘。因此，当发生故障转移时，该文档仅在 RAM 中，因此它永远消失了（既然你告诉了用户，就不会混淆）。
再次声明，我不是 Couchbase 内部结构方面的专家，所以这一切都是我所知道的，但听起来您需要做的就是打开自动故障转移，您会没事的。默认关闭；这个想法是你应该首先了解它是什么并选择加入。但对于大多数系统，使用自动故障转移。
下面是我与 Couchbase 人员交谈后发现的内容：
场景 #1
One scenario could be that after it has been acknowledged as persisted, but before it’s been replicated, the node fails. In that case, if you do not failover the node, when it comes back online, that item will be replicated.
场景 #2
One other scenario is that you could have autofailover enabled and after it’s received by the primary but before it’s replicated or persisted, autofailover kicks in and brings a replica to primary. In this case, your application will have seen the failure to achieve the durability requirement requested. If the previous primary does come back online, before it rejoins the cluster it will resync with the state of the current cluster meaning the location where the item is active is now the current state.
所以我问过“当以前的主服务器重新联机并带有本地保留但未复制的项目并开始重新同步时，这些项目会被擦除吗？” -
Yes, and that’s really intentional. You could look at those previously persisted items as an “alternate history” that didn’t play out. When the failure occurred, the cluster picked a new starting place, got everyone to agree, and started the universe moving forward from there. When the old node recovers and tries to join this universe, it has to do so with a shared understanding of that universe, which potentially means dropping data that wasn’t passed along.
Of course, in practice, since replication is memory-to-memory and Disk IO tends to be higher latency (the replication of an item and the persistence of items are both scheduled concurrently), things will tend to be replicated more than persisted, but there is no guarantee. Also, the app (through the SDK) has some ability to influence outcomes too with the Durability Requirements features we were talking about.
完整的对话是here。
这个问题的更新：
Couchbase 6.5 引入了对事务的支持：
transactions.run((txnctx) -> {
// get the account documents for Andy and Beth
TransactionJsonDocument andy = txnctx.getOrError(collection, "Andy");
JsonObject andyContent = andy.contentAsObject();
int andyBalance = andyContent.getInt("account_balance");
TransactionJsonDocument beth = txnctx.getOrError(collection, "Beth");
JsonObject bethContent = beth.contentAsObject();
int bethBalance = bethContent.getInt("account_balance");
// if Beth has sufficient funds, make the transfer
if (bethBalance > transferAmount) {
andyContent.put("account_balance", andyBalance + transferAmount);
txnctx.replace(andy, andyContent);
bethContent.put("account_balance", bethBalance - transferAmount);
txnctx.replace(beth, bethContent);
}
else throw new InsufficientFunds();
// Commit transaction - if omitted will be automatically committed
txnctx.commit();
});
耐用性也得到了提升，现在您可以在 3 个级别之间进行选择：多数、persistToActive、persistToMajority
阅读更多：