Get the interpretation of `SHOW SLAVE STATUS` at once

One-time SHOW SLAVE STATUSinterpretation

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 STATUSresults 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_THREADFetch entries from nodes (via thread) and write to relay log, read relay log, and SQL_THREADreplay 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 STATUSthe 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.

insert image description here

The picture below, demonstrates the lagging slave state.

insert image description here

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

Guess you like

Origin blog.csdn.net/renfufei/article/details/129269891