mysql利用binlog恢復資料
需求：需要給開發提供一個2018年9月30號的資料，按照我們公司正常備份策略來說，直接找到對應時間的備份資料，解壓匯入即可，恰好這個時間節點的資料沒有，只備份到2018年9月25號的，糟糕了吧
咋辦呢，咱們利用binlog日誌來恢復吧，如果二進位制日誌都沒有，那還恢復啥呢，運維咋當滴
話不多說，進入正題
一、匯入資料
我的源資料：baodian_2018-09-25_329010659.tar.bz2 #這一串數字是pos節點位置，等下利用二進位制恢復的時候需要用到，時間：9月 25 01:08
隨便在哪個mysql資料庫解壓匯入即可，根據自己的需求就行
二、找到對應的binlog
知道的時間節點：
1.開始pos位置：329010659
2.結束時間：2018-10-01 00:00:00
# 二進位制日誌分析
2018-09-22 12:34:23.459540935 2018-09-29 15:54:20.554318725 mysql-bin.000163
2018-09-29 15:54:20.554318725 2018-10-04 00:09:50.238484899 mysql-bin.000164
三、資料恢復
利用binlog恢復，一條命令搞定
/usr/local/mysql/bin/mysqlbinlog --start-position=329010659 --stop-datetime='2018-10-01 00:00:00' --database=baodian
溫馨提示：
1.mysqlbinlog分析多個檔案的時候，不能分開寫，否則匯入的時候會報語法錯誤，如圖
2.儘量加上字符集編碼引數，否則中文是亂碼
我的是： --set-charset=utf8
3. mysqlbinlog分析分時候，不要加這個引數，--base64-output=decode-rows，否則資料導不進去 #當然是根據我的環境來說的
其實我覺得一般是可以的，可能是我my.cnf裡面設定了格式為row
4.如果導資料的時候，出現如下兩種報錯資訊
1)ERROR 1609 (HY000): The BINLOG statement of type `Table_map` was not preceded by a format description BINLOG statement. #直接在資料庫source的時候
2) ERROR 2006 (HY000) at line xx: MySQL server has gone away #出現這個原因有很多種，其他原因的解決辦法參考：https://www.cnblogs.com/fnlingnzb-learner/p/5984795.html
這裡的原因是，sql操作時間過長，傳送的資料太大，可以設定max_allowed_packed來避免
解決：在my.cnf裡面新增一行引數
max_allowed_packed=16M #如果不行將16M再加大
mysqlbinlog其他用法，參考：
https://www.cnblogs.com/kevingrace/p/5907254.html