Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.6.18, 10.6.19
-
None
-
Can result in unexpected behaviour
-
Replication could break while replicating ALTER SEQUENCE on a parallel replica because the ALTER SEQUENCE command could complete and commit before a slow-running preceding transaction, thereby leading to an out-of-order sequence number error.
-
Q3/2025 Maintenance
Description
Create a 3 node replication group comprising of one master and two slaves. Use the following globals on slaves:
gtid_strict_mode=ON
|
slave_parallel_max_queued = 524288
|
slave_parallel_mode = conservative
|
slave_parallel_threads = 3
|
Run a script on master that includes large multi-statement transactions and ALTER SEQUENCE. Example script is attached.
The following replication error is found on each slave:
Last_SQL_Error: An attempt was made to binlog GTID 0-1-13 which would create an out-of-order sequence number with existing GTID 0-1-14, and gtid strict mode is enabled
|
What is unusual about this is I have tested it with many versions, and not all of them have the same problem. This may be because the fix from MDEV-31503 is included in some but not included in all software.
The following distributions can reproduce this error:
10.6.19-15-MariaDB-enterprise-log on Debian installed using apt
10.6.17-13-MariaDB-enterprise-log on Debian installed using apt
10.6.16-MariaDB-log (community) installed on Centos using yum (same as customer)
10.6.19-MariaDB-log (community) installed on Centos using yum
The following software distributions do not produce this problem:
mariadb-10.6.17-linux-systemd-x86_64.tar.gz
mariadb-10.6.18-linux-systemd-x86_64.tar.gz
mariadb-10.6.19-linux-systemd-x86_64.tar.gz
mariadb-10.6.20-linux-systemd-x86_64.tar.gz
I noticed on one of my tests that when there is only one slave, the error does not occur. So, to reproduce this, create two slaves.