Here is why.
In order to have full true load balancing, you need to have two or more MySQL database server replicating data to each other in real time. Currently your only choice is master-master replication.
master-master replication is not fast enough for real-time updates for a load-balanced environment. It is good enough for fail-over which is what we currently implement.
You can still have load-balancing in a distributed fashion. If you have two MySQL database servers for your cluster, and you designate half your databases for one server and half for the other, technically you are implementing "load balancing" as your distributing your data among two servers. Although this is not really the best practice. However in this setup, each server can be a fail-over for the other. So if one server fails the other takes over as master for it's databases.
fail-over recovery.
This is one issue worth considering. If your MySQL database server comes back online, LVS (Linux Virtual Server) wants to immediately throw it back in as master/primary. However, once the server is up, it needs time to get back up to date from the other master. So for recovery, you will need to perform this manually and not let LVS do this automatically. Bring the server back online, allow time for the replication to complete, then go to the LVS and set the server as active primary.
-RG
Kevin A. Burton wrote:
Was curious what people on the list are using for load balancing.. there are a number of techniques here but it would be interesting if people could share some real-world experiences....
HTTP load balancing is pretty well understood but there's not a bunch out there on MySQL load balancing
Kevin
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
