Results tagged “high availability”

Before embarking on a MySQL Cluster installation, it is important to remember that MySQL Cluster is 'just' a storage engine for your existing MySQL database servers.  It stores data at the table level, not the whole database, it is therefore on the same functional level as MyISAM or INNODB.  You still need a standard MySQL server to access the table data and store the database information.  This has the fringe benefit that you can target specific tables to be saved to the cluster, rather than the whole database, if you have some tables that are either more important, or more heavily used.

In this article we are going to cover MySQL Cluster, it's installation on Debian (Lenny), Master-Master replication and how to tie all this together with HAProxy for a very high availability solution.
NB: At present you cannot request or share additional internal IP addresses with Rackspace Cloud, so you are going to have to use the external addresses.  With large databases this will incur additional bandwidth charges, be sure to evaluate this additional cost against the benefits provided by high availability.  When Rackspace allow the allocation of additional internal IPs, this article will be updated to reflect that.

Through two related tools and some cheap Rackspace Cloud servers, you can provide a front-end for your database that will balance between multiple replicated database servers and automatically failover if one of your balancers develops a fault.

This article will cover setting up heartbeat and pacemaker to handle the transfer of an IP from one machine to another on a failure and then another install of HAProxy on both boxes to balance the load between your database servers and cope with either of them failing.
To go with our Load Balanced Web Cluster, which provides good availability for your web services, providing high availability for your database is also likely to be an important requirement.  In most modern web apps, there's not much use having your webservers available constantly if your database is down.

There are a number of solutions to this with MySQL and every situation will require a different response, there are a lot of good articles out there to help you decide which solution is best. In this article we will be covering MySQL Master-Master replication and installation on Debian (Lenny) using Rackspace Cloud Servers.

The standard model of MySQL replication is a single master with multiple slaves, which provides you with very good read reliability, but writes can only be made to the master node.  This means that if the master fails, you can't just switch to another node and carry on as before, your slaves will become out of sync.  Additionally you can't load balance between your nodes for reads and writes.  By using a multiple master configuration, you can drop a node at any point and either switch your connection string to using the remaining master, or use load balancing and failover with HAProxy.
When we first wanted to load balance web servers, we initially followed Rackspace Cloud's articles on the subject. They recommended using mod_proxy with Apache.  This took a little while to set up and even with countless amounts of config changes, every now and then requests would get lost and you'd have to refresh your browser to get connected again.  This was not a problem in a development environment, but is unacceptable when we wanted to go live with the service.  So we looked for a different solution and found HAProxy, which was not only easier to set up than mod_proxy_balancer, but is tonnes more reliable and quicker too.
1