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.