實戰：一文帶你解決Mysql主從複製平常錯誤

使用過Mysql數據庫朋友，必定聽過讀寫分離，聽的多的，估計耳朵都起繭子了。那麼讀寫分離是怎麼實現的呢，最多見的方法就是搭建Mysql的主從複製，主庫提供寫操做，從庫提供讀操做，從而達到應用的讀寫分離。

對於剛入坑開發崗，運維崗的萌新們，必定要弄懂什麼是讀寫分離，讀寫分離解決什麼業務問題，只有完全弄明白這些以後，纔去用讀寫分離架構。

廢話就很少說了，在這裏就來講說，主從複製最多見的2種錯誤
第一種：主鍵衝突（Error_code: 1062）
第二種：記錄丟失，例如update,delete操做，在從庫找不到對應記錄（Error_code: 1032）

下面來詳細模擬一下記錄丟失，處理全過程

檢查主從複製是否正常

[root@localhost] 11:34:29 [testdb]>show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.0.1
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: binlog.000029
          Read_Master_Log_Pos: 3683
               Relay_Log_File: mysql-relay-bin.000003
                Relay_Log_Pos: 2207
        Relay_Master_Log_File: binlog.000029
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

能夠看到IO線程和SQL線程運行都是正常的。

建立測試表和記錄

[root@localhost] 11:25:48 [testdb]>show create table test1\G;
*************************** 1. row ***************************
       Table: test1
Create Table: CREATE TABLE `test1` (
  `id` int(11) NOT NULL,
  `name1` char(10) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
  `name2` char(20) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
1 row in set (0.07 sec)

insert into test1 values(1,'test1','test1');
insert into test1 values(2,'test2','test2');
insert into test1 values(3,'test3','test3');

模擬主從複製因爲從庫記錄缺失，致使主從複製失敗

第一步：在從庫中刪除id=2的記錄

[root@localhost] 11:26:41 [testdb]>delete from test1 where id=2;
Query OK, 1 row affected (0.44 sec)

[root@localhost] 11:26:52 [testdb]>select * from test1;
+----+-------+-------+
| id | name1 | name2 |
+----+-------+-------+
|  1 | test1 | test1 |
|  3 | test3 | test3 |
+----+-------+-------+
2 rows in set (0.00 sec)

第二步：在主庫上刪除id=2的記錄

[root@localhost] 11:27:11 [testdb]>delete from test1 where id=2;
Query OK, 1 row affected (0.17 sec)

[root@localhost] 11:27:51 [testdb]>select * from test1;
+----+-------+-------+
| id | name1 | name2 |
+----+-------+-------+
|  1 | test1 | test1 |
|  3 | test3 | test3 |
+----+-------+-------+
2 rows in set (0.00 sec)

在從庫上查看主從複製狀況

[root@localhost] 11:34:05 [testdb]>show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.0.1
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: binlog.000029
          Read_Master_Log_Pos: 3683
               Relay_Log_File: mysql-relay-bin.000003
                Relay_Log_Pos: 1929
        Relay_Master_Log_File: binlog.000029
             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: 1032
                   Last_Error: Could not execute Delete_rows event on table testdb.test1; Can't find record in 'test1', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log binlog.000029, end_log_pos 3652
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 3405
              Relay_Log_Space: 2414
              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: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 1032
               Last_SQL_Error: Could not execute Delete_rows event on table testdb.test1; Can't find record in 'test1', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log binlog.000029, end_log_pos 3652
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 111213106
                  Master_UUID: 3ada166e-c4db-11ea-b21d-000c29cc2388
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State:
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp: 200904 11:33:10
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set: 3ada166e-c4db-11ea-b21d-000c29cc2388:84830-84835
            Executed_Gtid_Set: 3ada166e-c4db-11ea-b21d-000c29cc2388:1-84834,
3ada166e-c4db-11ea-b21d-000c29cc2389:1-4
                Auto_Position: 1
         Replicate_Rewrite_DB:
                 Channel_Name:
           Master_TLS_Version:
1 row in set (0.00 sec)

此時主從的sql線程已是中止狀態，主從複製的數據已經不一樣步了。複製開始報1032錯誤了。

要解決1032錯誤，能夠有如下3中方案
方案一：手工將缺失的業務記錄在主庫上導出，並導入到從庫，而後啓動從庫的sql線程就能夠了。慢着，你們有沒有注意到一個問題，就是在主庫上，到底要導出哪條記錄，報錯信息裏並無，可是有提示，he event's master log binlog.000029, end_log_pos 3652，因此還須要將binlog日誌裏的內容解析處理，找到要操做的記錄，彷佛有些麻煩。不用慌，還有方案二，方案三。

方案二：Mysql數據庫提供一個參數slave_skip_errors，這個參數能夠跳過指定錯誤代碼的sql語句，例如：slave_skip_errors=1032，惋惜，這個參數不能在線修改，修改生效須要重啓實例，是否是也太友好。

[root@localhost] 11:28:57 [testdb]>set global slave_skip_errors=1032;
ERROR 1238 (HY000): Variable 'slave_skip_errors' is a read only variable

方案三：使用percona-toolkits工具集中的pt-slave-restart工具，自動跳過主從同步指定的報錯代碼sql語句，此方法對mysql數據侵入性小，沒必要重啓Mysql實例

[mysql@mysql ~]$ pt-slave-restart --user=root --password=root --socket=/data/mysql/run/3306/mysql.sock --error-numbers=1032

# A software update is available:
2020-09-04T11:32:07 S=/data/mysql/run/3306/mysql.sock,p=...,u=root mysql-relay-bin.000003        1651 1032

當跳過主從同步指定的報錯代碼sql語句，主從複製恢復以後，間隔64秒，會再次自動檢測主從複製是否有1032錯誤。

其它相似的錯誤，均可以用以上三種方法方案處理，建議你們使用方案三。