xtrabackup_galera_info to grastate.dat

[Raghavendra D Prabhu]

innobackupex --apply-log can be made to generate grastate.dat from xtrabackup_galera_info to avoid manual creation of the file.

[Alex Yurchenko (ayurchen)]

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?

[Raghavendra D Prabhu (raghavendra-prabhu)]

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

[Jay Janssen (jay-janssen)]

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.

[Jay Janssen (jay-janssen)]

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.

[Alex Yurchenko (ayurchen)]

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

[Raghavendra D Prabhu (raghavendra-prabhu)]

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.

[Raghavendra D Prabhu (raghavendra-prabhu)]

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.

[Raghavendra D Prabhu (raghavendra-prabhu)]

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

[Raghavendra D Prabhu (raghavendra-prabhu)]

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

[Shahriyar Rzayev (rzayev-sehriyar)]

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