- I am trying to understand an outage scenario. Let’s say we have a 3 node cluster and all is well. Let’s pretend that 2 of the 3 nodes reboot simultaneously. Does the last node standing still continue functioning or does it “break” because the other 2 nodes are non existent (no quorum???).
If the last node standing DOES continue functioning, how do you bootstrap that last node standing without bringing it down and restarting into bootstrap mode so the other 2 can sync data from this node when they come back up? If the last node standing does NOT continue functioning, where does this leave us in terms of a recovery scenario?
- Let’s say we have reports which run very long selects. Do these need to occur on a 4th non cluster node (standard slave replication) in order to not block writes and/or reads on the cluster?
Thanks for your help.
Any words of wisdom? I am trying to figure out if I need to setup a 4th non cluster node with standard slave replication for long running selects for reporting - would these block writes and/or other writes if I put them on the cluster?
Hello there
Does this answer question one? [url]https://www.percona.com/blog/2015/06/12/percona-xtradb-cluster-quorum-availability-cluster/[/url]
Meanwhile I will see if anyone has suggestions about question 2.
Yes that is really helpful for #1. Thanks so much…
Hello,
With InnoDB/XtraDB (due to its MVCC), writes don’t block reads and reads never block anything.
As long as the SELECT is read-only (ie. not SELECT FOR UPDATE) the only issue you might find with it being long running is that the InnoDB undo logs might start to grow so that the SELECT can see a consistent view of the tables.
Also, if this SELECT is within a transaction that also writes at some point, it’s possible it could cause other writes to fail to get a lock, or it could be rolled back on commit.