MDEV-39880 Reïmplement MDEV-37146 to include MDEV-39519#5458
Conversation
This comment was marked as spam.
This comment was marked as spam.
| @@ -6603,16 +6635,18 @@ static int do_show_slave_status(MYSQL *mysql_con, | |||
| if (use_gtid) | |||
There was a problem hiding this comment.
For 10.11: Warn when using --gtid to dump MySQL or a pre-GTID MariaDB?
The behaviour before MDEV-37146 or MDEV-39519 appears to still dump no-MariaDB-GTID servers with the following snippet, just not followed by SET GLOBAL gtid_slave_pos='…';.
-- The deferred gtid setting for slave corresponding to the dump-slave CHANGE-MASTER follows
-- GTID position to start replication:| have_info_schema_slave_status= false; | ||
| // Between 10.0 and 11.5 inclusive | ||
| switch (mysql_query_with_error_report(mysql_con, &slave_status_res, | ||
| "SHOW ALL SLAVES STATUS", true |
There was a problem hiding this comment.
I considered using REPLICAS here as well, but I noticed that if MySQL suddenly adds SHOW ALL REPLICAS STATUS, but in MySQL’s column order rather than MariaDB’s, then these assumptions would break in the absence of version checks.
(It’s not MDEV-39880’s concern, but version ≥ 10.0 checks probably will also fall apart soon with the upcoming MySQL 26.7.
They have not released their last quarter’s commits, so the only way to verify is to download their entire pre-release, which I’m not bothering.)
On the other hand, I assume that both MariaDB deleting the SLAVES keyword and MySQL reviving it are very unlikely.
| if (mysql_query_with_error_report(mysql_con, &slave_status_res, | ||
| have_info_schema_slave_status ? | ||
| // 11.6 and above | ||
| switch (mysql_query_with_error_report(mysql_con, &slave_status_res, |
There was a problem hiding this comment.
I’m tempted to revive my old draft implementation based on virtual methods.
But the old argument holds that we will eventually deprecate 11.4 & before.
It’s also really MySQL’s problem that their SQL version of SHOW REPLICA STATUS is still stuck behind Perf. Schema.
I did not extend mysql_query_with_retry() because this code design requires an overly detailed flexibility.
(Although it’d be cleaner with that virtual methods code design.)
Currently, the only other uses of mysql_query_with_retry() are in --master-data ’s and --delete-master-logs’s code, but they both query SHOW MASTER STATUS first and then SHOW BINARY LOG STATUS.
It’s not my current focus to get them to share their results, though (but it’s viable because --delete-master-logs includes --master-data).
Side note
While I removed --dump-slave & --apply-slave-statements support for pre-10.0 in MDEV-37146, I did not touch --master-data.
There was a problem hiding this comment.
This PR does not add --apply-slave-statements support for MySQL.
But I doubt that mariadb-dump should support outputting for MySQL.
STOP/START REPLICA also means STOP/START ALL SLAVES on MySQL, but not on MariaDB, so this is a (if not the only) detail where an output intended for MySQL would have an incomplete effect on MariaDB.
There was a problem hiding this comment.
… which reminds me that I must use STOP/START REPLICA SQL_THREAD FOR CHANNEL '…', which is compatible with both MariaDB 10.7 and MySQL.
fixing now done
[P.S.] 10.6 isn’t dead dead tho…
[P.P.S] … eh screw it for today; ES and other extended supporters can add their own code branch or backport FOR CHANNEL to their 10.6.
So should the MDEV-39519 base…
But the old code design can only send the base STOP/START REPLICAL SQL_THREAD to MySQL, which works, just inconvenient.
Oh well.
MDEV-39519 added MySQL 8 compatibility to `mariadb-dump --dump-slave` by attempting `SHOW REPLICA STATUS` first and then `SHOW SLAVE STATUS`. This conflicted with MDEV-37146, where `mariadb-dump --dump-slave` queries either `SELECT … FROM information_schema.SLAVE_STATUS` or `SHOW ALL SLAVES STATUS` depending on the server version. This commit merges MDEV-37146 and MDEV-39519: * Use MDEV-39519’s strategy based on syntax error handling. * Use MDEV-37146’s preference order: 1. `SELECT … FROM information_schema.SLAVE_STATUS` 2. `SHOW ALL SLAVES STATUS` 3. `SHOW REPLICA STATUS` (for MySQL compatibility _only_) * Send `STOP`/`START REPLICA SQL_THREAD FOR CHANNEL '…'` commands for both MariaDB (est. 10.7) and MySQL. * Refactor column indices to variables set when a query succeeds. * Partially revert MDEV-37146’s removal of `--dump-slave`’s support for pre-GTID & pre-multi-source, but tailored for MySQL compatibility; coverage for MariaDB pre-10.0 is not fully restored.
1 participant
MDEV-39519 added MySQL compatibility to
mariadb-dump --dump-slaveby attemptingSHOW REPLICA STATUSfirst and thenSHOW SLAVE STATUS.This conflicted with MDEV-37146, where
mariadb-dump --dump-slavequeries eitherSELECT … FROM information_schema.SLAVE_STATUSorSHOW ALL SLAVES STATUSdepending on the server version.This commit merges MDEV-37146 and MDEV-39519:
SELECT … FROM information_schema.SLAVE_STATUSSHOW ALL SLAVES STATUSSHOW REPLICA STATUS(for MySQL compatibility only)STOP/START REPLICA SQL_THREAD FOR CHANNEL '…'commands for both MariaDB (est. 10.7) and MySQL.--dump-slave’s support for pre-GTID & pre-multi-source, but tailored for MySQL compatibility; coverage for MariaDB pre-10.0 is not fully restored.(That would require a 4th command:
SHOW SLAVE STATUS.)Disclaimer re. «Consistent use of terminology "master" and "slave" in replication development»:
All appearances of
REPLICAin this PR are about MySQL compatibility and are not directly related to… that movement.