mysql主從備份及常見問題處理
1.mysql主從備份基本原理
mysql支持單向、異步復制，復制過程中一個服務器充當主服務器，而一個或多個其它服務器充當從服務器。mysql復制基於主服務器在二進制日誌中跟蹤所有對數據庫的更改(更新、刪除等等)。因此，要進行復制，必須在主服務器上啟用二進制日誌。每個從服務器從主服務器接收主服務器已經記錄到的二進制日誌，獲取日誌信息更新。通過設置在Master上的binlog，使其處於打開狀態；Slave通過一個I/O線程從Master上讀取binlog，然後傳輸到Slave的中繼日誌中，然後使用SQL線程讀取中繼日誌，並應用到自身數據庫中，從而實現主從數據同步功能。
前提：mysql數據庫主從數據庫的版本最好一樣，小版本編碼不一樣也可以，比如：5.7.20備份到5.7.11。
2.主數據庫遷移
在做數據庫主從備份之前，首先要確定需要備份的具體數據庫，若該數據庫為新建數據庫，只有表結構，可導出主數據庫的sql腳本，導入到從數據庫中執行，使主數據庫與從數據庫的結構相同。
若該數據庫已經存在存儲信息，則需要鎖定主數據庫，暫時不讓任何程序操作數據庫，導出主數據庫sql腳本，從數據庫執行sql腳本，保證在做主從備份之前，主從數據庫的結構，存儲信息一致。也可采用Navicat Premium等數據庫管理工具，直接做數據傳輸操作。如圖：
3.windows環境下主從備份操作
<1>主數據庫master配置
1.打開mysql數據庫的基礎配置文件，可在服務中查看mysql啟用的配置文件信息，若發現在服務器中沒有該配置文件，請設置服務器把隱藏的文件也展示出來。參考截圖如下：
2.打開my.ini配置文件，設置主數據庫的參數信息，主要設置字段為server-id,log_bin,binlog_do_db ，其他字段參考參數定義自行設置， 配置文件中相關參數定義如下：
| 參數 | 意義 |
|---|---|
| server-id | 數據庫唯一ID，一組主從中此標識號不能重復。其中1 代表主數據庫（源） 2代表輔數據庫（目的） |
| log_bin | 開啟bin-log，並指定文件目錄和文件名前綴 |
| binlog_do_db | 需要同步的數據庫名字，可以是多個，之間用分號分割 |
| binlog_ignore_db | 不需要同步的數據庫名字 |
| max_binlog_size | 每個bin-log最大大小，當此大小等於500M時會自動生成一個新的日誌文件。一條記錄不會寫在2個日誌文件中，所以有時日誌文件會超過此大小。 |
| binlog_cache_size | 日誌緩存大小 |
| binlog-do-db | 需要同步的數據庫名字，如果是多個，就以此格式在寫一行即可。 |
| binlog-ignore-db | 不需要同步的數據庫名字，如果是多個，就以此格式在寫一行即可。 |
| expire_logs_day | 設置bin-log日誌文件保存的天數，此參數mysql5.0以下版本不支持。 |
| binlog_format | bin-log日誌文件格式，設置為MIXED可以防止主鍵重復。 |
3.主服務器創建允許從服務器同步數據的賬戶：
4.重啟mysql服務，查看master狀態，查看命令：show master status;
<2>從數據庫slave配置
1.打開從服務器的my.ini配置，設置從數據庫參數信息，設置字段信息server-id,binlog_do_db 。slave庫上建議把一些重要的選項開啟，例如設置為read only、relay_log_recovery、sync_master_info、sync_relay_log_info、sync_relay_log這些重要選項開啟。
2.停止slave服務，指令為：stop slave;
3.配置從服務器，開啟同步模式，關鍵參數如下：
在設置同步模式時，需要保證主從服務器所在的網絡是相通的，配置的文件日誌名稱，索引位置與主服務器查詢的信息一致。
4.啟動slave服務，指令為：start slave;
5.重啟mysql服務，查看從數據庫同步狀態，查看指令為：show slave status;當查詢的Slave_IO_Running: Yes，Slave_SQL_Running: Yes時，表示同步狀態正常，主從配置成功。
4.linux環境下主從備份操作
通過分析mysql主從備份的原理，它本身是基於主數據庫的二進制日誌備份的，所以，主從備份本身受操作系統的影響較小，在linux環境下面配置主從備份與在windows下面配置主從備份操作步驟相同，修改參數也相同。唯一不同點是linux版本數據庫的配置文件是my.cnf，一般在/etc/my.cnf下面，修改主從數據的配置文件信息，重啟mysql數據庫服務，即可完成mysql數據庫主從備份。
筆者也親自測試過，windows版本的mysql數據庫做為主數據庫，linux版本的mysql數據庫做為從數據庫，或者調換，均可設置主從備份。
5.mysql主從備份常見錯誤及解決方案
筆者在初次成功配置了mysql數據庫主從備份後，以為自此可以萬事無憂。但未過多久，通過查詢指令查看從服務器的同步狀態，發現報錯了，在網上尋求解決辦法解決後。發現不多久，又會出現其他類型的錯誤。總之，感覺很棘手，也覺得主從備份不可靠，需要人經常去查看同步狀態，一旦出現報錯，需要及時人為的處理。這樣的情況一般出現在最初做數據庫同步的那幾天，還有就是主服務器，或者從服務器宕機時間長了的情況。常見錯誤及解決方案如下：
-
[ERROR] Slave I/O: Got fatal error 1236 from master when reading data from binary log: ‘Client requested master to start replication from impossible position‘, Error_code: 1236
解決方案：出現1236，出現這種錯誤一般是主從服務器失去連接，出現了宕機的情況。常用解決辦法，重新查詢主服務器的狀態，獲取新的position位置，重新設置從服務器的同步信息。
-
Last_Errno: 1032， Last_Error: Could not execute Update_rows event on table xuanzhi.test; Can‘t find record in ‘test‘, Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event‘s master log mysql
解決方案：出現1032，表示從數據庫上面缺少某一條數據記錄，主數據庫對這條記錄又做了修改，從數據庫在修改時報錯。解決方案是直接用數據庫管理工具，數據傳輸模式處理具體異常的數據表，保證主數據與從數據庫對應的報錯數據表結構信息一樣。
-
Last_Errno: 1062，Last_Error: Could not execute Write_rows event on table xuanzhi.test; Duplicate entry ‘5‘ for key ‘PRIMARY‘, Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event‘s master log
解決方案：出現1062，表示主鍵沖突，及從數據庫上面出現了主數據庫上面沒有的主鍵信息記錄。解決方案是直接刪除提示的從數據庫中的異常數據，或者利用數據傳輸模式處理具體異常的數據表。
-
Last_Errno: 1594，Last_Errno: 1593
解決方案：中繼日誌錯誤，一般是服務器宕機引起，解決方案和出現錯誤1236一樣。在msql 5.5以上版本，可在slave的配置文件my.cnf裏要增加一個參數relay_log_recovery=1。
校驗主從服務器上面的數據是否完全一致，可通過工具pt-table-checksum操作。具體操作請參考這篇博文。
mysql主從備份及常見問題處理