Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.11.19, 12.3.3
-
None
-
Pretty much anywhere, doesn't seem to be affected by the environment.
-
Can result in hang or crash
Description
With the following configuration on both the master and the slave:
log-bin
|
log-slave-updates
|
rpl_semi_sync_master_enabled=1
|
rpl_semi_sync_slave_enabled=1
|
rpl_semi_sync_master_timeout=1000000
|
The slave stalls whenever it executes the first event from the relay log. Here's the output from the slave where it stalls on the CREATE DATABASE IF NOT EXISTS test that I execute as the first statement on the master.
+----+-------------+-----------+------+-----------+------+--------------------------------------+------------------------------------+----------+
|
| Id | User | Host | db | Command | Time | State | Info | Progress |
|
+----+-------------+-----------+------+-----------+------+--------------------------------------+------------------------------------+----------+
|
| 6 | system user | | NULL | Slave_IO | 21 | Waiting for master to send event | NULL | 0.000 |
|
| 7 | system user | | test | Slave_SQL | 21 | Waiting for semi-sync ACK from slave | CREATE DATABASE IF NOT EXISTS test | 0.000 |
|
| 12 | root | localhost | NULL | Query | 0 | starting | show processlist | 0.000 |
|
+----+-------------+-----------+------+-----------+------+--------------------------------------+------------------------------------+----------+
|
This only happens when log-slave-updates is used. Turning it off skips the ACK, as expected, since this is probably using the same binlogging path that the normal client-facing commits use.
This is a problem because it prevents configurations from being used that use both log-slave-updates and semi-sync replication. Currently the only workaround is to manually manage the value of rpl_semi_sync_master_enabled which, due to the lack of being able to persist configuration changes, has to be repeatedly polled on both the master and the slave and enabled on the master and disabled on the slave. Software that manages replication, e.g. MaxScale and the MariaDB Operator, has to handle this added complexity due to the possibility of a replication stall due to log-slave-updates.
Attachments
Issue Links
- relates to
-
MDEV-40934 Add IO thread version of MASTER_GTID_WAIT
-
- Open
-
