mysql 數據同步 出現Slave_IO_Running:No問題的解決方法小結
更新時間:2011年05月25日 17:47:13 作者:
mysql replication 中slave機器上有兩個關鍵的進程,死一個都不行,一個是slave_sql_running,一個是Slave_IO_Running,一個負責與主機的io通信,一個負責自己的slave mysql進程。
下面寫一下,這兩個要是有no了,怎么恢復。。
如果是slave_io_running no了,那么就我個人看有三種情況,一個是網絡有問題,連接不上,像有一次我用虛擬機搭建replication,使用了nat的網絡結構,就是死都連不上,第二個是有可能my.cnf有問題,配置文件怎么寫就不說了,網上太多了,最后一個是授權的問題,replication slave和file權限是必須的。如果不怕死就all咯。。
一旦io為no了先看err日志,看看爆什么錯,很可能是網絡,也有可能是包太大收不了,這個時候主備上改max_allowed_packet這個參數。
如果是slave_sql_running no了,那么也有兩種可能,一種是slave機器上這個表中出現了其他的寫操作,就是程序寫了,這個是會有問題的,今天我想重現,但是有時候會有問題,有時候就沒有問題,現在還不是太明了,后面再更新,還有一種占絕大多數可能的是slave進程重啟,事務回滾造成的,這也是mysql的一種自我保護的措施,像關鍵時候只讀一樣。
這個時候想恢復的話,只要停掉slave,set GLOBAL SQL_SLAVE_SKIP_COUNTER=1;再開一下slave就可以了,這個全局變量賦值為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鏡像服務器因錯誤停止的恢復
下午主服務器,由于一些原因,導致死機,重啟后,發(fā)現從服務器的數據沒有跟上。
配好MYSQL主從也才前幾天的事,沒多少經驗,第一次碰上這問題,有點焦急。不過,自己試了下,還算解決了:)
從服務器上
Master_Log_File: mysqlhxmaster.000007
Read_Master_Log_Pos: 84285377
看一下主服務器:mysqlhxmaster.000007 | 84450528 |
已經過后很多了,確實沒跟上。
show slave status\G
Slave_IO_Running: Yes
Slave_SQL_Running: No
有問題了,Slave_SQL_Running應該是Yes才對。
再往下看,有錯誤的提示:
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語句)'
這里有說明要怎么操作了:)
先stop slave,然后執(zhí)行了一下提示的語句,再SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE;
show slave status\G
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
OK了,從服務器也在幾分鐘內把堆積的log處理完了,兩邊又同步了:)
從MYSQL服務器Slave_IO_Running: No的解決2
早晨機房意外斷電,導致了發(fā)現mysql從服務器同步異常。使用以前碰到的Slave_SQL_Running為No的解決辦法無效,仍然無法同步。
查看一下狀態(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
主服務器show master status\G
File: mysqlmaster.000080
Position: 13818288
Binlog_Do_DB:
Binlog_Ignore_DB: mysql,test
mysql錯誤日志:
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,從日志上來看,服務器讀mysqlmaster.000079這個Log的183913228這個位置時發(fā)生錯誤,這個位置不存在,于是無法同步。
查看一下這個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.
嘗試從損壞之前的位置開始
SLAVE STOP;
CHANGE MASTER TO MASTER_LOG_FILE='mysqlcncnmaster.000079', MASTER_LOG_POS=183913220;
SLAVE START;
無效!
只好從新的日志開始
SLAVE STOP;
CHANGE MASTER TO MASTER_LOG_FILE='mysqlcncnmaster.000080', MASTER_LOG_POS=0;
SLAVE START;
此時Slave_IO_Running恢復為Yes,同步進行了!觀察了會兒,沒有任何出錯跡象,問題解決。
另外,出現Slave_IO_Running:NO還有一個原因是slave上沒有權限讀master上的數據。
如果是slave_io_running no了,那么就我個人看有三種情況,一個是網絡有問題,連接不上,像有一次我用虛擬機搭建replication,使用了nat的網絡結構,就是死都連不上,第二個是有可能my.cnf有問題,配置文件怎么寫就不說了,網上太多了,最后一個是授權的問題,replication slave和file權限是必須的。如果不怕死就all咯。。
一旦io為no了先看err日志,看看爆什么錯,很可能是網絡,也有可能是包太大收不了,這個時候主備上改max_allowed_packet這個參數。
如果是slave_sql_running no了,那么也有兩種可能,一種是slave機器上這個表中出現了其他的寫操作,就是程序寫了,這個是會有問題的,今天我想重現,但是有時候會有問題,有時候就沒有問題,現在還不是太明了,后面再更新,還有一種占絕大多數可能的是slave進程重啟,事務回滾造成的,這也是mysql的一種自我保護的措施,像關鍵時候只讀一樣。
這個時候想恢復的話,只要停掉slave,set GLOBAL SQL_SLAVE_SKIP_COUNTER=1;再開一下slave就可以了,這個全局變量賦值為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鏡像服務器因錯誤停止的恢復
下午主服務器,由于一些原因,導致死機,重啟后,發(fā)現從服務器的數據沒有跟上。
配好MYSQL主從也才前幾天的事,沒多少經驗,第一次碰上這問題,有點焦急。不過,自己試了下,還算解決了:)
從服務器上
Master_Log_File: mysqlhxmaster.000007
Read_Master_Log_Pos: 84285377
看一下主服務器:mysqlhxmaster.000007 | 84450528 |
已經過后很多了,確實沒跟上。
show slave status\G
Slave_IO_Running: Yes
Slave_SQL_Running: No
有問題了,Slave_SQL_Running應該是Yes才對。
再往下看,有錯誤的提示:
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語句)'
這里有說明要怎么操作了:)
先stop slave,然后執(zhí)行了一下提示的語句,再SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE;
show slave status\G
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
OK了,從服務器也在幾分鐘內把堆積的log處理完了,兩邊又同步了:)
從MYSQL服務器Slave_IO_Running: No的解決2
早晨機房意外斷電,導致了發(fā)現mysql從服務器同步異常。使用以前碰到的Slave_SQL_Running為No的解決辦法無效,仍然無法同步。
查看一下狀態(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
主服務器show master status\G
File: mysqlmaster.000080
Position: 13818288
Binlog_Do_DB:
Binlog_Ignore_DB: mysql,test
mysql錯誤日志:
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,從日志上來看,服務器讀mysqlmaster.000079這個Log的183913228這個位置時發(fā)生錯誤,這個位置不存在,于是無法同步。
查看一下這個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.
嘗試從損壞之前的位置開始
SLAVE STOP;
CHANGE MASTER TO MASTER_LOG_FILE='mysqlcncnmaster.000079', MASTER_LOG_POS=183913220;
SLAVE START;
無效!
只好從新的日志開始
SLAVE STOP;
CHANGE MASTER TO MASTER_LOG_FILE='mysqlcncnmaster.000080', MASTER_LOG_POS=0;
SLAVE START;
此時Slave_IO_Running恢復為Yes,同步進行了!觀察了會兒,沒有任何出錯跡象,問題解決。
另外,出現Slave_IO_Running:NO還有一個原因是slave上沒有權限讀master上的數據。
相關文章
修改mysql5.5默認編碼(圖文步驟修改為utf-8編碼)
安裝mysql后,啟動服務并登陸,使用show variables命令可查看mysql數據庫的默認編碼;mysql數據庫的默認編碼并不是utf-8如何修改呢,本文將詳細介紹,感興趣的朋友可以了解下2013-01-01mysql中 ${param}與#{param}使用區(qū)別
這篇文章主要介紹了mysql中 ${param}與#{param}使用區(qū)別,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧2020-08-08MySQL登錄時出現 Access denied for user ‘
今天打開mysql的時候突然提示:Access denied for user 'root'@'localhost' (using password: YES) 在網上搜索了很多文章,本文就來做一下總結,介紹了幾種場景的解決方法,感興趣的可以了解一下2024-03-03使用Kubernetes集群環(huán)境部署MySQL數據庫的實戰(zhàn)記錄
這篇文章主要介紹了使用Kubernetes集群環(huán)境部署MySQL數據庫,主要包括編寫 mysql.yaml文件,執(zhí)行如下命令創(chuàng)建,通過相關命令查看創(chuàng)建結果,對Kubernetes部署MySQL數據庫的過程感興趣的朋友一起看看吧2022-05-05