1

As stated by the Galera documentation, the cluster uses synchronous replication. But looking a bit deeper, there are statements, that Galera is only "virtually" synchronous. On the nodes, a commit has to pass a "certification" instead a physical commit. I really need to understand this part to plan the architecture of an application.

So I like to now which of the following cases would be true if any:

Script A does an UPDATE in a transaction taking approximate 5 seconds and a COMMIT takes a few seconds either. A Script B follows when Script A is finished immediately, for example with a HTTP-Redirect after HTTP-POST-Request within a second. Script B queries a different node than script A.

  1. Script B gets the status before the UPDATE because the UPDATE still needs around 4 seconds to finish.
  2. Script B gets the status after the UPDATE because the COMMIT finishes when the state of all nodes is synchronous.

Which one would be true if any? Or is the behavior dependent on configuration?

4

1 回答 1

5

事件顺序：

-- 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在常规复制中，在从站赶上之前，没有干净的方法可以停止。在 Galera，SET wsrep_sync_wait = 31在做SELECT. 这将确保“虚拟”变为“真实”。

'31' 是位掩码；也许你需要更少的位。请参阅 wsrep_sync_wait。

我希望这能给你足够的信息来弄清楚你的节点 A 和节点 B 会做什么。

有autocommit=ON和没有BEGIN，想想写（例如，UPDATE）是BEGIN; write; COMMIT;。那么我上面的列表仍然适用。

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

于 2015-09-08T21:40:42.787 回答