On Wednesday 24 January 2001 11:04, Steven Roussey wrote:
>> On the other hand, replication is a tried way
>> to scale read performance.
>What about scaling read _and_ write performance? Is there a plan for
>allowing multiple master replication, or some other method of clustering?
The problem with multiple master is that you have to write to **all**
masters, which means that the load is still the same. Scaling writes is a
very difficult problem, and I do not know of any general solution to it other
than more powerful hardware.
If you know something about the application, you can do tricks. For example,
if your application deals with users, and once you know the username, all
queries are localized to the data somehow associated with that user, you can
hash by username and for each hash value have a separate server. Thus your
web server first takes a quick look at the username calculating the hash, and
then connects to the appropriate server that has all the relevant info about
the user. To do global queries in the case is a little tricky, of course,
because you need to connect to all servers, gather the data, and then
post-process on the client, but is is a small price to pay for vitually
>Also related is how do we provide failover? If one machine goes down and
>repliction is active, then the slave can become the failover. But how do we
>bring the other server backup and take over master status?
The basic idea is once you have synced it with the current master:
CHANGE MASTER TO MASTER_HOST=new_master, MASTER_LOG_POS=start_pos,
on all machines. There are some ugly synchronization details. In 3.23.32
there is a secret function MASTER_POS_WAIT() that will wait until the slave
gets to a certain position, which can be used to syncronize a slave with the
snapshot of the master taken at a certain time. It does have a bug that I
have already fixed, so starting in 3.23.33 you can actually use it in your
MySQL Development Team
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Sasha Pachev <sasha@stripped>
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, http://www.mysql.com/
/_/ /_/\_, /___/\___\_\___/ Provo, Utah, USA