mysql 數(shù)據(jù)同步 出現(xiàn)Slave_IO_Running:No問(wèn)題的解決方法小結(jié)
更新時(shí)間：2011年05月25日 17:47:13 作者：
mysql replication 中slave機(jī)器上有兩個(gè)關(guān)鍵的進(jìn)程，死一個(gè)都不行，一個(gè)是slave_sql_running，一個(gè)是Slave_IO_Running，一個(gè)負(fù)責(zé)與主機(jī)的io通信，一個(gè)負(fù)責(zé)自己的slave mysql進(jìn)程。
下面寫(xiě)一下，這兩個(gè)要是有no了，怎么恢復(fù)。。
如果是slave_io_running no了，那么就我個(gè)人看有三種情況，一個(gè)是網(wǎng)絡(luò)有問(wèn)題，連接不上，像有一次我用虛擬機(jī)搭建replication，使用了nat的網(wǎng)絡(luò)結(jié)構(gòu)，就是死都連不上，第二個(gè)是有可能my.cnf有問(wèn)題，配置文件怎么寫(xiě)就不說(shuō)了，網(wǎng)上太多了，最后一個(gè)是授權(quán)的問(wèn)題，replication slave和file權(quán)限是必須的。如果不怕死就all咯。。
一旦io為no了先看err日志，看看爆什么錯(cuò)，很可能是網(wǎng)絡(luò)，也有可能是包太大收不了，這個(gè)時(shí)候主備上改max_allowed_packet這個(gè)參數(shù)。
如果是slave_sql_running no了，那么也有兩種可能，一種是slave機(jī)器上這個(gè)表中出現(xiàn)了其他的寫(xiě)操作，就是程序?qū)懥?，這個(gè)是會(huì)有問(wèn)題的，今天我想重現(xiàn)，但是有時(shí)候會(huì)有問(wèn)題，有時(shí)候就沒(méi)有問(wèn)題，現(xiàn)在還不是太明了，后面再更新，還有一種占絕大多數(shù)可能的是slave進(jìn)程重啟，事務(wù)回滾造成的，這也是mysql的一種自我保護(hù)的措施，像關(guān)鍵時(shí)候只讀一樣。
這個(gè)時(shí)候想恢復(fù)的話，只要停掉slave，set GLOBAL SQL_SLAVE_SKIP_COUNTER=1;再開(kāi)一下slave就可以了，這個(gè)全局變量賦值為N的意思是：
This statement skips the next N events from the master. This is useful for recovering from replication stops caused by a statement.
This statement is valid only when the slave thread is not running. Otherwise, it produces an error.
呵呵，講的比我清楚。
MYSQL鏡像服務(wù)器因錯(cuò)誤停止的恢復(fù)
下午主服務(wù)器，由于一些原因，導(dǎo)致死機(jī)，重啟后，發(fā)現(xiàn)從服務(wù)器的數(shù)據(jù)沒(méi)有跟上。
配好MYSQL主從也才前幾天的事，沒(méi)多少經(jīng)驗(yàn)，第一次碰上這問(wèn)題，有點(diǎn)焦急。不過(guò)，自己試了下，還算解決了：）
從服務(wù)器上
Master_Log_File: mysqlhxmaster.000007
Read_Master_Log_Pos: 84285377
看一下主服務(wù)器：mysqlhxmaster.000007 | 84450528 |
已經(jīng)過(guò)后很多了，確實(shí)沒(méi)跟上。
show slave status\G
Slave_IO_Running: Yes
Slave_SQL_Running: No
有問(wèn)題了，Slave_SQL_Running應(yīng)該是Yes才對(duì)。
再往下看，有錯(cuò)誤的提示：
Last_Errno: 1053
Last_Error: Query partially completed on the master (error on master: 1053) and was aborted. There is a chance that your master is inconsistent at this point. If you are sure that your master is ok, run this query manually on the slave and then restart the slave with SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE; . Query: 'INSERT INTO hx_stat_record ......(一句SQL語(yǔ)句)'
這里有說(shuō)明要怎么操作了：）
先stop slave，然后執(zhí)行了一下提示的語(yǔ)句，再SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE;
show slave status\G
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
OK了，從服務(wù)器也在幾分鐘內(nèi)把堆積的log處理完了，兩邊又同步了：)
從MYSQL服務(wù)器Slave_IO_Running: No的解決2
早晨機(jī)房意外斷電，導(dǎo)致了發(fā)現(xiàn)mysql從服務(wù)器同步異常。使用以前碰到的Slave_SQL_Running為No的解決辦法無(wú)效，仍然無(wú)法同步。
查看一下?tīng)顟B(tài)show slave status
Master_Log_File: mysqlmaster.000079
Read_Master_Log_Pos: 183913228
Relay_Log_File: hx-relay-bin.002934
Relay_Log_Pos: 183913371
Relay_Master_Log_File: mysqlmaster.000079
Slave_IO_Running: No
Slave_SQL_Running: Yes
主服務(wù)器show master status\G
File: mysqlmaster.000080
Position: 13818288
Binlog_Do_DB:
Binlog_Ignore_DB: mysql,test
mysql錯(cuò)誤日志：
100512 9:13:17 [Note] Slave SQL thread initialized, starting replication in log 'mysqlmaster.000079' at position 183913228, relay log './hx-relay-bin.002934' position: 183913371
100512 9:13:17 [Note] Slave I/O thread: connected to master 'replicuser@192.168.1.21:3306', replication started in log 'mysqlmaster.000079' at position 183913228
100512 9:13:17 [ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236)
100512 9:13:17 [ERROR] Got fatal error 1236: 'Client requested master to start replication from impossible position' from master when reading data from binary log
100512 9:13:17 [Note] Slave I/O thread exiting, read up to log 'mysqlmaster.000079', position 183913228
這次是Slave_IO_Running為No，從日志上來(lái)看，服務(wù)器讀mysqlmaster.000079這個(gè)Log的183913228這個(gè)位置時(shí)發(fā)生錯(cuò)誤，這個(gè)位置不存在，于是無(wú)法同步。
查看一下這個(gè)Log的最后幾行：
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
# at 4
#100511 9:35:15 server id 1 end_log_pos 98 Start: binlog v 4, server v 5.0.27-standard-log created 100511 9:35:15
# Warning: this binlog was not closed properly. Most probably mysqld crashed writing it.
嘗試從損壞之前的位置開(kāi)始
SLAVE STOP;
CHANGE MASTER TO MASTER_LOG_FILE='mysqlcncnmaster.000079', MASTER_LOG_POS=183913220;
SLAVE START;
無(wú)效！
只好從新的日志開(kāi)始
SLAVE STOP;
CHANGE MASTER TO MASTER_LOG_FILE='mysqlcncnmaster.000080', MASTER_LOG_POS=0;
SLAVE START;
此時(shí)Slave_IO_Running恢復(fù)為Yes，同步進(jìn)行了！觀察了會(huì)兒，沒(méi)有任何出錯(cuò)跡象，問(wèn)題解決。
另外，出現(xiàn)Slave_IO_Running:NO還有一個(gè)原因是slave上沒(méi)有權(quán)限讀master上的數(shù)據(jù)。
如果是slave_io_running no了，那么就我個(gè)人看有三種情況，一個(gè)是網(wǎng)絡(luò)有問(wèn)題，連接不上，像有一次我用虛擬機(jī)搭建replication，使用了nat的網(wǎng)絡(luò)結(jié)構(gòu)，就是死都連不上，第二個(gè)是有可能my.cnf有問(wèn)題，配置文件怎么寫(xiě)就不說(shuō)了，網(wǎng)上太多了，最后一個(gè)是授權(quán)的問(wèn)題，replication slave和file權(quán)限是必須的。如果不怕死就all咯。。
一旦io為no了先看err日志，看看爆什么錯(cuò)，很可能是網(wǎng)絡(luò)，也有可能是包太大收不了，這個(gè)時(shí)候主備上改max_allowed_packet這個(gè)參數(shù)。
如果是slave_sql_running no了，那么也有兩種可能，一種是slave機(jī)器上這個(gè)表中出現(xiàn)了其他的寫(xiě)操作，就是程序?qū)懥?，這個(gè)是會(huì)有問(wèn)題的，今天我想重現(xiàn)，但是有時(shí)候會(huì)有問(wèn)題，有時(shí)候就沒(méi)有問(wèn)題，現(xiàn)在還不是太明了，后面再更新，還有一種占絕大多數(shù)可能的是slave進(jìn)程重啟，事務(wù)回滾造成的，這也是mysql的一種自我保護(hù)的措施，像關(guān)鍵時(shí)候只讀一樣。
這個(gè)時(shí)候想恢復(fù)的話，只要停掉slave，set GLOBAL SQL_SLAVE_SKIP_COUNTER=1;再開(kāi)一下slave就可以了，這個(gè)全局變量賦值為N的意思是：
This statement skips the next N events from the master. This is useful for recovering from replication stops caused by a statement.
This statement is valid only when the slave thread is not running. Otherwise, it produces an error.
呵呵，講的比我清楚。
MYSQL鏡像服務(wù)器因錯(cuò)誤停止的恢復(fù)
下午主服務(wù)器，由于一些原因，導(dǎo)致死機(jī)，重啟后，發(fā)現(xiàn)從服務(wù)器的數(shù)據(jù)沒(méi)有跟上。
配好MYSQL主從也才前幾天的事，沒(méi)多少經(jīng)驗(yàn)，第一次碰上這問(wèn)題，有點(diǎn)焦急。不過(guò)，自己試了下，還算解決了：）
從服務(wù)器上
Master_Log_File: mysqlhxmaster.000007
Read_Master_Log_Pos: 84285377
看一下主服務(wù)器：mysqlhxmaster.000007 | 84450528 |
已經(jīng)過(guò)后很多了，確實(shí)沒(méi)跟上。
show slave status\G
Slave_IO_Running: Yes
Slave_SQL_Running: No
有問(wèn)題了，Slave_SQL_Running應(yīng)該是Yes才對(duì)。
再往下看，有錯(cuò)誤的提示：
Last_Errno: 1053
Last_Error: Query partially completed on the master (error on master: 1053) and was aborted. There is a chance that your master is inconsistent at this point. If you are sure that your master is ok, run this query manually on the slave and then restart the slave with SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE; . Query: 'INSERT INTO hx_stat_record ......(一句SQL語(yǔ)句)'
這里有說(shuō)明要怎么操作了：）
先stop slave，然后執(zhí)行了一下提示的語(yǔ)句，再SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE;
show slave status\G
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
OK了，從服務(wù)器也在幾分鐘內(nèi)把堆積的log處理完了，兩邊又同步了：)
從MYSQL服務(wù)器Slave_IO_Running: No的解決2
早晨機(jī)房意外斷電，導(dǎo)致了發(fā)現(xiàn)mysql從服務(wù)器同步異常。使用以前碰到的Slave_SQL_Running為No的解決辦法無(wú)效，仍然無(wú)法同步。
查看一下?tīng)顟B(tài)show slave status
Master_Log_File: mysqlmaster.000079
Read_Master_Log_Pos: 183913228
Relay_Log_File: hx-relay-bin.002934
Relay_Log_Pos: 183913371
Relay_Master_Log_File: mysqlmaster.000079
Slave_IO_Running: No
Slave_SQL_Running: Yes
主服務(wù)器show master status\G
File: mysqlmaster.000080
Position: 13818288
Binlog_Do_DB:
Binlog_Ignore_DB: mysql,test
mysql錯(cuò)誤日志：
100512 9:13:17 [Note] Slave SQL thread initialized, starting replication in log 'mysqlmaster.000079' at position 183913228, relay log './hx-relay-bin.002934' position: 183913371
100512 9:13:17 [Note] Slave I/O thread: connected to master 'replicuser@192.168.1.21:3306', replication started in log 'mysqlmaster.000079' at position 183913228
100512 9:13:17 [ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236)
100512 9:13:17 [ERROR] Got fatal error 1236: 'Client requested master to start replication from impossible position' from master when reading data from binary log
100512 9:13:17 [Note] Slave I/O thread exiting, read up to log 'mysqlmaster.000079', position 183913228
這次是Slave_IO_Running為No，從日志上來(lái)看，服務(wù)器讀mysqlmaster.000079這個(gè)Log的183913228這個(gè)位置時(shí)發(fā)生錯(cuò)誤，這個(gè)位置不存在，于是無(wú)法同步。
查看一下這個(gè)Log的最后幾行：
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
# at 4
#100511 9:35:15 server id 1 end_log_pos 98 Start: binlog v 4, server v 5.0.27-standard-log created 100511 9:35:15
# Warning: this binlog was not closed properly. Most probably mysqld crashed writing it.
嘗試從損壞之前的位置開(kāi)始
SLAVE STOP;
CHANGE MASTER TO MASTER_LOG_FILE='mysqlcncnmaster.000079', MASTER_LOG_POS=183913220;
SLAVE START;
無(wú)效！
只好從新的日志開(kāi)始
SLAVE STOP;
CHANGE MASTER TO MASTER_LOG_FILE='mysqlcncnmaster.000080', MASTER_LOG_POS=0;
SLAVE START;
此時(shí)Slave_IO_Running恢復(fù)為Yes，同步進(jìn)行了！觀察了會(huì)兒，沒(méi)有任何出錯(cuò)跡象，問(wèn)題解決。
另外，出現(xiàn)Slave_IO_Running:NO還有一個(gè)原因是slave上沒(méi)有權(quán)限讀master上的數(shù)據(jù)。
相關(guān)文章
MySQL是一種關(guān)系數(shù)據(jù)庫(kù)管理系統(tǒng)，所使用的 SQL 語(yǔ)言是用于訪問(wèn)數(shù)據(jù)庫(kù)的最常用的，本文主要以Mysql免安裝版為例，幫助大家解決安裝與配置mysql的步驟2021-06-06
數(shù)據(jù)庫(kù)管理系統(tǒng)中,死鎖是指多個(gè)事務(wù)互相等待對(duì)方釋放資源,導(dǎo)致事務(wù)僵持不前,影響系統(tǒng)穩(wěn)定性,本文詳細(xì)介紹了如何在MySQL中排查和分析死鎖問(wèn)題,文中通過(guò)代碼介紹的非常詳細(xì),需要的朋友可以參考下2024-09-09
這篇文章主要給大家介紹了關(guān)于MySQL中int最大值的相關(guān)資料，文中通過(guò)示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面來(lái)一起學(xué)習(xí)學(xué)習(xí)吧2019-02-02
深入解析Linux下MySQL數(shù)據(jù)庫(kù)的備份與還原
以下是對(duì)Linux下MySQL數(shù)據(jù)庫(kù)的備份與還原進(jìn)行了詳細(xì)的分析介紹。需要的朋友可以過(guò)來(lái)參考下2013-08-08
安裝配置mysql及Navicat prenium的詳細(xì)流程
這篇文章主要介紹了安裝配置mysql及Navicat Premium的詳細(xì)流程,配置方法也真的很簡(jiǎn)單，本文給大家詳細(xì)介紹mysql Navicat Premium安裝配置相關(guān)知識(shí)感興趣的朋友，一起學(xué)習(xí)吧2021-06-06
對(duì) MySQL 數(shù)據(jù)庫(kù)的查詢(xún)，除了基本的查詢(xún)外，有時(shí)候需要對(duì)查詢(xún)的結(jié)果集進(jìn)行處理。例如只取 10 條數(shù)據(jù)、對(duì)查詢(xún)結(jié)果進(jìn)行排序或分組等等，今天就給大家分享MySQL一些常用高級(jí)SQL語(yǔ)句，感興趣的朋友一起看看吧2021-07-07
二進(jìn)制日志包含了所有更新了數(shù)據(jù)或者已經(jīng)潛在更新了數(shù)據(jù)（例如，沒(méi)有匹配任何行的一個(gè)DELETE）的所有語(yǔ)句2011-10-10
本文講述了在MySQL中識(shí)別和終止導(dǎo)致死鎖的SQL語(yǔ)句,通過(guò)SHOWENGINEINNODBSTATUS和INFORMATION_SCHEMA表,可以找到死鎖的具體事務(wù),感興趣的可以了解一下2024-11-11
MySQL數(shù)據(jù)表分區(qū)技術(shù)PARTITION詳解
在處理大規(guī)模數(shù)據(jù)時(shí),數(shù)據(jù)庫(kù)性能的優(yōu)化變得尤為重要,MySQL提供了一種稱(chēng)為“分區(qū)”（Partitioning）的技術(shù),可以顯著提高查詢(xún)效率和管理大型數(shù)據(jù)庫(kù)表的能力,本文將詳細(xì)介紹MySQL中的數(shù)據(jù)表分區(qū)技術(shù),包括其基本概念、類(lèi)型以及如何實(shí)現(xiàn)和維護(hù),需要的朋友可以參考下2025-02-02
如何在Linux平臺(tái)卸載MySQL呢？這篇文章主要介紹了Linux下卸載MySQL數(shù)據(jù)庫(kù)的方法，具有一定的參考價(jià)值，感興趣的小伙伴們可以參考一下2017-06-06