maria-discuss team mailing list archive

[Pak Chan <pakchan9000@xxxxxxxxx>]

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!

PC

On 5 October 2017 at 14:32, Pak Chan <pakchan9000@xxxxxxxxx> wrote:

> Hi,
>
> 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
>    committed")
>    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.
> PC
>