Now we can start our two load balancers for the first time:
loadb1.example.com / loadb2.example.com:
/etc/init.d/ldirectord stop/etc/init.d/heartbeat start
If you don't see errors, you should now reboot both load balancers:
loadb1.example.com / loadb2.example.com:
shutdown -r now
After the reboot we can check if both load balancers work as expected :
loadb1.example.com / loadb2.example.com:
ip addr sh eth0
The active load balancer should list the virtual IP address (192.168.0.105):
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:16:3e:45:fc:f8 brd ff:ff:ff:ff:ff:ff inet 192.168.0.103/24 brd 192.168.0.255 scope global eth0 inet 192.168.0.105/24 brd 192.168.0.255 scope global secondary eth0
The hot-standby should show this:
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:16:3e:16:c1:4e brd ff:ff:ff:ff:ff:ff inet 192.168.0.104/24 brd 192.168.0.255 scope global eth0
loadb1.example.com / loadb2.example.com:
ldirectord ldirectord.cf status
Output on the active load balancer:
ldirectord for /etc/ha.d/ldirectord.cf is running with pid: 1603
Output on the hot-standby:
ldirectord is stopped for /etc/ha.d/ldirectord.cf
loadb1.example.com / loadb2.example.com:
ipvsadm -L -n
Output on the active load balancer:
IP Virtual Server version 1.2.1 (size=4096)Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConnTCP 192.168.0.105:3306 wrr -> 192.168.0.101:3306 Route 1 0 0 -> 192.168.0.102:3306 Route 1 0 0
Output on the hot-standby:
IP Virtual Server version 1.2.1 (size=4096)Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn
loadb1.example.com / loadb2.example.com:
/etc/ha.d/resource.d/LVSSyncDaemonSwap master status
Output on the active load balancer:
master running(ipvs_syncmaster pid: 1766)
Output on the hot-standby:
master stopped(ipvs_syncbackup pid: 1440)
If your tests went fine, you can now try to access the MySQL database from a totally different server in the same network (192.168.0.x) using the virtual IP address 192.168.0.105:
mysql -h 192.168.0.105 -u ldirector -p
(Please note: your MySQL client must at least be of version 4.1; older versions do not work with MySQL 5.)
You can now switch off one of the MySQL cluster nodes for test purposes; you should then still be able to connect to the MySQL database.
8 Annotations
There are some important things to keep in mind when running a MySQL cluster:
- All data is stored in RAM! Therefore you need lots of RAM on your cluster nodes. The formula how much RAM you need on ech node goes like this:
(SizeofDatabase × NumberOfReplicas × 1.1 ) / NumberOfDataNodes
So if you have a database that is 1 GB of size, you would need 1.1 GB RAM on each node!
- The cluster management node listens on port 1186, and anyone can connect. So that's definitely not secure, and therefore you should run your cluster in an isolated private network!
It's a good idea to have a look at the MySQL Cluster FAQ: http://dev.mysql.com/doc/refman/5.0/en/mysql-cluster-faq.html and also at the MySQL Cluster documentation: http://dev.mysql.com/doc/refman/5.0/en/ndbcluster.html
Links
MySQL: http://www.mysql.com/
MySQL Cluster documentation: http://dev.mysql.com/doc/refman/5.0/en/ndbcluster.html
MySQL Cluster FAQ: http://dev.mysql.com/doc/refman/5.0/en/mysql-cluster-faq.html
Ultra Monkey: http://www.ultramonkey.org/
The High-Availability Linux Project: http://www.linux-ha.org/