Not the answer you need?
Register and ask your own question!

3 node outage scenario plus long query block question

patonbikepatonbike EntrantCurrent User Role Beginner
1) 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?

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

Comments

  • patonbikepatonbike Entrant Current User Role Beginner
    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?
  • lorraine.pocklingtonlorraine.pocklington Percona Community Manager Legacy User Role Patron
    Hello there

    Does this answer question one? https://www.percona.com/blog/2015/06/12/percona-xtradb-cluster-quorum-availability-cluster/

    Meanwhile I will see if anyone has suggestions about question 2.
  • patonbikepatonbike Entrant Current User Role Beginner
    Yes that is really helpful for #1. Thanks so much..
  • jdlawriejdlawrie Entrant Current User Role Contributor
    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.
Sign In or Register to comment.

MySQL, InnoDB, MariaDB and MongoDB are trademarks of their respective owners.
Copyright ©2005 - 2020 Percona LLC. All rights reserved.