Description:
It is a future request.
MySQL semi-sync plugin has variable rpl_semi_sync_master_wait_for_slave_count, which can control the master to wait for at least number of slaves to response ack.
For cross datacenter situation, such as two datacenter, we hope the semi-sync can ensure the master transaction has been received by the slave in the other datacenter.
If only use rpl_semi_sync_master_wait_for_slave_count, we must cover all slaves in the datacenter of the master, which may lead master to wait too many slaves and has worse tolerance for net environment.
How to repeat:
Two datacenter and setup two mysqls for each datacenter.
Suppose these four mysqls are m1, s1, s2, s3.
m1 and s1 in datacenter1.
s2 and s3 in datacenter2.
The replication relationship is m1->s1, m1->s2, m1->s3.
In order to ensure the transaction of m1 to replica to datacenter2, we should set rpl_semi_sync_master_wait_for_slave_count to be 2, actually we can finish the master commit if any of s2 or s3 response to master, no need to wait for s1.
Suggested fix:
It is better to introduce the available zoon for mysql, such as a datacenter is a available zoon, and mysql can config to wait at least number of available zoon slaves for master commit.
For detail, each mysql has new options:
1. available_zoon_id, which indicate the available zoon of this mysql.
It is a global variable and can not be dynamic changed.
2. rpl_semi_sync_master_wait_for_slave_az_count, which indicate the master only need to wait how many of available zoon slaves for commit.
The master will maintain two ack_container, one for rpl_semi_sync_master_wait_for_slave_count, and one for rpl_semi_sync_master_wait_for_slave_az_count.
Anyone ck_container satisfied can lead master to finish commit.
For tow datacenter four mysqls situation mentioned above, we can set rpl_semi_sync_master_wait_for_slave_count to be 2 and set rpl_semi_sync_master_wait_for_slave_az_count to be 1.
If s2 or s3 response fast than s1, the master can finish the commit more soon.
