On Mar 2, 2013, at 11:52 AM, Alex Yurchenko <email address hidden> wrote:
> The problem here is that this option is used in _automatic_ (read:
> unattended) node recovery: to pass a GTID value found via --wsrep-
> recover option from InnoDB table space. So it is not always user-
> supplied, and hence grastate.dat takes precedence, since InnoDB does not
> store DDL and other non-transactional GTIDs.
It's really not clear at what points grastate takes precedence over --wsrep_start_position.
AFAIK, there are three (maybe 4) possible grastate.dat states:
1) UUID set, seqno is >= 0, indicating either a clean shutdown, or someone manually tinkering with the file
2) UUID set, seqno is -1: indicating an unclean shutdown/crash
3) UUID zeroed: wsrep abort (?) (like lp:1111706?, and RBR errors?)
3) grastate.dat missing or unparseable: someone trying to build a node from a backup, someone manually tinkering with the file, or something horrible (filesystem corruption)
AFAICT, --wsrep_start_position only works in case #2, am I right?
I can accept that #3 would not accept wsrep_start_position, since RBR errors should trigger SST. However, there should be a clear log entry explaining why wsrep_start_position is getting ignored (in any and every case that it is ignored, BTW).
However, I think --wsrep_start_position should apply in #4 -- this would make manual node recovery (say from a backup) much easier, and if you wanted to try an auto-recovery in case of #3, all you would need to do is delete the grastate and let it try to recover.
On Mar 2, 2013, at 11:52 AM, Alex Yurchenko <email address hidden> wrote:
> The problem here is that this option is used in _automatic_ (read:
> unattended) node recovery: to pass a GTID value found via --wsrep-
> recover option from InnoDB table space. So it is not always user-
> supplied, and hence grastate.dat takes precedence, since InnoDB does not
> store DDL and other non-transactional GTIDs.
It's really not clear at what points grastate takes precedence over --wsrep_ start_position.
AFAIK, there are three (maybe 4) possible grastate.dat states:
1) UUID set, seqno is >= 0, indicating either a clean shutdown, or someone manually tinkering with the file
2) UUID set, seqno is -1: indicating an unclean shutdown/crash
3) UUID zeroed: wsrep abort (?) (like lp:1111706?, and RBR errors?)
3) grastate.dat missing or unparseable: someone trying to build a node from a backup, someone manually tinkering with the file, or something horrible (filesystem corruption)
AFAICT, --wsrep_ start_position only works in case #2, am I right?
I can accept that #3 would not accept wsrep_start_ position, since RBR errors should trigger SST. However, there should be a clear log entry explaining why wsrep_start_ position is getting ignored (in any and every case that it is ignored, BTW).
However, I think --wsrep_ start_position should apply in #4 -- this would make manual node recovery (say from a backup) much easier, and if you wanted to try an auto-recovery in case of #3, all you would need to do is delete the grastate and let it try to recover.
Jay Janssen, MySQL Consulting Lead, Percona about.me/ jay.janssen www.percona. com/live/ mysql-conferenc e-2013/
http://
Percona Live in Santa Clara, CA April 22nd-25th 2013
http://