maria-discuss team mailing list archive

[Artem Russakovskii <archon810@xxxxxxxxx>]

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@xxxxxxxxxxxxxxx>
wrote:

> Artem Russakovskii <archon810@xxxxxxxxx> 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.
>