1

While evaluating the galera cluster, on the documentation it mentions that all cluster members should be listed on the "wsrep_cluster_address" setting...

This doesn't seem very scalable to me as adding a new node would mean having to reconfigure all existing nodes.

Is it so? or is there any way of not having to specify all nodes on that variable?

  • 1
    "Elasticity" makes sense for web servers, which are mostly "stateless". For databases, it is all about "state", namely the "data". So, changing the number of DB nodes comes at a cost. Still, Galera is very good (but not free) at being "elastic". Adding a node effectively ties up another node's I/O to copy the data over. Suggest you always keep one node more that the traffic warrants. (And never less than 3.) – Rick James Aug 26 '16 at 19:14
  • 1
    You might appreciate my Galera tips – Rick James Aug 26 '16 at 19:27
  • 1
    Back to your question... I would write a script (Perl or otherwise) to discover the list of nodes and add/subtract one. This would be part of your expand/contract script. – Rick James Aug 26 '16 at 19:29
  • 1
    HAProxy (and any of several competing tools) is likely to be a good idea for routing data to the Galera nodes. And it provides a single place for telling the clients where the nodes are. Do not blindly split reads vs writes; be aware of the "critical read" case. – Rick James Aug 26 '16 at 20:06
  • 1
    I have not heard of more than 6 nodes in a single cluster. Percona's blog seems reasonable, but your Cloud vendor may not allow multicast -- check on that before considering it. – Rick James Aug 26 '16 at 20:10
1

EDIT:

My original answer below is still correct, but the is an easier way to handle this: multicast. I didn't mention this before because I thought galera could only use multicast for replication, which is probably something else you probably want to configure to save bandwidth with a large number of nodes. Basically, you can use a multicast address for the cluster connection in wsrep_cluster_address. Using multicast will allow you to configure a single address on every node. I'm using multicast for replicating data in my galera cluster, but unicast for the cluster connection. The page I link to doesn't say anything explicitly about it, but you might need to configure a different multicast address for the galera data replication channel (gmcast.mcast_addr) and the cluster information channel (wsrep_cluster_address). More information on using multicast with galera is available in a Percona blog post.

Original:

It is not required to have every node in the cluster defined in wsrep_cluster_address. When a node starts up, it tries to connect to the provided addresses to connect to an existing cluster and then connect to all of the other current nodes in the cluster. It only really needs to connect to a single node in the cluster to join since it connects to other nodes based on the current state of the cluster. Because of that, if you specify a few nodes that should always be in the cluster, you should be fine even if there are many other nodes that are not specified.

| improve this answer | |
  • Thanks for the reply G-Nugget. That would mean I would always need to know and keep active a few, always online monitor nodes. I am trying to understand if i can avoid that at all (Prior knowlege of which ones are up). Would putting a Load balancer with a "Virtual IP" such as HAproxy in front of the monitor nodes suffice the need to know which monittor is up? Doing that would mean that the configuration could be static (with the Virtual IP) which then would serve as a "router" to currently active nodes? – Onitlikesonic Aug 25 '16 at 18:34
  • 1
    @Onitlikesonic I updated my answer with information on using multicast with galera, that is a much better solution for your situation. – G-Nugget Aug 26 '16 at 15:39
0

Actually specifying all members in wsrep_cluster_address is highly recommended but not mandatory - here is an extraction from official documentation:

"The new node only needs to connect to one of the existing cluster nodes. Once it connects to one of the existing cluster nodes, it will be able to see all of the nodes in the cluster. However, it is generally better to list all nodes of the cluster in wsrep_cluster_address, so that any node can join a cluster by connecting to any of the other cluster nodes, even if one or more of the cluster nodes are down"

See documentation

I saw such implementation in kubernetes Galera multi-master setups - the wsrep_cluster_address is set to dns name of k8s service instead of specifying all dns names of the pods (it is possible that IP address of the pod is changed however Galera will still try to connect to old IP)

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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