Xtrabackup doesn't log master co-ordinates while backup up MariaDB 10

[kedar]

Innobackupex provided with --slave-info doesn't log master's binlog co-ordinates instead it log's slave's binlog position.

Xtrabackup is being used with Holland backup framework.
Option --slave-info is provided.
Backup logs the GTID correctly though the binlog co-ordinates of master are not logged.

Xtrabackup 2.2.4
Mariadb10

[Nilnandan Joshi (nilnandan-joshi)]

Verified with MariaDB 10 and Xtrabackup 2.2.7.

root@desktop:/home/nilnandan/backup/2014-12-31_14-45-42# cat xtrabackup_slave_info
CHANGE MASTER TO master_use_gtid = slave_pos
root@desktop:/home/nilnandan/backup/2014-12-31_14-45-42#

With PS 5.6.21 and Xtrabackup 2.2.7, we can see like this.

root@desktop:/home/nilnandan/backup/2014-12-31_15-07-20# cat xtrabackup_slave_info
SET GLOBAL gtid_purged='2c827228-90cf-11e4-b877-00224db1c503:1-2';
CHANGE MASTER TO MASTER_AUTO_POSITION=1
root@desktop:/home/nilnandan/backup/2014-12-31_15-07-20#

Actually, in MariaDB, we need master binlog file and position to get GTID, also from backup, we can get the GTID.
i.e

nilnandan@desktop:~$ sudo innobackupex --user=root --password=msandbox --socket=/tmp/mysql_sandbox24026.sock --defaults-file=/home/nilnandan/sandboxes/rsandbox_mariadb-10_0_15/node1/my.sandbox.cnf --slave-info /home/nilnandan/backup/

...

innobackupex: Backup created in directory '/home/nilnandan/backup/2014-12-31_14-45-42'
innobackupex: MySQL binlog position: filename 'mysql-bin.000001', position 312, GTID of the last change '0-1-12'
innobackupex: MySQL slave binlog position: master host '127.0.0.1', gtid_slave_pos 0-1-12
141231 14:45:45 innobackupex: Connection to database server closed
141231 14:45:45 innobackupex: completed OK!
nilnandan@desktop:~$

So the slave_info should be,

SET GLOBAL gtid_slave_pos = '0-1-12';
CHANGE MASTER TO master_use_gtid=slave_pos;

Find more information here. https://mariadb.com/blog/enabling-gtids-server-replication-mariadb-100

[Peter McLarty (peter-mclarty)]

I hame mariadb 10.0.14
From my servers last backup
innobackupex: MySQL binlog position: filename 'mysql-bin.000024', position 883188569, GTID of the last change '0-148-29896064'

Setting the slave up as follows after recovery from the using xtrabackup to backup and restore should allow the new slave to identify to and recover correctly with the master not the slave it was recovered from

CHANGE MASTER TO MASTER_HOST = TruemasterIp/hostmname , MASTER_USER ='repluser', MASTER_PASSWORD = 'replpass';
SET GLOBAL gtid_slave_pos
CHANGE MASTER TO '0-148-29896064'
CHANGE MASTER TO master_use_gtid=slave_pos;
start slave;

Is the steps correct?
GTID isn't well documented as yet This may help others to understand the way to get a new slave created and get around this bug

[Peter McLarty (peter-mclarty)]

I have conducted some additional testing and found that unless log_slave_updates is on then this problem doesn't occur.
The replica create from the slave without this parameter or set to 0 correctly records the master info.

[kedar (k-vaijanapurkar)]

Greetings Peter,

Glad to know you're doing additional testing and checks. About usual restore, I posted it in my blog(#1) which was based on the documentation(#2). So normally when you restore the current and master gtid pos match so all you need to do is start replication, noted in blog.

Additionally, if log_slave_updates are OFF, I'd not think there is any need to log the co-ordinates too... do you agree?

Regards.

#1 - http://kedar.nitty-witty.com/blog/mariadb-slave-restore-using-gtid-xtrabackup-bug
#2 - https://mariadb.com/kb/en/mariadb/documentation/replication/standard-replication/global-transaction-id/#setting-up-from-backup

[Sergei Glushchenko (sergei.glushchenko)]

https://github.com/percona/percona-xtrabackup/pull/178
https://github.com/percona/percona-xtrabackup/pull/177

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXB-715