One-time SHOW SLAVE STATUS
interpretation
Parsing the location of log files
It is true that GTID (Global Transaction Identifier) has been supported in MySQL 5.6, in addition, it can also be implemented by Tungsten replicator software (Google has been maintaining it since 2009, isn't it?).
But some people are still using the standard copy method of MySQL 5.5, so where are these binary log files? The SHOW SLAVE STATUS
results of the command output often confuse us, and it is time and time again.
This article tries to interpret SHOW SLAVE STATUS in a visual way.
About binary logs and relay logs
The main library (master) writes logs to binary files. A typical log file is mysql-bin.#####
or mysqld-bin.#####
(where #####
represents a string of numbers).
The slave node (slave, slave library) connects to the corresponding master node (master, master library), and reads entries from the binary log of the master library. Slaves write these entries to their own relay logs. A typical relay log file is mysql-relay.#####
or mysqld-relay.#####
(where #####
represents a string of numbers).
The relay log of the slave node has no corresponding relationship in name or quantity with the binary log of the master node. The storage location of the relay log has nothing to do with the storage location of the master node's binary log. Files are automatically flushed to disk and rolled; can vary in size depending on configuration. Of course, slaves keep track of the current relay-log entry: knowing which binary entry it matches from the master.
This is a very important knowledge point.
IO_THREAD
Fetch entries from nodes (via thread) and write to relay log, read relay log, and SQL_THREAD
replay those entries via thread).
So at each point in time, we are interested in the following "coordinates":
- Where to get data from the master node? From which file and where to get it.
- Where should the information be written? (this implies using the latest relay log file, and its size)
- The location of the currently executed slave query, the coordinates in the relay-log. The read position from the node is much smaller than the write position.
- The location of the currently executed slave query, the coordinates in the binary-log of the master node. This information tells us how far apart the master and slave are in sync.
From SHOW SLAVE STATUS
the output of , how do we interpret the above information?
Take two pictures as an example below.
The first picture, demonstrates the status of the slave keeping up with the master node.
The picture below, demonstrates the lagging slave state.
Hope this helps you.
原文链接: The “once and for all” SHOW SLAVE STATUS log files & positions explained
Original date: March 6, 2014
Date of translation: October 17, 2014
Translator: Iron Anchor: http://blog.csdn.net/renfufei