Galera 集群中提交后的节点状态是什么

Question

如 Galera 文档所述，集群使用同步复制。但再深入一点，有一些说法，Galera 只是“实际上”同步的。在节点上，提交必须通过“认证”而不是物理提交。我真的需要了解这部分来规划应用程序的架构。

所以我现在想知道以下哪种情况是正确的：

脚本 A 在事务中执行 UPDATE 大约需要 5 秒，而 COMMIT 也需要几秒钟。当脚本 A 立即完成时，脚本 B 紧随其后，例如在一秒钟内 HTTP-POST-Request 之后的 HTTP-Redirect。脚本 B 查询与脚本 A 不同的节点。

1. 脚本 B 获得 UPDATE 之前的状态，因为 UPDATE 仍然需要大约 4 秒才能完成。
2. 脚本 B 获取 UPDATE 之后的状态，因为 COMMIT 在所有节点的状态同步时结束。

如果有的话，哪一个是正确的？还是行为取决于配置？

Answer 1

事件顺序：

-- Node 1:
BEGIN;  (or otherwise start a transaction)
Do some writes
COMMIT;
Node 1 sends the entire transaction (via RBR) to the other nodes.
The other nodes say "OK, there won't be any conflicts".
Node 1 receives the OKs.
Node 1 responds OK to the client.
-- (eventually) on the other nodes:
Actually finish writing the data disk, etc.

请注意，到其他节点只有一次往返，并且发生在COMMIT 之后，控制权返回给客户端之前。 这就是 Galera 的秘诀。

同步，客户端只有在所有个节点都有数据并同意写入成功后才获得OK。

它是“虚拟的”，因为一些工作（通常是 I/O 密集型）尚未完成。

“关键阅读”是，例如，用户发布博客条目，然后去查看它（但可能连接到不同的从站/节点）。他希望它在那里。在常规复制中，没有干净的方法来停止SELECT，直到从站赶上。在 Galera，SET wsrep_sync_wait = 31 在执行 SELECT 之前。这将确保“虚拟”变为“真实”。

'31' 是位掩码；也许你需要更少的位。看 wsrep_sync_wait.

我希望这可以为您提供足够的信息来确定您的节点 A 和节点 B 将做什么。

如果有autocommit=ON，而没有BEGIN，则认为写入（例如UPDATE）是BEGIN; write; COMMIT;。那么我上面的列表仍然适用。

在我看来，5 秒的交易时间太长了。我会尝试找出其中最长的部分并对其进行优化。