How To Set Up A Load-Balanced MySQL Cluster With MySQL 5.1
This tutorial is based on Falko Timme's tutorial for MySQL Cluster 5.0. It shows how to configure a MySQL 5.1 cluster with five nodes: 1 x management, 2 x storage nodes and 2 x balancer nodes. This cluster is load-balanced by an Ultra Monkey package which provides heartbeat (for checking if the other node is still alive) and ldirectord (to split up the requests to the nodes of the MySQL cluster).
Read more...How To Set Up A Load-Balanced MySQL Cluster With MySQL 5.1
This tutorial is based on Falko Timme's tutorial for MySQL Cluster 5.0. It shows how to configure a MySQL 5.1 cluster with five nodes: 1 x management, 2 x storage nodes and 2 x balancer nodes. This cluster is load-balanced by an Ultra Monkey package which provides heartbeat (for checking if the other node is still alive) and ldirectord (to split up the requests to the nodes of the MySQL cluster).
Read more...Master-Master Replication With MySQL 5 On Fedora 8
This document describes how to set up master-master replication with MySQL 5 on Fedora 8. Since version 5, MySQL comes with built-in support for master-master replication, solving the problem that can happen with self-generated keys. In former MySQL versions, the problem with master-master replication was that conflicts arose immediately if node A and node B both inserted an auto-incrementing key on the same table. The advantages of master-master replication over the traditional master-slave replication are that you don't have to modify your applications to make write accesses only to the master, and that it is easier to provide high-availability because if the master fails, you still have the other master.
Read more...I've used it for a while to get high-availability from two NFS servers and I always recommend it in my scalability talk. It's awesome. (Heartbeat which is the "fail-over" software in the typical configuration isn't so great, more on that another time).
Anyway, being at the MySQL conference the context of course is "how can this be used for MySQL". Usually I prefer a simpler master-master replication setup for redundancy. Later in the afternoon Mats Kindahl (one of the replication developers) pointed out how the drbd setup is great for having a highly-available master in a more typical master-slave(*N) setup.
It's funny, just as I write this Paul Tuckfield from YouTube is giving a keynote and telling about the complicated stuff they were doing to deal with failure of their master in their replication system. :-)
If they used drbd the redundant masters would "share the disks" (but you have the content duplicated so there isn't even a disk SPOF). When the primary master fails, the second one would just start up and all the replication slaves wouldn't know the difference. Magic!