Percona XtraDB Cluster - HA scalable solution for MySQL

Port gtid_mode to wsrep_sst_xtrabackup in PXC 5.6

Reported by Raghavendra D Prabhu on 2013-09-20
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
MySQL patches by Codership
Status tracked in 5.6
5.5
Undecided
Unassigned
5.6
Undecided
Unassigned
Percona XtraDB Cluster
Status tracked in Trunk
5.6
Undecided
Unassigned
Trunk
Undecided
Unassigned

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
copied):

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

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
sst_joiner_thread

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.

@Alex,

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.
Thanks.

Equivalent of following would be required for PXB sst:

    if ! [ -z $WSREP_SST_OPT_BINLOG ]
    then

        pushd $BINLOG_DIRNAME &> /dev/null
        if [ -f $BINLOG_TAR_FILE ]
        then
            # 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}.*)
            do
                echo ${BINLOG_DIRNAME}/${ii} >> ${BINLOG_FILENAME}.index
            done
        fi
        popd &> /dev/null
    fi

Alex Yurchenko (ayurchen) wrote :

So it is copying all binlog files then?

Alex Yurchenko (ayurchen) wrote :

not applicable to 5.5

@Alex,

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

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

Other bug subscribers