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.
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.