Galera support - Githubissues

openark / orchestrator

MySQL replication topology management and HA

Apache License 2.0

5.64k stars 933 forks source link

Galera support #55

Open ManjotS opened 7 years ago

ManjotS commented 7 years ago

Code that checks for slaves and comasters should also check ws_rep variables and recognize galera nodes as comasters (that can't be dragged or demoted)

arvenil commented 7 years ago

This seems like a rather easy change to do or no? Could you point me in the code what func you think should be changed? I might take a look.

shlomi-noach commented 7 years ago

@arvenil you're looking at instance.go and instance_dao.go for defining, reading and writing the appropriate variables.

More complex issues are:

[ ] how to deterministically identify a representative co-master that will be the "cluster master" (right now orchestrator identifies a cluster by a single master node.
[ ] how to visualize a 3/5 node cluster in d3?
[ ] should orchestrator manage failovers?
- If so, how so?
- if not, make sure orchestrator does not handle failovers for galera

I'll add more bullets if I think of something else.

alphaDev23 commented 6 years ago

Is there any update on this functionality?

ManjotS commented 6 years ago

how to deterministically identify a representative co-master that will be the "cluster master" (right now orchestrator identifies a cluster by a single master node.

How is it currently identified in master-master topologies? one of the masters is picked as the primary master. I think same can be done in this case (or see which is first in the average gcom url)

how to visualize a 3/5 node cluster in d3?

This should be done just like current master-master. Currently we see them as slaves of each other on the far left of the GUI. We would just add another 1-3 below the first 2 as additional masters.

should orchestrator manage failovers? If so, how so? if not, make sure orchestrator does not handle failovers for galera

IMO (and at least for the initial iteration) it should only handle failovers for asynchronous slaves. Galera doesn't need failover handling as all are masters.

At some point later, as part of another feature, orchestrator could run hooks based on node failure without doing anything to the cluster/masters itself.

shlomi-noach commented 6 years ago

How is it currently identified in master-master topologies? one of the masters is picked as the primary master. I think same can be done in this case (or see which is first in the average gcom url)

If the master/master setup is writable/read-only then the writabel master is picked. If it's writable/writable then the first master is picked, alphabetically sorted.