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

Question

如Galera文档所述，群集使用同步复制。但是看得更深一些，有一些声明，Galera只是“几乎”同步。在节点上，提交必须通过“认证”而不是物理提交。我真的需要理解这部分来规划应用程序的体系结构。

所以我现在喜欢以下哪种情况如果有的话：

脚本A在事务中执行UPDATE大约需要5秒钟，而COMMIT需要几秒钟。当脚本A立即完成时，脚本B就会出现，例如在一秒钟内在HTTP-POST-Request之后使用HTTP重定向。脚本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之后，并且在控制返回给客户端之前。 那是加莱拉的秘密酱。

同步是因为客户端只有在所有节点都拥有数据并且同意写入成功后才能获得OK。

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

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

'31'是一个掩码;也许你需要更少的比特。看到 wsrep_sync_wait

我希望这能为您提供足够的信息，以确定您的Node A和Node B将做什么。

使用autocommit=ON，而不是BEGIN，请考虑写入（例如，UPDATE）为BEGIN; write; COMMIT;。然后我上面的列表仍然适用。

在我看来，交易5秒钟太长了。我会试着弄清楚它的哪一部分是最长的并进行优化。