Explains the handshake and acknowledgement process for semi-synchronous replication, ensuring data is committed on at least one replica.
Regular MariaDB replication is asynchronous. MariaDB also includes semisynchronous replication semi-synchronous Binlog Event.
If the user variable @rpl_semi_sync_slave is set, 2 extra bytes are added after the status byte of a binlog network stream and before the normal binlog event header.
semi-sync indicator, always 0xef.
semi-sync flags, either 0x00 (no ACK) or 0x01 (ACK).
Note : The packet size, as in the network protocol header, is then: event_size + 1 byte status + 2 bytes semi-sync replication.
The MariaDB server sets the user variable whenever it is starting replication. For MariaDB Connector/C , the following query must be executed before the call to mariadb_rpl_open() is made to enable semi-sync replication.
If the semi-sync flag is set to 0x01, the master waits for a Semi Sync ACK packet from the slave and when the Semi Sync ACK is seen, the master acknowledges the client which has issued the transaction with a standard OK_Packet or a ERR_Packet.
The master can then write the transaction to the binary log and send the next events to the replica.
Note : The master only requests Semi Sync ACKs if is enabled. If it is not enabled, the semi-sync flag will always be 0x00.
This event is sent by the replica only if the semi-sync flag is set to 0x01.
semi-sync indicator, always 0xef;
the next position of received event;
binlog file name.
Sending an ACK when the semi-sync flag is set to 0x0 causes an error, and the connection is closed.
We can see:
2a 00 00 [3 bytes] packet size.
06 [1] sequence.
00 [1] status byte = 00 => OK.
ef 00 [2] bytes => semi sync indicator (0xef) and semi-sync flag (00).
The master sets the Semi-Sync ACK request in the XID_EVENT event:
We see the 2 semi sync bytes: ef and 01. The latter, being 1, means the replica server must send the Semi Sync ACK packet.
We also see in the binlog event header:
Event Type [1] = 10 XID_EVENT.
Next Event pos [4] = 4a 05 00 00 => 1354.
This is sent by the replica server after the XID_EVENT receiving.
We see:
The semi sync indicator [1] = 0xef, sent before anything else.
The Next Event position [8] = 4a 05 00 00 00 00 00 00 => 1354 which is the next position of the XID_EVENT above.
The binlog filename = mysql-bin.000034.
Please note:
There is no terminating CRC32.
The packet sequence now start starts from 0.
This page is licensed: CC BY-SA / Gnu FDL
SET @rpl_semi_sync_slave=1T 127.0.0.1:23240 -> 127.0.0.1:41054 [AP]
2a 00 00 06 00 ef 00 00 00 00 00 1b d9 27 00 00 *............'..
27 00 00 00 79 04 00 00 00 00 6d 79 73 71 6c 2d '...y.....mysql-
62 69 6e 2e 30 30 30 30 33 34 ed ef e1 f0 bin.000034....22 00 00 0c 00 ef 01 17 d0 37 5a 17 d0 37 5a 10 "............7Z.
d9 27 00 00 1f 00 00 00 4a 05 00 00 00 00 6f 00 .?......J.....o.
00 00 00 00 00 00 44 30 aa fc ......D0..19 00 00 00 ef 4a 05 00 00 00 00 00 00 6d 79 73 .....J.......mys
71 6c 2d 62 69 6e 2e 30 30 30 30 33 34 ql-bin.000034