[MDEV-10047] Upgrade from MySQL to extract data into master.info file WAS: table-based master info repository Created: 2016-05-09  Updated: 2023-02-16  Due: 2020-04-24  Resolved: 2020-03-13

Status: Closed
Project: MariaDB Server
Component/s: Replication
Fix Version/s: 10.2.32, 10.3.23, 10.4.13, 10.5.2

Type: Task Priority: Major
Reporter: Kolbe Kegel (Inactive) Assignee: Sujatha Sivakumar (Inactive)
Resolution: Fixed Votes: 9
Labels: None

Issue Links:
Relates
relates to MDEV-21753 convert the upstream's '*-info-reposi... Stalled

 Description   

Upon upgrade from MySQL to MariaDB master-info-repository and relay-log-info-repository are completely ignored without even warning in .err log. This causes troubles when migrating slave servers. There should be at least warning if not error in .err log.

Ideally mysql_upgrade script should take care of that and extract the data from mysql.slave_master_info and mysql.slave_relay_log_info to store them in master.info file.

The ticket description is edited to stress on the missed warnings at or after upgrade to mariadb, the former description text is below. In fact its aim to have table-based master info is addressed through mysql.gtid_slave_pos which in combination with CHANGE MASTER TO ... master_use_gtid = slave_pos provides failure tolerance to slave.

I'd like to see MariaDB support table-based master info repository (see https://dev.mysql.com/doc/refman/5.6/en/replication-options-slave.html#option_mysqld_master-info-repository). If an InnoDB table were used, it could be encrypted. This would be preferable to having to put the password in plaintext in a text file.



 Comments   
Comment by Alexander Keremidarski [ 2019-10-18 ]

Upon upgrade from MySQL to MariaDB master-info-repository and relay-log-info-repository are completely ignored without even warning in .err log. This causes troubles when migrating slave servers. There should be at least warning if not error in .err log.

Ideally mysql_upgrade script should take care of that and extract the data from mysql.slave_master_info and mysql.slave_relay_log_info to store them in master.info file.

Comment by Andrei Elkin [ 2020-01-29 ]

julien.fritsch: to why would it be possible to do.. - I merely offered an option if this feature request can be rated as a bug. After all no new option seem need to be provided for the user.

But now when I dwelt into the matter better, the ultimate goal's changes in the upgrade script do not look significant at all.
salle, how about executing a couple of sql queries on the MySQL slave side prior its ultimate stopping:

set @@global.master_info_repository='file';
set @@global.relay_log_info_repository='file';

I am not sure where to place those lines but the mysql_upgrade docs leaves hope we can
place them there and run the program twice - before and after the new binary are installed:

mysql_upgrade is run after starting the new MariaDB server. Running it before you shut down the old version will not hurt anything and will allow you to make sure it works and figure out authentication for it ahead of time.

Comment by Sujatha Sivakumar (Inactive) [ 2020-03-10 ]

Code changes: https://github.com/MariaDB/server/commit/9ae015878f11be3e3033fd1b35357ea5927c6c51

Build Bot testing: http://buildbot.askmonty.org/buildbot/grid?category=main&branch=bb-10.5-sujatha

Changes were reviewed and approved by Andrei.

Generated at Thu Feb 08 07:39:16 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.