DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 

(mysql.info.gz) SHOW SLAVE STATUS

Info Catalog (mysql.info.gz) SET GLOBAL SQL_SLAVE_SKIP_COUNTER (mysql.info.gz) Replication Slave SQL (mysql.info.gz) START SLAVE
 
 13.6.2.7 `SHOW SLAVE STATUS' Syntax
 ...................................
 
      SHOW SLAVE STATUS
 
 Provides status information on essential parameters of the slave
 threads. If you issue this statement using the `mysql' client, you can
 use a `\G' statement terminator rather than semicolon to get a more
 readable vertical layout:
 
      mysql> SHOW SLAVE STATUS\G
      *************************** 1. row ***************************
             Slave_IO_State: Waiting for master to send event
                Master_Host: localhost
                Master_User: root
                Master_Port: 3306
              Connect_Retry: 3
            Master_Log_File: gbichot-bin.005
        Read_Master_Log_Pos: 79
             Relay_Log_File: gbichot-relay-bin.005
              Relay_Log_Pos: 548
      Relay_Master_Log_File: gbichot-bin.005
           Slave_IO_Running: Yes
          Slave_SQL_Running: Yes
            Replicate_Do_DB:
        Replicate_Ignore_DB:
                 Last_Errno: 0
                 Last_Error:
               Skip_Counter: 0
        Exec_Master_Log_Pos: 79
            Relay_Log_Space: 552
            Until_Condition: None
             Until_Log_File:
              Until_Log_Pos: 0
         Master_SSL_Allowed: No
         Master_SSL_CA_File:
         Master_SSL_CA_Path:
            Master_SSL_Cert:
          Master_SSL_Cipher:
             Master_SSL_Key:
      Seconds_Behind_Master: 8
 
 Depending on your version of MySQL, you may not see all the fields just
 shown. In particular, several fields are present only as of MySQL 4.1.1.
 
 `SHOW SLAVE STATUS' returns the following fields:
 
 `Slave_IO_State'
      A copy of the `State' field of the output of `SHOW PROCESSLIST'
      for the slave I/O thread. This tells you if the thread is trying
      to connect to the master, waiting for events from the master,
      reconnecting to the master, and so on. Possible states are listed
      in  Replication Implementation Details. Looking at this
      field is necessary because, for example, the thread can be running
      but unsuccessfully trying to connect to the master; only this field
      will make you aware of the connection problem.  The state of the
      SQL thread is not copied because it is simpler.  If it is running,
      there is no problem; if it is not, you will find the error in the
      `Last_Error' field (described below).
 
      This field is present beginning with MySQL 4.1.1.
 
 `Master_Host'
      The current master host.
 
 `Master_User'
      The current user used to connect to the master.
 
 `Master_Port'
      The current master port.
 
 `Connect_Retry'
      The current value of the `--master-connect-retry' option.
 
 `Master_Log_File'
      The name of the master binary log file from which the I/O thread is
      currently reading.
 
 `Read_Master_Log_Pos'
      The position up to which the I/O thread has read in the current
      master binary log.
 
 `Relay_Log_File'
      The name of the relay log file from which the SQL thread is
      currently reading and executing.
 
 `Relay_Log_Pos'
      The position up to which the SQL thread has read and executed in
      the current relay log.
 
 `Relay_Master_Log_File'
      The name of the master binary log file that contains the last
      event executed by the SQL thread.
 
 `Slave_IO_Running'
      Whether or not the I/O thread is started.
 
 `Slave_SQL_Running'
      Whether or not the SQL thread is started.
 
 `Replicate_Do_DB, Replicate_Ignore_DB'
      The lists of databases that were specified with the
      `--replicate-do-db' and `--replicate-ignore-db' options, if any.
 
      These fields are present beginning with MySQL 4.1.1.
 
 `Replicate_Do_Table, Replicate_Ignore_Table, Replicate_Wild_Do_Table, Replicate_Wild_Ignore_Table'
      The lists of tables that were specified with the
      `--replicate-do-table', `--replicate-ignore-table',
      `--replicate-wild-do-table', and `--replicate-wild-ignore_table'
      options, if any.
 
      These fields are present beginning with MySQL 4.1.1.
 
 `Last_Errno, Last_Error'
      The error number and error message returned by the most recently
      executed query.  An error number of 0 and message of the empty
      string mean "no error."  If the `Last_Error' value is not empty,
      it will also appear as a message in the slave's error log.
 
      For example:
 
           Last_Errno: 1051
           Last_Error: error 'Unknown table 'z'' on query 'drop table z'
 
      The message indicates that the table `z' existed on the master and
      was dropped there, but it did not exist on the slave, so `DROP
      TABLE' failed on the slave.  (This might occur, for example, if
      you forget to copy the table to the slave when setting up
      replication.)
 
 `Skip_Counter'
      The last used value for `SQL_SLAVE_SKIP_COUNTER'.
 
 `Exec_Master_Log_Pos'
      The position of the last event executed by the SQL thread from the
      master's binary log (`Relay_Master_Log_File').
      (`Relay_Master_Log_File', `Exec_Master_Log_Pos') in the master's
      binary log corresponds to (`Relay_Log_File', `Relay_Log_Pos') in
      the relay log.
 
 `Relay_Log_Space'
      The total combined size of all existing relay logs.
 
 `Until_Condition, Until_Log_File, Until_Log_Pos'
      The values specified in the `UNTIL' clause of the `START SLAVE'
      statement.
 
      `Until_Condition' has these values:
 
         * `None' if no `UNTIL' clause was specified
 
         * `Master' if the slave is reading until a given position in
           the master's binary logs
 
         * `Relay' if the slave is reading until a given position in its
           relay logs
 
      `Until_Log_File' and `Until_Log_Pos' indicate the log filename and
      position values that define the point at which the SQL thread will
      stop executing.
 
      These fields are present beginning with MySQL 4.1.1.
 
 `Master_SSL_Allowed, Master_SSL_CA_File, Master_SSL_CA_Path, Master_SSL_Cert, Master_SSL_Cipher, Master_SSL_Key'
      These fields show the SSL parameters used by the slave to connect
      to the master, if any.
 
      `Master_SSL_Allowed' has these values:
 
         * `Yes' if an SSL connection to the master is allowed
 
         * `No' if an SSL connection to the master is not allowed
 
         * `Ignored' if an SSL connection is allowed but the slave
           server does not have SSL support enabled
 
      The values of the other SSL-related fields correspond to the
      values of the `--master-ca', `--master-capath', `--master-cert',
      `--master-cipher', and `--master-key' options.
 
      These fields are present beginning with MySQL 4.1.1.
 
 `Seconds_Behind_Master'
      This field is present beginning with MySQL 4.1.1. It's been
      experimental and has been changed in MySQL 4.1.9. The following
      applies to slaves running MySQL 4.1.9 or newer.  This field is an
      indication of how "late" the slave is.  When the slave SQL thread
      is actively running (processing updates), this field is the number
      of seconds that have elapsed since the timestamp of the last
      master's event executed by that thread. When that thread has
      caught up on the slave I/O thread and goes idle waiting from more
      events from the I/O thread this field is zero.  To sum up, this
      field measures in seconds the time difference between the slave
      SQL thread and the slave I/O thread.
 
      If the network connection between master and slave is fast, the
      slave I/O thread will be very close to master, so this field will
      be a good approximation of how late the slave SQL thread is
      compared to the master.  If the network is slow, this will *not*
      be a good approximation; slave SQL thread may quite often be
      caught up with the slow-reading slave I/O thread, so
      `Seconds_Behind_Master' will often show a value of 0, even if I/O
      thread is late compared to master. In other words, *this column is
      useful only for fast networks*.
 
      This time difference computation will work even though your master
      and slave don't have identical clocks (the clock difference is
      computed when the slave I/O thread starts, and assumed to remain
      constant from then on).  `Seconds_Behind_Master' will be `NULL'
      (which means "unknown") if the slave SQL thread is not running, or
      if the slave I/O thread is not running or not connected to master.
      For example if the slave I/O thread is sleeping for
      `master-connect-retry' seconds before reconnecting, `NULL' will be
      shown, as the slave cannot know what the master is doing, so cannot
      reliably say how late it is.
 
      This field has one limitation. Indeed the timestamp is preserved
      through replication, which means that if your master M1 is itself
      a slave of M0, any event from M1's binlog which has its origin in
      replication of an event of M0's binlog, has the timestamp of that
      last event. This enables MySQL to replicate `TIMESTAMP'
      successfully. But the drawback for `Seconds_Behind_Master' is that
      if M1 also receives direct updates from clients, then the value
      will randomly go up and down, because sometimes the last M1's
      event will be from M0 and sometimes it will be from a direct
      update, and so will be the last timestamp.
 
 
Info Catalog (mysql.info.gz) SET GLOBAL SQL_SLAVE_SKIP_COUNTER (mysql.info.gz) Replication Slave SQL (mysql.info.gz) START SLAVE
automatically generated byinfo2html