maria-discuss team mailing list archive
Mailing list archive
Re: MaxScale (lack of) resilience to Galera cluster changes
Apparently, I was doing something wrong! When I set
"available_when_donor=true" in the Galera Monitor section, it stopped
dropping the client connection (and thus losing the transaction) when I
stopped the non-write master database node.
Methinks I'll go off to re-read the documentation!
On 5 October 2017 at 14:32, Pak Chan <pakchan9000@xxxxxxxxx> wrote:
> Following on from my other thread, I'm testing MaxScale fronting a 2-node
> Galera cluster (with a Galera Arbitrator acting as the third node).
> My current test outline is as follows:
> 1. Identify the Write Master server in MaxScale
> 2. Connect two mysql clients to MaxScale, and put them both into "READ
> COMMITTED" isolation level ("set global transaction isolation level read
> 3. Begin a transaction in each client session
> 4. Take down the non-Write master node in the Galera cluster
> ("systemctl stop mysql" on that server)
> 5. Commit the transaction in client 1
> 6. Confirm that the clients can see the committed change
> 7. Start up the stopped node in the Galera cluster ("systemctl start
> mysql" on that server)
> 8. Commit the transaction in client 2
> 9. Confirm that the clients can see the committed change
> 10. ...
> What happens is that everything appear to work up until step 8, when
> client 2 loses its connection to the database when trying to commit,
> reconnects and loses its uncommitted transaction as a result. At step 9,
> client 1 announces that it has lost the connection and reconnects.
> Is this meant to happen?
> If I run the same test, bypassing MaxScale and connecting both clients
> directly to the same Galera node, I don't get the connection loss.
> I understand that MaxScale will route writes to one node and reads to
> another, but surely the loss of connection to a read node should not result
> in the loss of connection to the write node?
> Am I doing something wrong?
> Yours very puzzled.