Hi, On 12/4/24 13:19, Kristian Nielsen via developers wrote:
5. A more controversial thought is to drop support for semi-sync replication. I think many users use semi-sync believing it does something more than the reality. Instead of semi-sync, users can always just SELECT MASTER_GTID_WAIT(@@last_gtid) on a slave to get arguably better functionality. And the semi-sync implementation has always been problematic (IMHO), what with sending the actual binlog filename string back and forth with every commit, and causing much complexity and many bugs. Less controversial will be to release the first version without semi-sync support and add it later.
As a (kind of) user of semi-sync replication, I believe it has a valid, albeit limited, use-case and that it's a necessary component in setups where no transactions are allowed to be lost when the primary node in a replication cluster goes down. Perhaps I'm wrong or the way it works isn't how I think it does so I'll try and describe what I think it does and what it doesn't do. When semi-synchronous replication is enabled and configured correctly (by default it isn't), the only thing that it guarantees is that if a client receives an OK for the COMMIT, it means that at least one other server in the replication topology has successfully received that transaction. This means that if the server where the transaction was committed goes down and never comes back up again, it's still possible to find the committed transaction on another node and then fail over the cluster to replicate from that node. Doing this manually requires inspecting the GTIDs and waiting for the relay log to be applied but there are automated solutions for this (e.g. MaxScale). What it doesn't do is guarantee that the event has been applied when the OK is received. It might not even get applied if the server that ended up receiving the event has diverged from the rest of the cluster and fails to apply it. The delay in the application of the event is a separate problem (read causality) that can be solved with different methods (e.g. MASTER_GTID_WAIT). The problem of a "broken" server receiving and not being able to apply it is a tougher problem to solve but I believe it can be mostly avoided by making replicas read-only and requiring strict GTID ordering. I think that the current default values for the semi-sync replication are not useful for this use-case and I think that a lot of the misunderstanding comes from this. The default value of rpl_semi_sync_master_wait_point should be AFTER_SYNC (lossless failover) and rpl_semi_sync_master_timeout should be set to something a lot higher than 10 seconds. Personally, I think setting it to the maximum value is the safest as it prevents writes if they might not survive an outage of the node being written on. This does mean that a two node setup cannot tolerate a loss of a node without going read-only but this is an unavoidable fact and trying to work around it would render semi-sync useless. The documentation could also be improved to clearly state what it does to describe a use-case for the feature. Right now the Semisynchronous Replication page (https://mariadb.com/kb/en/semisynchronous-replication/) mentions that "semisynchronous replication therefore comes with some negative performance impact, but increased data integrity" which doesn't adequately explain why one would want to use it. Markus -- Markus Mäkelä, Senior Software Engineer MariaDB Corporation