xtrabackup_galera_info to grastate.dat

This is sorta dangerous. grastate.dat is not a part of the interface and has no specificaiton. It can change any time. In fact we were planning to add quite a lot of galera state there that xtrabackup can not know about.

What exactly is the use case for that?

I thought it would make the backup restore more convenient. But,
again, I wanted opinions on this. Thanks.

Alex: use-case is avoiding an SST with a backup you already have. Last I knew, wsrep_start_position did NOT work if the grastate.dat wasn't present and at least parseable by Galera. If you can fix that instead, then that's probably sufficient.

My take is if this bug is fix: https://bugs.launchpad.net/galera/+bug/1112724 then wsrep_recover will build a grastate.dat for us.

Jay, yes, that would be a more correct solution.

Currently as it stands, while restoring from backup, one needs to
manually create grastate.dat from xtrabackup_galera_info which is
not nice. This bug is to automatically generate grastate.dat from
xtrabackup_galera_info at apply-log stage.

Now, technically, wsrep-recover recovers the galera co-ordinates.
So why is grastate.dat needed (or the larger point of collecting galera-info from xtrabackup)? https://bugs.launchpad.net/galera/+bug/1112724 seems to be the issue.

""
Submitting a ---wsrep_start_position when the datadir does not have a grastate.dat not work -- it forces a zero state and SSTs instead.
""

So, if I have a backup without (grastate.dat created manually from xtrabackup_galera_info or grastate.dat already present) wsrep-recover may work but its co-ordinates are not taken.

If lp:1112724 is fixed, then I don't think we need any galera
specific stuff from xtrabackup (--galera-info). Also, assuming no DDL is run,
--no-lock can also be used. There will be no need for
xtrabackup_galera_info either.

@Alexey, any plans on lp:1112724? (seems to be only for galera
3.0 though)

So, in interim and for galera 2.x (PXC 5.x), I think generating grastate.dat from xtrabackup_galera_info may be good, and regarding the specification, since this change is non-invasive one, if it changes (and I presume it changes only in 3.x) then we can remove this.

From further investigations that I did, it looks like
xtrabackup_galera_info is not used on joiner other than:

cat ${MAGIC_FILE}

which outputs uuid:seqno.

Also, interestingly, the gtid passed on wsrep_sst_xtrabackup on
donor ends up being the uuid:seqno on the joiner after SST is
done.

Marking this issue closed since it is not required to create grastate.dat here.

If you are adding this, this will only help with backups of PXC node.

Also, if and when adding this, add it with an option to innobackupex (in addition to --apply-log), otherwise the grastate.dat generated from this will conflict with existing grastate.dat during SST and SST wil break (SST doesn't use grastate.dat).

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