2. 程式人生 > >MySQL主從同步報錯故障處理記錄

MySQL主從同步報錯故障處理記錄

阿新 • • 發佈：2017-06-05
記錄 error start record master


前言

在發生故障切換後，經常遇到的問題就是同步報錯，下面是最近收集的報錯信息。

記錄刪除失敗

在master上刪除一條記錄，而slave上找不到

Last_SQL_Error: Could not execute Delete_rows event on table hcy.t1;
Can‘t find record in ‘t1‘,
Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND;
the event‘s master log mysql-bin.000006, end_log_pos 254

解決方法：master要刪除一條記錄，而slave上找不到報錯，這種情況主都已經刪除了，那麽從機可以直接跳過。

stop slave;
set global sql_slave_skip_counter=1;
start slave;

如果這種情況很多，需要針對這種錯誤專門寫相關腳本。

主鍵重復

在slave已經有該記錄，又在master上插入了同一條記錄。

Last_SQL_Error: Could not execute Write_rows event on table hcy.t1; 
Duplicate entry ‘2‘ for key ‘PRIMARY‘, 
Error_code: 1062; 
handler error HA_ERR_FOUND_DUPP_KEY; the event‘s master log mysql-bin.000006, end_log_pos 924

解決方法：

在slave上用desc hcy.t1; 先看下表結構：

mysql> desc hcy.t1;
+-------+---------+------+-----+---------+-------+
| Field | Type    | Null | Key | Default | Extra |
+-------+---------+------+-----+---------+-------+
| id    | int(11) | NO   | PRI | 0       |       | 
| name  | char(4) | YES  |     | NULL    |       | 
 
+-------+---------+------+-----+---------+-------+

刪除重復的主鍵

mysql> delete from t1 where id=2;
Query OK, 1 row affected (0.00 sec)

mysql> start slave;
Query OK, 0 rows affected (0.00 sec)

mysql> show slave status\G;
……
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
……
mysql> select * from t1 where id=2;

在master上和slave上再分別確認一下。

更新丟失

在master上更新一條記錄，而slave上找不到，丟失了數據。

Last_SQL_Error: Could not execute Update_rows event on table hcy.t1; 
Can‘t find record in ‘t1‘, 
Error_code: 1032; 
handler error HA_ERR_KEY_NOT_FOUND; 
the event‘s master log mysql-bin.000010, end_log_pos 794

解決方法：

在master上，用mysqlbinlog 分析下出錯的binlog日誌在幹什麽。

/usr/local/mysql/bin/mysqlbinlog --no-defaults -v -v --base64-output=DECODE-ROWS mysql-bin.000010 | grep -A ‘10‘ 794

#120302 12:08:36 server id 22  end_log_pos 794  Update_rows: table id 33 flags: STMT_END_F
### UPDATE hcy.t1
### WHERE
###   @1=2 /* INT meta=0 nullable=0 is_null=0 */
###   @2=‘bbc‘ /* STRING(4) meta=65028 nullable=1 is_null=0 */
### SET
###   @1=2 /* INT meta=0 nullable=0 is_null=0 */
###   @2=‘BTV‘ /* STRING(4) meta=65028 nullable=1 is_null=0 */
# at 794
#120302 12:08:36 server id 22  end_log_pos 821  Xid = 60
COMMIT/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET [email protected]_COMPLETION_TYPE*/;

在slave上，查找下更新後的那條記錄，應該是不存在的。

mysql> select * from t1 where id=2;
Empty set (0.00 sec)

然後再到master查看

mysql> select * from t1 where id=2;
+----+------+
| id | name |
+----+------+
|  2 | BTV  | 
+----+------+
1 row in set (0.00 sec)

把丟失的數據在slave上填補，然後跳過報錯即可。

mysql> insert into t1 values (2,‘BTV‘);
Query OK, 1 row affected (0.00 sec)

mysql> select * from t1 where id=2;    
+----+------+
| id | name |
+----+------+
|  2 | BTV  | 
+----+------+
1 row in set (0.00 sec)

mysql> stop slave ;set global sql_slave_skip_counter=1;start slave;
Query OK, 0 rows affected (0.01 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)

mysql> show slave status\G;
……
 Slave_IO_Running: Yes
 Slave_SQL_Running: Yes
……

1236錯誤, 二進制文件缺失

誤刪二進制文件等各種原因，導致主庫mysql-bin.000012文件丟失，從庫同步失敗。

Master_Log_File: mysql-bin.000012
Slave_IO_Running: No
Slave_SQL_Running: Yes
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: ‘Could not find first log file name in binary log index file‘

  • 首先停止從庫同步

    slave stop;

  • 查看主庫日誌文件和位置

    mysql> show master logs;
    +------------------+-----------+
    | Log_name         | File_size |
    +------------------+-----------+
    | mysql-bin.000013 |       154 |
    +------------------+-----------+

  • 回從庫，使日誌文件和位置對應主庫

    CHANGE MASTER TO MASTER_LOG_FILE=‘log-bin.000013‘,MASTER_LOG_POS=154;

  • 最後，啟動從庫：

```bash
slave start;

show slave status\G;

Master_Log_File: mysql-bin.000013
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Last_IO_Error:
```

中繼日誌損壞

slave的中繼日誌relay-bin損壞。

Last_SQL_Error: Error initializing relay log position: I/O error reading the header from the binary log
Last_SQL_Error: Error initializing relay log position: Binlog has bad magic number;  
It‘s not a binary log file that can be used by  this version of MySQL

1、手工修復
解決方法：找到同步的binlog和POS點，然後重新做同步，這樣就可以有新的中繼日值了。

例子：

mysql> show slave status\G;
*************************** 1. row ***************************
              Master_Log_File: mysql-bin.000010
          Read_Master_Log_Pos: 1191
               Relay_Log_File: vm02-relay-bin.000005
                Relay_Log_Pos: 253
        Relay_Master_Log_File: mysql-bin.000010
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 1593
                   Last_Error: Error initializing relay log position: I/O error reading the header from the binary log
                 Skip_Counter: 1
          Exec_Master_Log_Pos: 821

Slave_IO_Running ：接收master的binlog信息
                   Master_Log_File
                   Read_Master_Log_Pos

Slave_SQL_Running：執行寫操作
                   Relay_Master_Log_File
                   Exec_Master_Log_Pos

以執行寫的binlog和POS點為準。

Relay_Master_Log_File: mysql-bin.000010
Exec_Master_Log_Pos: 821
mysql> stop slave;
Query OK, 0 rows affected (0.01 sec)

mysql> CHANGE MASTER TO MASTER_LOG_FILE=‘mysql-bin.000010‘,MASTER_LOG_POS=821;
Query OK, 0 rows affected (0.01 sec)

mysql> start slave;
Query OK, 0 rows affected (0.00 sec)


mysql> show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.8.22
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 10
              Master_Log_File: mysql-bin.000010
          Read_Master_Log_Pos: 1191
               Relay_Log_File: vm02-relay-bin.000002
                Relay_Log_Pos: 623
        Relay_Master_Log_File: mysql-bin.000010
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 1191
              Relay_Log_Space: 778
              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: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error:

2、Ibbackup
各種大招都用上了，無奈slave數據丟失過多，ibbackup（需要銀子）該你登場了。

Ibbackup熱備份工具，是付費的。xtrabackup是免費的，功能上一樣。

Ibbackup備份期間不鎖表，備份時開啟一個事務（相當於做一個快照），然後會記錄一個點，之後數據的更改保存在ibbackup_logfile文件裏，恢復時把ibbackup_logfile 變化的數據再寫入到ibdata裏。

Ibbackup 只備份數據（ ibdata、.ibd ），表結構.frm不備份。


MySQL主從復制常見故障及解決方法？


1.1.1故障1：從庫數據與主庫沖突


show slave status; 報錯：且show slave status\GSlave_I/O_Running:YesSlave_SQL_Running:NoSeconds_Behind_Master:NULLLast_error:Error ‘Can‘t create database ‘xiaoliu‘; database exists‘ on query. Default

database:‘xiaoliu‘.query:‘create database xiaoliu‘


解決方法1：

stop slave;set global sql_slave_skip_counter = 1; #將同步指針向下移動一個，如果多次不同步可以重復操作


解決方法2：在從庫配置文件中配置，直接跳過不影響業務的錯誤號

grep slave-skip /etc/my.cnfslave-skip-errors = 1032,1062,1007


1.1.2故障2：MySQL主從復制延遲問題原因和解決方案


問題1：主庫的從庫太多，導致復制延遲

從庫數量一般 3—5個為宜，要復制的節點過多，導致復制延遲

問題2：從庫硬件配置比主庫差，導致延遲

查看Master和Slave的配置，可能因為配置不當導致復制的延遲

問題3：慢SQL語句過多

假如一條語句執行時間超過2秒， 就需要進行優化進行調整

問題4：主從復制設計問題

主從復制單線程，如果主庫的寫入並發太大，來不及傳送到從庫就會導致延遲

更高版本的MySQL可以支持多線程復制，門戶網站則會自己開發多線程同步功能

問題5：主從庫之間的網絡延遲

主從庫網卡、網線、連接的交換機等網絡設備都可能成為復制的瓶頸

導致復制延遲，另外跨公網主從復制很容易導致主從復制延遲

問題6：主庫讀寫壓力大，導致復制延遲

主庫硬件要好一些，架構前端要加buffer緩存層



MySQL主從同步報錯故障處理記錄

相關推薦

MySQL主從同步報錯故障處理記錄

記錄 error start record master 前言在發生故障切換後，經常遇到的問題就是同步報錯，下面是最近收集的報錯信息。記錄刪除失敗在master上刪除一條記錄，而slave上找不到Last_SQL_Error: Could not execute Delete_rows e

線上MYSQL同步報錯故障處理方法總結

table 存在 index 刪除 查找 skip number hat rec 前言 在發生故障切換後，經常遇到的問題就是同步報錯，下面是最近收集的報錯信息。 記錄刪除失敗 在master上刪除一條記錄，而slave上找不到 Last_SQL_Error:

線上MYSQL同步報錯故障處理方法總結(必看篇)

前言在發生故障切換後，經常遇到的問題就是同步報錯，資料庫很小的時候，dump完再匯入很簡單就處理好了，但線上的資料庫都150G-200G，如果用單純的這種方法，成本太高，故經過一段時間的摸索，總結了幾種處理方法。生產環境架構圖目前現網的架構，儲存著兩份資料，通過非同步複製做的

線上MYSQL同步報錯故障處理總結

http://www.cnblogs.com/itcomputer/articles/5618907.html 前言 在發生故障切換後，經常遇到的問題就是同步報錯，資料庫很小的時候，dump完再匯入很簡單就處理好了，但線上的資料庫都150G-200G，

mysql主從同步報錯 Got fatal error 1236 from master when reading data from binary log

突然發現從庫不同步主庫了 ，不知道是什麼原因   來不及分析  只能先恢復 報錯；Got fatal error 1236 from master when reading data from binary log 剛開始怎麼的執行set global sql_slave

[MySQL] MySQL主從同步報錯1236解決

記一次MySQL主從同步1236報錯檔案解決。 報錯： Slave同步失敗報錯1236，日誌 mysql> show slave status \G *************************** 1. row **********************

mysql 5.7 基於GTID 主從同步的1236故障處理（其它事務故障等同）

其它 top 處理 set tid gtid stop eve 1-1 登錄從庫 stop slave; 查看執行事務 show slave status\G Retrieved_Gtid_Set: ee3bdb44-f6a1-11e7-b194-005056a35fd4

centos 7格式化分區報錯的處理記錄

格式化報錯 not make a 文件系統 her 1、給一塊新硬盤sdb分區：[root@localhost ~]# fdisk /dev/sdb 歡迎使用 fdisk (util-linux 2.23.2)。 更改將停留在內存中，直到您決定將更改寫入磁盤。 使用寫入命令前請三思。 Devic

mysql主從同步搭建和故障排除

mysql主從同步搭建 mysql主從同步線程無法開啟 mysql主從同步定義和作用 主從同步的定義： 是存儲數據的一種結構模式。主：被客戶端訪問的數據庫服務器就是主庫服務器master從：連接主庫服務器，自動同步主庫的所有數據到本機slave1、什麽是mysql主從同步？ 當master

MYSQL啟動後報錯故障問題的解決辦法

quit ... AI gin native with 錯誤日誌 查看 RR centos系統有一次異常關機後啟動mysql一直報錯#/etc/init.d/mysqld startStarting MySQL.. ERROR! The server quit withou

linux上mysql的gtid主從複製報錯處理

一、從庫上報錯檢視：     show slave status\G             Retrieved_Gtid_Set: e10c75be-5c1b-11e6-ab7c-000

【故障】MySQL主從同步故障－Slave_SQL_Running: No

ack counter stop usr mysql-bin back data 連接 xid 轉自：http://www.linuxidc.com/Linux/2014-02/96945.htm 故障現象：進入slave服務器，運行：mysql> show slav

mysql登錄報錯“Access denied for user 'root'@'localhost' (using password: YES”的處理方法

為我 方法 error: top error 告訴 猜想 network grant 最近登錄某臺服務器的mysql時候總報錯： Access[root@log01 ~]# mysql -u root -p Enter password: ERROR 1045 (2800

MySQL主從同步常見報錯的解決辦法2

MySQL ERROR 1872 報錯截圖如下：該報錯屬於SQL線程報錯，原因是relay -index.index 和relay-log裏面的文件路徑對應不上。解決辦法： mysql> stop slave;mysql> reset slave;重新指定主庫信息mysql> ch

mysql儲存emoji表情報錯的處理方法【更改編碼為utf8mb4】

utf-8編碼可能2個位元組、3個位元組、4個位元組的字元，但是MySQL的utf8編碼只支援3位元組的資料，而移動端的表情資料是4個位元組的字元。如果直接往採用utf-8編碼的資料庫中插入表情資料，Java程式中將報SQL異常： java.sql.SQLException: Incorrect st

mysql存儲emoji表情報錯的處理方法【更改編碼為utf8mb4】

ice filesyste 內容 except 位置 tween see red dir utf-8編碼可能2個字節、3個字節、4個字節的字符，但是MySQL的utf8編碼只支持3字節的數據，而移動端的表情數據是4個字節的字符。如果直接往采用utf-8編碼的數據庫中插入表情

Windows7 上連線 MySQL報錯問題處理

在 win7上面連線 MySQL 報錯：ERROR 1045 (28000): Access denied for user 'ODBC'@'localhost' (using password: YES). 環境如下： win7 64位系統（32位也應該沒有關係把）

mysql 故障處理記錄

20181113 phpadmin 查詢到的狀態引數，紅牌如下圖： 1、查詢掛起的任務 show processlist 處理完成後 2、查詢生成的臨時表 查考 https://www.imooc.com/article/48896 show GLOBAL STAT

使用MySQLadmin自定義MySQL資料庫密碼報錯處理

MySQL自定義密碼報錯 1.報錯示例 例如:mysqladmin -uroot password “123456” mysqladmin: connect to server at ‘localhost’ failed error: ‘Access denied for use

最近處理了很多服務端 相關的報錯，總結記錄

解決了很多服務端的錯誤，很多都是，這個環境沒有問題，移到其它環境就出問題了，排除花費了很多時間，總結下來後，發現除了少部分是程式的問題，大部分是環境的問題，而且問題可以化為以下幾類： 1、磁碟空間不足。 2、記憶體空間不足。 3、網段不通。 4、配置錯誤。