Mysql從庫恢復失敗

推斷是因為一句修改表結構的語句在從庫執行失敗(或者未同步？)導致mysql從庫同步異常，使用命令show slave status;可以看到

Slave_IO_Running: Yes
Slave_SQL_Running: No

然後通過Relay_Master_Log_File和Exec_Master_Log_Pos定位到具體的sql語句,發現是條更新語句，更新某個表的19個欄位，然而從庫該表只有18個欄位。

1. 找到歷史更新記錄，然後手動在從庫新增該欄位
2. 暫停同步stop slave;
3. 跳過當前執行的同步sql set global sql_slave_skip_counter =1;
4. 繼續同步 start slave;

檢視同步狀態，發現開始正常地執行歷史sql了。然而，過了大約半個小時，我再次檢視狀態時，發現另一個sql又執行報錯，重複幾次後發現又有不同的sql執行報錯，而且由於前面跳過了一些重要資料沒有同步，導致後面大片失敗，這時候只好選擇重建從庫。

重建過程

1. mysqldump -u*** -p*** -h db-master --default-character-set=utf8 --master-data=2 --single-transaction --databases DB1 DB2 DB3  > product_data_backup_20170515.
    
   sql

   這裡將需要同步的資料庫DB1/DB2/DB3匯出到檔案。注意–master-data=2 –single-transaction的配合使用，前一個引數會在開始匯出時鎖全表，記錄當前的binlog檔案和位置，然後釋放鎖，然後在同一個事務中匯出資料，以保證一致性。

2. 從庫stop slave;

3. 從庫先drop需要同步的資料庫，然後source product_data_backup_20170515.sql匯入資料；
4. grep 'CHANGE MASTER TO MASTER_LOG_FILE' product_data_backup_20170515.sql拿到匯出時的MASTER_LOG_FILE和MASTER_LOG_POS,例：-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000068', MASTER_LOG_POS=70371793;
5. 
CHANGE MASTER TO MASTER_HOST='10.*.*.*',MASTER_USER='slaveUser',MASTER_PASSWORD='***',MASTER_LOG_FILE='mysql-bin.000068', MASTER_LOG_POS=70371793;

6. start slave;
7. show slave status;發現從庫正在同步最新的資料，一會兒之後就已經同步到最新的POS,恢復正常

其他問題

1. 不要修改從庫的表結構以及資料，避免同步衝突失敗；
2. 不要濫用set global sql_slave_skip_counter,這會跳過某些同步sql，可能導致資料不一致；
3. 附件類資料儘量不要直接儲存在資料庫中，備份和恢復時會特別慢