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
I addressed something like back on June 14, 2012 : Configured MySQL replication but its not working
The basic problem may be the queries you are using
If you have a query that looks like this
INSERT INTO db1.tb SELECT * FROM db2.tb;
You could be potentially blocking queries of this nature
Queries like this:
USE db1
INSERT INTO tb SELECT * FROM db2.tb;
should work if you have replicate-do-db=db1
and Replicate-wild-do-table=db.%
To be sure, check out the replication filtering rules to make sure your queries are allowing your current settings to work on the Slave.
According to the replication filtering rules
To make it easier to determine what effect an option set will have, it
is recommended that you avoid mixing “do” and “ignore” options, or
wildcard and nonwildcard options. An example of the latter that may
have unintended effects is the use of --replicate-do-db and
--replicate-wild-do-table together, where --replicate-wild-do-table uses a pattern for the database name that matches the name given for
--replicate-do-db. Suppose a replication slave is started with --replicate-do-db=dbx --replicate-wild-do-table=db%.t1. Then, suppose that on the master, you issue the statement CREATE DATABASE dbx.
Although you might expect it, this statement is not replicated because
it does not reference a table named t1.
Perhaps you need to get rid of one of those rules on the Slave and restart mysql on the Slave.
Best Answer
The only other way would be at the application level but it will be a little messy.
TECHNIQUE #1
In your application, you can prevent replication of an
INSERT
of any table as follows:You would surround SQL statement or transaction with
SET sql_log_bin = 0;
andSET sql_log_bin = 1;
.TECHNIQUE #2
Another way (less code editing) would be to run
SET sql_log_bin = 0;
as the first statement after establishing a persistent DB Connection.You would then need to enable binary logging for the table you want replicated like this:
EPILOGUE
Obviously, TECHNIQUE #2 would be best. However, you would still need to deploy the code changes for this. You must make sure you have persistent DB Connections. You would also need to test this if you are using Connection Pooling.
UPDATE 2019-06-01 21:57 EDT
replicate-do-table must be setup on a slave, not a master.
In your particular situation, there is just one major problem: This option was first created in MySQL 5.6. It is also available in MySQL 5.7 and MySQL 8.0.
You had posted the same question in another post (which I closed). In that post, you specified MySQL 5.1. replicate-do-table does not exist in MySQL 5.1 or MySQL 5.5. This make my somewhat convoluted answer more applicable because MySQL 5.1 does not have this option.
You could just update Master and Slave to MySQL 5.6 and then setup the replication-do-table on the slave to your heart's content.
CAUTION
You may want to not use such filtering if you only have one slave. The use of only one slave makes it virtually impossible to perform any kind of point-in-time recovery using a slave. See Percona Blog "Why MySQL’s binlog-do-db option is dangerous" on this. Even though the Blog in 10 years old, it still applies.
If you do upgrade Master and Slave to MySQL 5.6, get a second slave. Setup one slave with no filters and the second slave with replication-do-table.
If you cannot upgrade MySQL, then you must go with the application-level techniques I first suggested. At least it will allow Master and Slave to be identical in data content.
Upgrading to MySQL 5.6 is actually the best option.