Apologies if this has been asked before, but I can't seem to find much on it.

We're going to be using HAProxy to load balance our MariaDB Galera Cluster. All the articles/tutorials I have seen on this use Keepalived (or something similar) for an active/passive HAProxy setup.

Is there any good reason why you shouldn't have an active/active setup?

Each HAProxy node can have a fixed IP and both have a floating IP. Under normal conditions requests are shared between the two HAProxy nodes, if one goes down, the other takes it's floating IP and handles requests under both IPs. When the other comes back up it takes its floating IP and share of load back again.

I'd appreciate your opinions on this.



The important considerations not to have an active/active setup with two virtual IP addresses for the same resource is

  • how do you distribute requests over the two virtual IP's
  • how do you deal with sticky sessions, affinity, persistence and such, i.e. what happens when subsequent requests start off going to virtual IP1 and then go to virtual IP2 and do you need those to go the same back-end server.
  • what happens when the virtual IP-addresses fails over to the other host?
  • I appreciate your response. In my case I was intending to "randomly" pick one of the two virtual IPs to be the one to use to connect to the database with. If for some reason that fails, try the other (but it shouldn't fail for long if one does go down). In this case of a DB server, sticky sessions, etc are not as issue, but it is a good point with regard to other areas where it may need a work-around, or be a show-stopper. Regarding your third point, will Keepalived not try to bring the IP back when it's main node comes up again? – Luke Cousins Mar 18 '14 at 15:40
  • The MySQL Query Cache may be a good reason in some scenario's to maintain sticky sessions even with load balancing database queries. – HBruijn Mar 18 '14 at 16:05
  • That's an interesting point, that again I hadn't thought of. In our case we have the MySQL Query Cache disabled due it to being a single point of contention and a couple of other reasons (it slows down all selects, even most non-cachable ones, and all writes (invalidating caches)). Do you know of any other reasons why you would want MySQL stickiness? Thanks. – Luke Cousins Mar 18 '14 at 17:04
  • Any reason sourceIP hash stickyness shouldn't be sufficient here? We use this successfully. Of course, if quorum changes, the stickiness will be disrupted once. – namezero Oct 28 '18 at 18:18

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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