mysql - 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 直到从服务器 catch 。在 Galera 中，SET wsrep_sync_wait = 31 在执行 SELECT 之前。这将确保“虚拟”变为“真实”。

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

我希望这能为您提供足够的信息来弄清楚您的节点 A 和节点 B 将做什么。

在 autocommit=ON 且没有 BEGIN 的情况下，将写入(例如，UPDATE)视为 BEGIN；写;提交；。那么我上面的列表仍然适用。

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