Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
2.3.14, 2.4.3
-
None
Description
In MariaDB Server, semisynchronous replication can face some negative consequences when the master crashes. The specific consequence depends on the value of rpl_semi_sync_master_wait_point.
The consequences are explained in the following documentation section:
https://mariadb.com/kb/en/library/semisynchronous-replication/#configuring-the-master-wait-point
When rpl_semi_sync_master_wait_point is set to AFTER_SYNC, the consequences are:
The effects of the AFTER_SYNC wait point are:
...
- However, if the master crashes, then its binary log may also contain events for transactions that were prepared by the storage engine and written to the binary log, but that were never actually committed by the storage engine. As part of the server's automatic crash recovery process, the server may recover these prepared transactions when the server is restarted. This could cause the crashed master to become inconsistent with the slaves. Therefore, the crashed master may need to be rebuilt. See MDEV-19733 for more information.
When rpl_semi_sync_master_wait_point is set to AFTER_COMMIT, the consequences are:
The effects of the AFTER_COMMIT wait point are:
...
- If the master crashes, then failover may involve some data loss, because the master may have committed transactions that had not yet been acknowledged by the slaves.
If auto_rejoin is configured in MariaDB Monitor, then both of these cases can cause the master to fail to rejoin as a slave when it is restarted.
We should make sure that this information is documented:
https://mariadb.com/kb/en/mariadb-maxscale-23-mariadb-monitor/#limitations-and-requirements
https://mariadb.com/kb/en/mariadb-maxscale-24-mariadb-monitor/#limitations-and-requirements
Attachments
Issue Links
- is caused by
-
MDEV-20996 Maxscale auto-failover with semi-sync replication is not providing a true HA solution
- Closed