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

前言

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

記錄刪除失敗

在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 COMPLETION_TYPE=@OLD_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：從庫數據與主庫沖突

解決方法1：

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

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

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

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

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

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

問題3：慢SQL語句過多

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

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

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

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

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

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

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

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

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