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.

  • 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

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.