Status: To Do (View Workflow)
This was originally created as MDEV-18405.
Many users use Mariabackup to build slaves using the process outlined in the following documentation page:
One problem with this process is that Mariabackup doesn't back up and restore the original server's entire GTID state, which can be considered to be the value of gtid_current_pos.
The value of gtid_current_pos is constructed from the values of two other system variables--gtid_slave_pos and gtid_binlog_pos.
Mariabackup does back up and restores the original server's value for gtid_slave_pos, because that information is stored in mysql.gtid_slave_pos, which is an InnoDB table.
Mariabackup does not currently back up and restore the original server's gtid_binlog_pos, because that information is stored in the binary logs, which are not backed up.
This means that a server restored from a backup is missing some GTID state by default.
Mariabackup does back up the original server's value of gtid_current_pos in the xtrabackup_binlog_info file.
This means that if a user wants to build a slave using a backup, then they can restore the backup, and then they can extract the original server's gtid_current_pos from xtrabackup_binlog_info:
And then the user would need to use this value to set the value of gtid_slave_pos, and then they could set up replication:
Some users would prefer if the value of gtid_slave_pos would automatically be set to the original server's gtid_current_pos when a backup was prepared. That way, users would not have to worry about manually fixing the GTID state, and they could just set up replication from a slave created from a backup by doing something like this:
And the slave would automatically know where to start replicating from.