Since you have Master/Slave, you may want to implement the use of two things
- Circular Replication
- Database Virtual IP (aka DBVIP)
Circular Replication
Circular Replication is nothing more than first setting up Master/Slave then performing the same steps using the Slave as the Master's Master and the Master as the Slave's Slave. It just entails
- explicitly user a different server_id on each DB Server
- enabling binary logging on both DB servers
- making sure the replication user is defined on both DB servers
Database Virtual IP (aka DBVIP)
There are products you can download and install to setup a DBVIP. One such product I use is ucarp
. Another product is Linux Heartbeat. I normally do not use such things with MySQL Circular Replication or Master/Slave. Why?
Since those products can perform automatic failover, you do not want to do that in the event a Slave is some number of seconds behind in replication lag.
You should perform manual failovers.
Here is a poor man's approach to implementing DBVIP management.
Suppose you have this setup
- DB Server1 has IP 10.1.2.30
- DB Server2 has IP 10.1.2.40
- You want to use DBVIP 10.1.2.50
Create the Script called /usr/local/sbin/MyAppDBVIP like this
echo echo 10.1.2.50 > /usr/local/sbin/MyAppDBVIP
Create the Script called /usr/local/sbin/dbvip-up
DBVIP=`/usr/local/sbin/MyAppDBVIP`
ip addr add ${DBVIP}/24 dev eth1
Create the Script called /usr/local/sbin/dbvip-down
DBVIP=`/usr/local/sbin/MyAppDBVIP`
ip addr del ${DBVIP}/24 dev eth1
Make sure all scripts are executable
chmod +x /usr/local/sbin/MyAppDBVIP
chmod +x /usr/local/sbin/dbvip-up
chmod +x /usr/local/sbin/dbvip-down
Make sure these script exist on both DB Servers
Simply run dbvip on whichever server you choose. .
So the failover process and protocol are the following:
- Run
dbvip-down
on the DB Server that has the DBVIP. If you cannot
- Run
dbvip-up
on the DB Server that you want to have the DBVIP
- Just remember you should not run
dbvip-up
on both machines
- After running
dbvip-up
, restart apache, JBoss, or any other app server contacting MySQL via the old Master
Yes you can upgrade the Master's my.cnf file to handle the new environment.
I have an additional suggestion.
InnoDB prior to MySQL 5.1.38 cannot use multiple CPUs.
You can do one of two things that will not affect the Slave
- Upgrade to Percona Server 5.1
- MySQL 5.1.38 has InnoDB Plugin (dsiabled by default) which acceses mulitple CPUs
- If you have MySQL 5.1.37 or prior, upgrade to the latest MySQL 5.1 and install InnoDB Plugin
- If you have MySQL 5.1.38+, install InnoDB Plugin
Once you do, one of the above, you can configure the necessary options for accessing multiple CPUs
Best Answer
Let me give you a very broad piece of advise: I think you are trying optimisation in the wrong way. You are doing "We have spare memory, let's use it for something else" (which is otherwise very lucky and many people will envy you) instead of "let's identify our bottleneck and fix that with our resources".
I am not telling you that your idea is wrong, but in general, scaling out with slaves does not provide a better latency (and in many other cases, clustering it reduces it), but a better throughput (which if you were under high load, can sometimes mean better latency). I do not know if that is a problem that must be solved in your case. While having multiple mysql servers in the same machine is common, for example, in the hosting industry, they do not do it for performance, but for a cost-saving reason (consolidation). Also have into account that you may be more than doubling your maintenance/administration costs.
My real advice would be to identify your bottleneck: latency, throughput on where? Memory? Disk? Network? And try to use the extra resources in the best way- Are temporary tables being created? Can we use ramdisk for that? Are many queries too slow even if they are executed on memory? Can we setup a on-memory key-value cache system (memcache, by the way, integrated on MySQL 5.6-InnoDB) for caching results of frequent queries? Your write throughput is maximised? Maybe you need sharding. Your read throughput is maximised while your write throughput, network and disk bandwidth is low? Maybe your idea is ok. But you need metrics in order to support such an important architecture decision.