When you install the source and replica plugins for semisynchronous replication (see Section 3.10.1, “Installing Semisynchronous Replication”), system variables become available to control plugin behavior.
To check the current values of the status variables for
semisynchronous replication, use
mysql> SHOW VARIABLES LIKE 'rpl_semi_sync%';
From MySQL 8.0.26, new versions of the source and replica
plugins are supplied, which replace the terms
“master” and “slave” with
“source” and “replica” in system
variables and status variables. If you install the new
rpl_semi_sync_replica plugins, the new system
variables and status variables are available but the old ones
are not. If you install the old
rpl_semi_sync_slave plugins, the old system
variables and status variables are available but the new ones
are not. You cannot have both the new and the old version of the
relevant plugin installed on an instance.
system variables are described at
Section 2.6.2, “Replication Source Options and Variables” and
Section 2.6.3, “Replica Server Options and Variables”. Some key system
Controls whether semisynchronous replication is enabled on the source server. To enable or disable the plugin, set this variable to 1 or 0, respectively. The default is 0 (off).
Controls whether semisynchronous replication is enabled on the replica.
A value in milliseconds that controls how long the source waits on a commit for acknowledgment from a replica before timing out and reverting to asynchronous replication. The default value is 10000 (10 seconds).
Controls the number of replica acknowledgments the source must receive per transaction before returning to the session. The default is 1, meaning that the source only waits for one replica to acknowledge receipt of the transaction's events.
system variable controls the point at which a semisynchronous
source server waits for replica acknowledgment of transaction
receipt before returning a status to the client that committed
the transaction. These values are permitted:
AFTER_SYNC(the default): The source writes each transaction to its binary log and the replica, and syncs the binary log to disk. The source waits for replica acknowledgment of transaction receipt after the sync. Upon receiving acknowledgment, the source commits the transaction to the storage engine and returns a result to the client, which then can proceed.
AFTER_COMMIT: The source writes each transaction to its binary log and the replica, syncs the binary log, and commits the transaction to the storage engine. The source waits for replica acknowledgment of transaction receipt after the commit. Upon receiving acknowledgment, the source returns a result to the client, which then can proceed.
The replication characteristics of these settings differ as follows:
AFTER_SYNC, all clients see the committed transaction at the same time, which is after it has been acknowledged by the replica and committed to the storage engine on the source. Thus, all clients see the same data on the source.
In the event of source failure, all transactions committed on the source have been replicated to the replica (saved to its relay log). An unexpected exit of the source and failover to the replica is lossless because the replica is up to date. As noted above, the source should not be reused after the failover.
AFTER_COMMIT, the client issuing the transaction gets a return status only after the server commits to the storage engine and receives replica acknowledgment. After the commit and before replica acknowledgment, other clients can see the committed transaction before the committing client.
If something goes wrong such that the replica does not process the transaction, then in the event of an unexpected source exit and failover to the replica, it is possible for such clients to see a loss of data relative to what they saw on the source.
From MySQL 8.0.23, you can improve the performance of
semisynchronous replication by enabling the system variables
which limits callbacks, and
which adds shared locks and avoids unnecessary lock
acquisitions. These settings help as the number of replicas
increases, because contention for locks can slow down
performance. Semisynchronous replication source servers can also
get performance benefits from enabling these system variables,
because they use the same locking mechanisms as the replicas.