DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 

(mysql.info) show-slave-status

Info Catalog (mysql.info) set-global-sql-slave-skip-counter (mysql.info) replication-slave-sql (mysql.info) start-slave
 
 13.6.2.7 `SHOW SLAVE STATUS' Syntax
 ...................................
 
      SHOW SLAVE STATUS
 
 This statement 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 a semicolon
 to obtain 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
 
 `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 what the thread is doing:
      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. It is
      necessary to check this field for older versions of MySQL (prior
      to 5.0.12) because in these versions the thread could be running
      while unsuccessfully trying to connect to the master; only this
      field makes 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 can find the error in the
      `Last_Error' field (described below).
 
    * `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 containing the most recent
      event executed by the SQL thread.
 
    * `Slave_IO_Running'
 
      Whether the I/O thread is started and has connected successfully
      to the master. For older versions of MySQL (prior to 4.1.14 and
      5.0.12) `Slave_IO_Running' is `YES' if the I/O thread is started,
      even if the slave hasn't connected to the master yet.
 
    * `Slave_SQL_Running'
 
      Whether 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.
 
    * `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.
 
    * `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
      also appears 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 most recently 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
      stops executing.
 
    * `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 permitted
 
         * `No' if an SSL connection to the master is not permitted
 
         * `Ignored' if an SSL connection is permitted 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.
 
    * `Seconds_Behind_Master'
 
      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 most recent event on the
           master executed by that thread.
 
         * When the SQL thread thread has caught up to the slave I/O
           thread and goes idle waiting for more events from the I/O
           thread, this field is zero.
 
      In essence, this field measures the time difference in seconds
      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 is very close to the master, so this field is a
      good approximation of how late the slave SQL thread is compared to
      the master. If the network is slow, this is _not_ a good
      approximation; the slave SQL thread may quite often be caught up
      with the slow-reading slave I/O thread, so `Seconds_Behind_Master'
      often shows a value of 0, even if the I/O thread is late compared
      to the master. In other words, _this column is useful only for
      fast networks_.
 
      This time difference computation works even though the master and
      slave do not 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' is `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 the number of
      seconds given by the -master-connect-retry option before
      reconnecting, `NULL' is shown, as the slave cannot know what the
      master is doing, and so cannot say reliably how late it is.
 
      This field has one limitation. The timestamp is preserved through
      replication, which means that, if a master M1 is itself a slave of
      M0, any event from M1's binlog which originates in replicating an
      event from M0's binlog has the timestamp of that event. This
      enables MySQL to replicate `TIMESTAMP' successfully.  However, the
      drawback for `Seconds_Behind_Master' is that if M1 also receives
      direct updates from clients, the value randomly deviates, because
      sometimes the last M1's event is from M0 and sometimes it is the
      most recent timestamp from a direct update.
 
Info Catalog (mysql.info) set-global-sql-slave-skip-counter (mysql.info) replication-slave-sql (mysql.info) start-slave
automatically generated byinfo2html