The warning about --log-slave-updates
will only apply if you had multiple intermediary 'Master/Slave' servers.
The warning is this (my emphasis):
Then it will write updates that it receives from Master to its own binary log. When Slave 2 changes from Master to Slave 1 as its master, it may receive updates from Slave 1 that it has already received from Master
But in your scenario, Slave 2
is not changing masters, it will still point to the same Master 2
server it always was at.
So now, in case of Master 1
failing, you will need to do two things:
- Make sure your applications point to
Master 2
- Follow the instructions on promoting one of the three slaves to be new
Master 2
- make sure to enable
--log-slave-updates
on the new Master 2
The traditional way would be to use pt-table-checksum and pt-table-sync
I like doing things a little different. I immediately run pt-table-sync
with the --sync-to-master --print
options.
Here is the --sync-to-master option
--sync-to-master
Treat the DSN as a slave and sync it to its master.
Treat the server you specified as a slave. Inspect SHOW SLAVE STATUS,
connect to the server’s master, and treat the master as the source and
the slave as the destination. Causes changes to be made on the master.
Sets --wait to 60 by default, sets --lock to 1 by default, and
disables --[no]transaction by default. See also --replicate, which
changes this option’s behavior.
Here is the --print option
--print
Print queries that will resolve differences.
If you don’t trust pt-table-sync, or just want to see what it will do, this is a good way to be safe. These queries are valid SQL and you can run them yourself if you want to sync the tables manually.
This, if you do something like this:
echo "SET SQL_LOG_BIN=0;" > /root/SQLChanges.sql
pt-table-sync --print --sync-to-master h=10.1.2.30,u=username,p=password >> /root/SQLChanges.sql
The file /root/SQLChanges.sql
will contain every change you need to execute on the Slave. Once you are satisfied with its contents, just execute the script on the Slave.
With regard to using LOAD DATA INFILE in Replication, @DTest answered this question about that. I further explained how mysql replicates LOAD DATA INFILE.
Best Answer
Queries on slave are being applied by system user, so doing show full processlist and queries running with system user are the ones executed by slave sql thread.
Moreover you can view relay logs with the help of mysqlbinlog utlity and replacing binlog file with relay log file.
You can also introduce triggers on processlist table in information_schema database in this way you would be able to capture queries.
To get current query as string use following statement.
To get queries using trigger a sample trigger is as follows.
First create table
logging_table
with column asvarchar(1024)
.Create triggers of your choice accordingly.
Hope it helps.