Port gtid_mode to wsrep_sst_xtrabackup in PXC 5.6

[Raghavendra D Prabhu]

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

[Raghavendra D Prabhu (raghavendra-prabhu)]

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

[Raghavendra D Prabhu (raghavendra-prabhu)]

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

[Raghavendra D Prabhu (raghavendra-prabhu)]

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)]

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.

[Raghavendra D Prabhu (raghavendra-prabhu)]

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

[Raghavendra D Prabhu (raghavendra-prabhu)]

Reported it here https://bugs.launchpad.net/percona-xtrabackup/+bug/1250375

[Raghavendra D Prabhu (raghavendra-prabhu)]

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)]

So it is copying all binlog files then?

[Alex Yurchenko (ayurchen)]

not applicable to 5.5

[Raghavendra D Prabhu (raghavendra-prabhu)]

@Alex,

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

[Shahriyar Rzayev (rzayev-sehriyar)]

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