I'm using mariadb10.1.37, wsrep_provider_version 25.3.24(r3825). On my dev cluster (2node+1arbitrator) I found the following behaviour:

node1: bootstrap new cluster (using galera_new_cluster, with pc.weight=3)
node2: join cluster (pc.weight=3)
arbitrator: join cluster (pc.weight =1)

So, I have a three node cluster, with total pc.weight of 7. Then I do:

arbitrator: shutdown garbd
node2: shutdown mysqld

At this point, I expect node1, being only node out of three still alive, should have lost wsrep_cluster_status=Primary status, and no longer accept writes.

Instead, I find wsrep_cluster_status = Primary, wsrep_cluster_size=1, and yet node1 will still accept writes.

Is there something I am missing?

Thanks in advance!

  • 2
    Sounds like a bug. File it with MariaDB.
    – Rick James
    Nov 7, 2018 at 18:56
  • Thanks Rick - I'm going to try to reproduce again with fresh instances, and then I will submit a bug.
    – Mark S
    Nov 7, 2018 at 20:33
  • Good. (And post the bug number here.)
    – Rick James
    Nov 7, 2018 at 21:10

1 Answer 1


I don't think this is a bug. Its an expected behaviour interms of normal shutdown scenario. If you are practicing split-brain testcases then it makes sense for it to loose its Primary status.

In your case the clear information about their neighbouring voters exit status is communicated. And thus software lets it to serve the requests to the node1 that is alive, since the status of other nodes are shutdown and that is communicated to node1.

Try to execute Split-Brain scenario by isolating the node1 from node2+arbitor link and then you should find node1 losing its primary status and node2 wins while arbiter voting by its side.

  • Thanks Mannoj, yes more testing yesterday led me to the same conclusion.
    – Mark S
    Nov 8, 2018 at 19:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.