mysql - 在 haproxy 中写入故障转移期间，正在进行的 mysql 事务会发生什么情况？

Question

我目前将 haproxy 配置为对一组 mysql 服务器进行负载平衡和故障转移。我有一个为写入事务配置的后端，如下所示:

backend pool_mysql_write
timeout connect 10s
timeout server 1m
mode tcp
option mysql-check user haproxy_check
server primary <primary_node>:3306 check fastinter 1000
server secondary <secondary_node>:3306 check fastinter 1000 backup

“备份”指令的存在，以便所有写入仅转到主数据库节点，并且仅在主数据库出现故障时才会故障转移到辅助数据库节点。

编辑:数据库节点处于主-主复制模式。

我的问题是，当 haproxy 故障转移到辅助数据库节点时，正在进行的 mysql 写入查询会发生什么？例如，如果 haproxy 需要 5 秒才能提升辅助数据库节点进行写入，那么在 5 秒故障转移时间内可能尝试写入数据库的所有写入查询会发生什么情况？

它们就这样消失了吗？它们是否会在某个地方排队，以便在辅助数据库节点升级后可以提交它们？

Answer 1

当(由客户端)启动到 haproxy 的新 TCP 连接时，它会依次打开到上游服务器的新 TCP 连接。一旦建立了上游 TCP 连接，haproxy 就会将这些 TCP 连接连接在一起，来回中继通信。

如果其中一个 TCP 连接(即它与客户端之间的连接，或者与上游服务器之间的连接)断开，haproxy 只会断开另一个连接，换句话说，haproxy 不会切换现有到备用服务器的 TCP 连接(它只是重定向新连接)。交易对手负责决定下一步做什么。 (为了更智能的方法，您需要像 MariaDB MaxScale 这样的第 7 层代理，它可以重新路由现有连接)。

通常，如果其连接意外断开，客户端将尝试重新连接(此时 haproxy 可能最终将其与不同的上游服务器连接，例如，因为原始服务器不再可用)。

问题是，如果客户端向原始服务器发送了命令，导致其状态发生变化怎么办？

• 如果客户端在连接断开之前收到提交确认，那么客户端将了解其写入已被提交。因此，您必须确保 primary 不会确认提交，直到写入已复制到 secondary - 这就是为什么我在上面询问您如何执行该复制:至少，您想要Semisynchronous Replication :

  MySQL replication by default is asynchronous. The master writes events to its binary log but does not know whether or when a slave has retrieved and processed them. With asynchronous replication, if the master crashes, transactions that it has committed might not have been transmitted to any slave. Consequently, failover from master to slave in this case may result in failover to a server that is missing transactions relative to the master.

  Semisynchronous replication can be used as an alternative to asynchronous replication:

  [ deletia ]

  While the master is blocking (waiting for acknowledgment from a slave), it does not return to the session that performed the transaction. When the block ends, the master returns to the session, which then can proceed to execute other statements. At this point, the transaction has committed on the master side, and receipt of its events has been acknowledged by at least one slave.

• 如果客户端在连接断开之前未收到提交确认，则客户端应假设写入未提交并进行相应处理 - 例如建立新连接后重新尝试事务。

  但是，有可能，primary 实际上已经提交了写入(并且确实将它们复制到secondary)，但就在之前失败了它发送了提交确认，或者它发送了提交确认但在客户端收到之前连接失败。我认为对此我们无能为力(请发表评论？)，但风险非常小(因为在完成提交和发送确认之间没有发生任何处理)。