Hi all,
There is a replication regression in MariaDB 12.3.1, 12.3.2, and 13.0.1
(MDEV-39788). When a slave is upgraded to one of these versions from any
earlier version (10.x, 11.x, or 12.0 through 12.2), the server will
reset the value of `MASTER_USE_GTID` to the default, `Slave_Pos`, for
all configured slave connections. The specific regressions are:
1. The server will ignore the `using_gtid` setting in the existing
`master.info` files left by the old version.
2. `master.info` files written by 12.3.1, 12.3.2, and 13.0.1 servers
will have an additional line break at line 34. This file format
change doesn't break any behavior (nor does it break downgrades),
but it is noteworthy.
What you will see after the upgrade: `Using_Gtid` in `SHOW SLAVE
STATUS` shows the default, `Slave_Pos`, no matter what it was before.
* Slaves that ran with `MASTER_USE_GTID=No` reconnect in GTID mode
and resume from `gtid_slave_pos` instead of the saved binlog
coordinates.
* Slaves that ran with `Current_Pos` silently switch to
`Slave_Pos`.
* Slaves already on `Slave_Pos` are effectively unaffected, since
the lost value matches the default.
Note too, that the server soon rewrites `master.info` with the reset
value, so the original setting cannot be recovered from the file
afterwards. Only upgrades trigger this; slaves set up fresh on an
affected version, or restarted within one, are fine.
If you need to upgrade a slave to one of the affected versions, the
workaround is:
1. Before the upgrade, record `Using_Gtid` for every connection
(`SHOW ALL SLAVES STATUS`).
2. Start the upgraded server with `--skip-slave-start`.
3. Restore the previous mode and resume replication:
CHANGE MASTER TO MASTER_USE_GTID=no;
START SLAVE;
(Use `current_pos` instead of `no` if that was your previous
mode. In multi-source setups, repeat for each connection with
`CHANGE MASTER 'name' TO ...`.)
If a slave has already been running on an affected version, check
`Using_Gtid`, restore it with `STOP SLAVE` followed by the same
`CHANGE MASTER` and `START SLAVE`, and review whether replication
resumed from the intended position in the meantime.
This will be fixed in the next releases, 12.3.3 and 13.0.2. Upgrading
straight from 12.2 or earlier to a fixed release reads the old
`master.info` correctly, so upgrades that skip the affected versions
will not hit this. Upgrading from an affected version to a fixed one
does not bring the old setting back, though, so verify `Using_Gtid`
if you passed through 12.3.1, 12.3.2, or 13.0.1.
The cause of the regression is a refactoring (MDEV-37530), which changed
the meaning of the first line in the master.info file. Overall, this
file provides the configurations of a slave connection, where some lines
are values that are hard-coded to specific configurations, and other
lines are "key=value" pairs, where the configuration name is explicitly
listed. The first line in the file indicates the number of lines at the
beginning of the file with hard-coded values:
* Prior to the refactoring, this value included the first line in the
file (i.e. number-of-lines).
* After the refactoring, the value became the number of lines _following_
the first line (matching the first line in the `relay-log.info` file).
The result is that after the refactor, the server would read for
key=value configurations starting at line 35, but prior to the refactor,
the server would read for key=value configurations at line 34. The
configuration at line 34 is always `using_gtid`, and this was dropped.
Then when writing the file, it would start writing at line 35 instead of
34, thereby providing an extra line break before the key=value
configurations started. Note that the binlog file name, position, and
all other connection settings are preserved and read correctly.
Sorry for any inconvenience or problems this may bring,
Brandon
_______________________________________________
discuss mailing list -- [email protected]
To unsubscribe send an email to [email protected]
