mysql replication 中slave機器上有兩個關鍵的進程，死一個都不行，一個是slave_sql_running，一個是Slave_IO_Running，一個負責與主機的io通信，一個負責自己的slave mysql進程。
1.如果是slave_io_running no了，那麼就我個人看有三種情況，一個是網絡有問題，連接不上，像有一次我用虛擬機搭 建replication，使用了nat的網絡結構，就是死都連不上，第二個是有可能my.cnf有問題，配置文件怎麼寫就不說了，網上太多了，最後一個是授權的問題，replication slave和file權限是必須的。
一旦io爲no了先看err日誌,如果是包太大收不了，這個時候主備上改max_allowed_packet這個參數。
例：
錯誤日誌：
100512 9:13:17 [Note] Slave I/O thread: connected to master '[email protected]:3306', replication started in log 'mysqlmaster.000079' at position 183913228
Slave_IO_Running爲No，從日誌上來看，服務器讀mysqlmaster.000079這個Log的183913228這個位置時發生錯誤，這個位置不存在，於是無法同步。
從新的日誌開始
SLAVE STOP;
CHANGE MASTER TO MASTER_LOG_FILE='mysqlcncnmaster.000080', MASTER_LOG_POS=0;
SLAVE START;
此時Slave_IO_Running恢復爲Yes.
2.如果是slave_sql_running no了，那麼也有兩種可能，一種是slave機器上這個表中出現了其他的寫操作，就是程序 寫了,這個是會有問題的。還有一種佔絕大多數可能的是slave進程重啓，事務回滾造成的，這也是mysql的一種自我 保護的措施，像關鍵時候只讀一樣。
這個時候想恢復的話，只要停掉slave，set GLOBAL SQL_SLAVE_SKIP_COUNTER=1;再開一下slave就可以了.