mysql 數據同步 湧現Slave_IO_Running:No成績的處理辦法小結。本站提示廣大學習愛好者：（mysql 數據同步 湧現Slave_IO_Running:No成績的處理辦法小結）文章只能為提供參考，不一定能成為您想要的結果。以下是mysql 數據同步 湧現Slave_IO_Running:No成績的處理辦法小結正文
上面寫一下，這兩個如果有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鏡像辦事器因毛病停滯的恢復
下晝主辦事器，因為一些緣由，招致逝世機，重啟後，發明從辦事器的數據沒有跟上。
配好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，然後履行了一下提醒的語句，再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
凌晨機房不測斷電，招致了發明mysql從辦事器同步異常。應用之前碰著的Slave_SQL_Running為No的處理方法有效，依然沒法同步。
檢查一下狀況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 '
[email protected]: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這個地位時產生毛病，這個地位不存在，因而沒法同步。
檢查一下這個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上的數據。
