Percona XtraBackup moved to https://jira.percona.com/projects/PXB

xtrabackup_slave_info binary log coordinates not updated after using --apply-log

Asked by Patrick Zoblisein

Hi,

Using xtrabackup 1.6.3 and was trying to use the xtrabackup_slave_info file to clone a 2nd slave as described here: http://www.percona.com/doc/percona-xtrabackup/howtos/setting_up_replication.html

But it does not get updated after preparing the backup (innobackupex --apply-log <tardir>).

This is from the backup of the first slave:
cat xtrabackup_slave_info
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=1183048

Updated bin log coordinates from the --apply-log step:
InnoDB: Last MySQL binlog file position 0 1185145, file name ./mysql-bin.000001

When I establish replication from the cloned slave to the original master using the coordinates in the xtrabackup_slave_info file - I get replication errors as the cloned slave attempts to replay transactions which were contained in the "transaction log" that was applied.

This is easily resolvable by using the coordinates given in either the xtrabackup_binlog_pos_innodb file or at the end of the --apply-log output but the question is, based on the link describing how to clone a 2nd slave and the described usage of the --slave-info - is this a bug? Does it need to be fixed? Or am I missing something and not using it properly?

Thanks
Patrick

Question information

Language:
English Edit question
Status:
Answered
For:
Percona XtraBackup moved to https://jira.percona.com/projects/PXB Edit question
Assignee:
Alexey Kopytov Edit question
Last query:
Last reply:
Revision history for this message
Alexey Kopytov (akopytov) said : 		#1

Patrick,

On 07.01.12 1:35, Patrick Zoblisein wrote:
> When I establish replication from the cloned slave to the original master using the coordinates in the xtrabackup_slave_info file - I get replication errors as the cloned slave attempts to replay transactions which were contained in the "transaction log" that was applied.

I don't see how it's possible. xtrabackup_slave_info is written with all
tables locked with FLUSH TABLES WITH READ LOCK. The tables are not
unlocked until xtrabackup copies the redo log up to the FTWRL and exits.

Are you sure you are not using --no-lock?

>
> This is easily resolvable by using the coordinates given in either the xtrabackup_binlog_pos_innodb file or at the end of the --apply-log output but the question is, based on the link describing how to clone a 2nd slave and the described usage of the --slave-info - is this a bug? Does it need to be fixed? Or am I missing something and not using it properly?
>

I don't think coordinates in xtrabackup_binlog_pos_innodb can be used
like that. Those are binary log coordinates of the 1st slave, so they
have nothing to do with the master.

We have recently verified the procedure outlined at
http://www.percona.com/doc/percona-xtrabackup/howtos/setting_up_replication.html
and made a few tweaks (mostly clarifications) to it.

Anyway, it's hard to investigate your problem without having precise
commands used to clone the slaves.

Can you help with this problem?

Provide an answer of your own, or ask Patrick Zoblisein for more information if necessary.

To post a message you must log in.