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

Bug #1404484 reported by kedar
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Percona XtraBackup moved to https://jira.percona.com/projects/PXB
Status tracked in 2.4
Won't Fix
Fix Released
Sergei Glushchenko
Fix Released
Sergei Glushchenko

Bug Description

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

Revision history for this message
Nilnandan Joshi (nilnandan-joshi) wrote :

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

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';

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

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 '', gtid_slave_pos 0-1-12
141231 14:45:45 innobackupex: Connection to database server closed
141231 14:45:45 innobackupex: completed OK!

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

Revision history for this message
Peter McLarty (peter-mclarty) wrote :

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

Revision history for this message
Peter McLarty (peter-mclarty) wrote :

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.

Revision history for this message
kedar (k-vaijanapurkar) wrote :

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?


#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

tags: added: i65672
Revision history for this message
Sergei Glushchenko (sergei.glushchenko) wrote :
Revision history for this message
Shahriyar Rzayev (rzayev-sehriyar) wrote :

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

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers