Port gtid_mode to wsrep_sst_xtrabackup in PXC 5.6

Bug #1228304 reported by Raghavendra D Prabhu on 2013-09-20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
MySQL patches by Codership
Status tracked in 5.6
Percona XtraDB Cluster moved to https://jira.percona.com/projects/PXC
Status tracked in 5.6
Fix Released

Bug Description

Requires backup of binary logs in that. Currently only wsrep_sst_rsync supports it.

no longer affects: percona-xtrabackup

Since this requires backup of binlog files, it will probably need to be done in Xtrabackup itself (hence will require an lp bug on PXB).

summary: - Port gtid_mode to wsrep_sst_xtrabackup
+ Port gtid_mode to wsrep_sst_xtrabackup in PXC 5.6

For copying the binlog files (currently only last file is

a) Can be done in xtrabackup but this requires changes to

b) Otherwise, needs to be done in wsrep_sst_xtrabackup, but since
only 2 stages of copying are done, this is not possible
currently, will require potentially invasive changes here.

There is another way,

xtrabackup_binlog_info contains gtid info, if this info
can be used directly in wsrep_sst_xtrabackup and in

One more thing, the rsync SST does a 'flush logs' so that binlog files are small (otherwise it will be really expensive to copy one binlog file to get the last event), this is not feasible with Xtrabackup SST. While it is possible, it is not the same since Xtrabackup is the one doing FTWRL here unlike in rsync SST where the same is done in mysqld, and 'flush logs' done under FTWRL. So, this either requires changes to Xtrabackup or setting the gtid_purged would be more prudent.

Alex Yurchenko (ayurchen) wrote :

Raghu, if I may, I'd like to put forth a proposition, that this should not be considered PXC or SST-related problem. And you should not look much at rsync SST.

xtrabackup promise is that it backs up the server. Implying that if you start mysqld on the resulting datadir, it will be an exact copy of the source at some point in time. This is a requirement for PITR for example. And exact copy means that all the necessary gtids should be there as well, not just innodb tablespace. And if MySQL insists on storing this data in the binlog file, then it looks like xtrabackup has no choice but to mimic this somehow. Be it a file copy or be it a forged binlog file. Once xtrabackup can make such backup, all the problems will be saved.


Xtrabackup doesn't backup the binlog files at the moment (since
it has not been required till now). But, it looks like for 5.6 we
are going to need this. I will raise an Xtrabackup lp request.

Equivalent of following would be required for PXB sst:

    if ! [ -z $WSREP_SST_OPT_BINLOG ]

        pushd $BINLOG_DIRNAME &> /dev/null
        if [ -f $BINLOG_TAR_FILE ]
            # Clean up old binlog files first
            rm -f ${BINLOG_FILENAME}.*
            wsrep_log_info "Extracting binlog files:"
            tar -xvf $BINLOG_TAR_FILE >&2
            for ii in $(ls -1 ${BINLOG_FILENAME}.*)
                echo ${BINLOG_DIRNAME}/${ii} >> ${BINLOG_FILENAME}.index
        popd &> /dev/null

Alex Yurchenko (ayurchen) wrote :

So it is copying all binlog files then?

Alex Yurchenko (ayurchen) wrote :

not applicable to 5.5


No, only the last binlog after 'Flush binary logs' under FTWRL.

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

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

Other bug subscribers