Hi Michael,
interesting points, I like the solution 2. which has two advantages, being configuration-less and elegant.
I'll check if I can implement it in the development branch.
Cheers
Guillaume
Current work is in https://github.com/mariadb-corporation/MaxScale/tree/MXS-109
Monitored nodes could be part of different cluster UUIDs: select only
the ones belonging to UUID with more joined nodes.
In case of different UUIDs, if the joined nodes number is less than (n_nodes
/ 2 ) + 1 don’t consider any node part of the cluster
MaxAdmin> show monitors
....
Galera Cluster UUID: c08b6deb-e933-11e6-bf35-bb1d2a329b2e
Galera Cluster size: 4
maxscale.log
2017-02-02 11:00:07 info : [galeramon] Galera cluster UUID is now c08b6deb-e933-11e6-bf35-bb1d2a329b2e with 4 members of 4 nodes
2 differents UUIDs
2017-02-02 12:30:40 debug : [galeramon] Candidate cluster member server1: UUID c08b6deb-e933-11e6-bf35-bb1d2a329b2e, joined nodes 2
2017-02-02 12:30:40 debug : [galeramon] Candidate cluster member server2: UUID fa7b0cab-e942-11e6-a67e-b669708bfe5a, joined nodes 2
2017-02-02 12:30:40 debug : [galeramon] Candidate cluster member server3: UUID c08b6deb-e933-11e6-bf35-bb1d2a329b2e, joined nodes 2
2017-02-02 12:30:40 debug : [galeramon] Candidate cluster member server4: UUID fa7b0cab-e942-11e6-a67e-b669708bfe5a, joined nodes 2
2017-02-02 12:30:40 error : [galeramon] Galera cluster cannot be set with 2 members of 4: not enough nodes (3 at least)
MaxAdmin> show monitors
.....
Galera Cluster NOT set: no member nodes
In case of 2 UUIDs if the user stops all the nodes of UUID_A (the good cluster), then nodes od UUID_B (the wrong one) will become part of the one Cluster MaxScale sees
I think that is correct behaviour. Excellent work! 