[Maria-discuss] Post-MySQL(5.6) to MariaDB migration question - why are master_info_repository=TABLE and relay_log_info_repository=TABLE not supported?
Hi, This is my first post to the mariadb list, as I just migrated from mysql to mariadb (OpenSUSE stopped supporting mysql after Leap 15.0). I immediately ran into an issue migrating, with the slave not starting. Upon further analysis, it turned out to be the lack of support of master_info_repository=TABLE and relay_log_info_repository=TABLE in mariadb, which means the master information effectively disappeared as far as the slave server is concerned. I am very surprised by this revelation. Not only did it break replication (I had to figure this out and reassemble the CHANGE MASTER TO command with the values fished out from the slave_master_info table), it also seems to be a step back when it comes to crash-safe replication. Does anyone have an explanation for why we're now back to master.info and relay-log.info on disk rather than nice tables in memory? See https://www.percona.com/blog/2013/09/13/enabling-crash-safe-slaves-with-mysq... from years ago for more info, for example. It'd be great to hear from the core mariadb/mysql developers. The lack of master_info_repository and relay_log_info_repository support is documented here: https://mariadb.com/kb/en/library/system-variable-differences-between-mariad... . Thank you. Sincerely, Artem
Artem Russakovskii <archon810@gmail.com> writes:
Upon further analysis, it turned out to be the lack of support of master_info_repository=TABLE and relay_log_info_repository=TABLE in mariadb, which means the master information effectively disappeared as far as the slave server is concerned.
the values fished out from the slave_master_info table), it also seems to be a step back when it comes to crash-safe replication.
Does anyone have an explanation for why we're now back to master.info and relay-log.info on disk rather than nice tables in memory?
In MariaDB, the replication position is stored crash-safe in a table (mysql.gtid_slave_pos) when using MariaDB global transaction ID. One problem with the way the MySQL relay_log_info_repository=TABLE feature is designed is that it makes it impossible for two transactions to update their position simultaneously. Thus it doesn't work well with parallel replication. That's one reason it is implemented differently in MariaDB. I agree it is unfortunate that this breaks mysql->mariadb migrations. Hope this helps, - Kristian.
Thank you for the explanation. Helpful. I'm guessing once all slaves and then the master are converted to mariadb, global transaction IDs are going to start getting used (or maybe I'll need to tweak some variables). Because right now it's empty on the one slave I converted. On Mon, Dec 24, 2018 at 1:33 AM Kristian Nielsen <knielsen@knielsen-hq.org> wrote:
Artem Russakovskii <archon810@gmail.com> writes:
Upon further analysis, it turned out to be the lack of support of master_info_repository=TABLE and relay_log_info_repository=TABLE in mariadb, which means the master information effectively disappeared as far as the slave server is concerned.
the values fished out from the slave_master_info table), it also seems to be a step back when it comes to crash-safe replication.
Does anyone have an explanation for why we're now back to master.info and relay-log.info on disk rather than nice tables in memory?
In MariaDB, the replication position is stored crash-safe in a table (mysql.gtid_slave_pos) when using MariaDB global transaction ID.
One problem with the way the MySQL relay_log_info_repository=TABLE feature is designed is that it makes it impossible for two transactions to update their position simultaneously. Thus it doesn't work well with parallel replication. That's one reason it is implemented differently in MariaDB.
I agree it is unfortunate that this breaks mysql->mariadb migrations.
Hope this helps,
- Kristian.
Artem Russakovskii <archon810@gmail.com> writes:
Thank you for the explanation. Helpful. I'm guessing once all slaves and then the master are converted to mariadb, global transaction IDs are going to start getting used (or maybe I'll need to tweak some variables). Because right now it's empty on the one slave I converted.
The first time the mariadb slave connects to the migrated mariadb master, the slave obtains the GTID corresponding to the current position. Then you can switch the slave to use GTID for future connections: CHANGE MASTER TO master_use_gtid=slave_pos - Kristian.
participants (2)
-
Artem Russakovskii -
Kristian Nielsen