mysql主從同步導致1062和1032問題

事情起因

不知道為什麼mysql的資料庫所在磁碟空間滿了。導致主從出現數據不一致。可是我並不知道是空間滿了引起的，各種辦法使用了，mysql卻停不了。登陸mysql也沒辦執行命令。然後就

```
    kill -9 mysql's pid
```

結果就悲劇了。mysql的主從被破壞。（這個是時候才想起來看一下磁碟空間問題，已經晚了）想了很多方式，還是沒辦法解決。最後決定重新做一下從庫。進入主題。

==友情提示：千萬不要 kill -9 誰用誰知道==

下面是我操作的具體步驟

1. 拉取主庫的備份檔案。恢復從庫資料。
2. 設定從庫的binlog日誌和pos點。
3. 啟動重複，開啟複製。

悲劇開始

1. 主從出現問題,輸入：show slave status \G; 這個時候出現了Error_code: 1062的錯誤。附上當時的主從的狀態和錯誤日誌。

   Slave_IO_Running: Yes
   Slave_SQL_Running: No

   2016-06-09 00:07:07 23352 [ERROR] Error reading packet from server: Lost connection to MySQL server during query ( server_errno=2013)
   2016-06-09 00:07:07 23352 [Note] Slave I/O thread killed while
    
    reading event
   2016-06-09 00:07:07 23352 [Note] Slave I/O thread exiting, read up to log 'mysql-bin-190.000667', position 9049889
   2016-06-09 00:07:07 23352 [Warning] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and
    
    PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information.
   2016-06-09 00:07:07 23352 [Warning] Slave SQL: If a crash happens this configuration does not guarantee that the relay log info will be consistent, Error_code: 0
   2016-06-09 00:07:07 23352 [Note] Slave SQL thread initialized, starting replication in log 'mysql-bin-190.000666' at position 2935199, relay log './mysql3306-relay-bin.000002' position: 2935366
   2016-06-09 00:07:07 23352 [Note] 'SQL_SLAVE_SKIP_COUNTER=1' executed at relay_log_file='./mysql3306-relay-bin.000002', relay_log_pos='2935366', master_log_name='mysql-bin-190.000666', master_log_pos='2935199' and new position at relay_log_file='./mysql3306-relay-bin.000002', relay_log_pos='2935750', master_log_name='mysql-bin-190.000666', master_log_pos='2935583' 
   2016-06-09 00:07:07 23352 [Note] Slave I/O thread: connected to master '[email protected]:3306',replication started in log 'mysql-bin-190.000667' at position 9049889
   2016-06-09 00:07:08 23352 [ERROR] Slave SQL: Could not execute Write_rows event on table asy.pm_camera_recordrate; Duplicate entry '913df478e36f4f888505874ddec59240' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysql-bin-190.000666, end_log_pos 2944382, Error_code: 1062
   2016-06-09 00:07:08 23352 [Warning] Slave: Duplicate entry '913df478e36f4f888505874ddec59240' for key 'PRIMARY' Error_code: 1062

   解決方式：在my.cnf檔案中加入如下程式碼到[mysqld]。重啟mysql

   slave-skip-errors = 1062

2. 執行完第一步。由於資料問題，又出現了。Error_code: 1032錯誤。

解決方式：在my.cnf檔案中加入如下程式碼到[mysqld]。重啟mysql

```
slave-skip-errors = 1062,1032
```

如果能預估到錯誤資料比較少。也可以用如下程式碼。每次執行只跳過一個事務。

```
stop slave;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1 ;
start slave ;
```

可能出現的問題

跳過1062和1032錯誤 。可能會導致日誌中出現警告資訊。所以在在my.cnf檔案中加入如下程式碼到[mysqld]。重啟mysql可解決問題。

```
binlog_format=mixed
```

反思問題起因

1. 在從庫由於使用了 kill -9 殺掉了mysql執行緒。可能導致了mysql的事務回滾。也有可能導致了mysql中繼日誌出現問題。
2. 在拉取備份檔案恢復的時候。由於拉取了最新的備份資料。恢復資料的時候。只是重設了同步的binlog檔案和pos點。並沒有修改中繼日誌的起點。導致了中繼日誌中的資料應該是比資料庫中的備份點資料更早了。然後產生了1062主鍵衝突和1032刪除資料不存在的錯誤。

以上類容純屬猜想，並未真正驗證，如有理解錯誤，歡迎大家指正，謝謝！