Don't run wsrep-recover on first SST

[Raghavendra D Prabhu]

This adds a needless step: wsrep-recover creates ibdata1 and ib_logfile* files and the SST after that removes them - (which is slow and unnecessary)

The logic is that if datadir is empty, use "00000000-0000-0000-0000-000000000000:-1" directly.

[Raghavendra D Prabhu (raghavendra-prabhu)]

Actually fix for this is needed in this milestone, otherwise it breaks SST. So, fixed it.

[Raghavendra D Prabhu (raghavendra-prabhu)]

It broke SST only when xbstream is used, otherwise it didn't.

[Jay Janssen (jay-janssen)]

Actually, when I break it down, wsrep_recover's position (submitted via --wsrep_start_position) is *only* used when the grastate looks like this:

uuid:    9d241cd3-c46c-11e2-0800-81ab1e4b64e6
seqno:   -1

Why don't we make mysqld_safe check for this state (non-zero uuid and -1 seqno) before it decides to bother with wsrep_recover?

I would also submit that wsrep_recover should be tried when the grastate is simply missing, but galera won't auto-generate a grastate from only --wsrep_start_position yet (https://bugs.launchpad.net/galera/+bug/1112724).

[Jay Janssen (jay-janssen)]

Expounding on the above: --wsrep_start_position does not seem to apply when:

- uuid + seqno are set (and non-zero / -1)
- grastate is zeroed
- grastate is missing

Therefore, there is no point in running wsrep_recover automatically in those states.

[Raghavendra D Prabhu (raghavendra-prabhu)]

@Jay,

Yes, I will check into that. In this issue I was looking at only the empty datadir SST issue (and it was also breaking SST + xbstream + mysqld_safe). Hence, fixed this for this milestone itself. For the other cases, I will open a separate issue.

[Raghavendra D Prabhu (raghavendra-prabhu)]

Reported here https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1193781

[Raghavendra D Prabhu (raghavendra-prabhu)]

Regarding #4,

> - grastate is missing

This is the logic I am currently using to avoid wsrep-recover for
SST on empty directory. https://bazaar.launchpad.net/~raghavendra-prabhu/percona-xtradb-cluster/release-5.5.31/revision/433 for details.

[Alex Yurchenko (ayurchen)]

Just some food for thought: strictly speaking the user can configure grastate.dat file to be called differently and to be stored in a location different from mysql datadir. In fact, when we start to support multiple providers this will become a necessity. So ideally we must think of something better than checking a fixed file name.

[Raghavendra D Prabhu (raghavendra-prabhu)]

@Alexey,

Do you mean the wsrep_data_home_dir (for grastate.dat's location)? I will add it in lp:1193781.

Does the name of the file change? Currently it looks statically
set. If it is changed in future, I will change it in mysqld_safe
then.

[Alex Yurchenko (ayurchen)]

Yes, perhaps taking care of the wsrep_data_home_dir could be sufficient. But unchanged file name can't be guaranteed in future...

[Shahriyar Rzayev (rzayev-sehriyar)]

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