今天一位跨界老碼農不知咋回事，興奮過了頭，一不小心把資料庫給刪掉啦，然後問我咋恢復，然後我告訴他基於 binlog 可以恢復，誰成想沒有開啟 binlog，最後只能躲在角落裡傷心。

愛情 36 技系列，好久沒更新啦，真是苦了追逐愛情系列的那些朋友們。

好了，請忘記上面的一切，因為我們的愛情故事系列又要更新啦。

自從 Java 那小子喜獲 Python 菇涼的芳心之後，兩人就邁入了柴米油鹽醬醋茶的生活，但是鍋碗瓢盆難免磕磕碰碰，生活中吵吵鬧鬧甚是正常。

不過每次小吵小鬧，Python 菇涼都會忍不住想刪除存儲在 MySQL 上的旅途記憶（不是想刪庫，就是想跑路）。但是老話說的好：天上月亮圓圓的，小兩口吵架總是鬧著玩的，況且小兩口沒有隔夜的仇，所以每次花好月圓之時，Java 那小子總會憑自己精湛的技藝把 Python 菇涼放在 MySQL 上的記憶給恢復如初。

另外 Java 那小子為了幫助其他家庭能夠快速重建美好記憶，考慮到家庭穩固，特意把秘訣分享給大家，希望大家拿去使用，估計會屢試不爽。

秘訣一：記錄日誌，讓你有跡可查

第一步：確認 binlog 日誌是否處於開啟狀態 ？

show variables like 'log_%';

第二步：開啟 MySQL binlog 日誌

首先找到 my.cnf 文件。

mysql --help | grep 'Default options' -A 1

可能會有一堆的 my.cnf，載入的優先順序順序如下，別傻傻分不清。

不過也有可能 my.cnf 文件都是空空如也，別以為是見鬼啦，空空如也，就根據需要添加自己的配置就行。

vim /etc/my.cnf 

#添加 
[mysqld]
#設置日誌格式
binlog_format=mixed
#日誌文件的名字及存儲路徑（咱們這次配置的路徑為預設）
log-bin=mysql-bin
#表示單個節點的id，用來在集群中區別伺服器
server-id=1

第三步：重啟 MySQL

不同的系統，重啟指令也不同，我是 Mac 系統，操作如下

sudo /usr/local/mysql/support-files/mysql.server restart

第四步：確認 binlog 日誌是否真開啟啦？

show variables like 'log_%';

第五步： 熟練使用命令。

查看 binlog 所有日誌列表：show master logs;

查看最新一個 binlog 日誌的信息：show master status;

秘訣二：望聞問切，辨證施藥

病理一：Python 菇涼一怒之下，刪除了去東京的旅途記憶。

望聞問切：查看 mysql-bin.000003 日誌文件中記錄的 Python 菇涼的操作，找到上一步的狀態位置。

show binlog events in 'mysql-bin.000003';

確診：從 binlog 的事件中可以看斷出執行 Python 菇涼執行 delete from memories 語句前的 position 節點為 1240，所以恢復開始的 pos 節點為 962，停止的 pos 節點為 1240 。

施藥：採用 mysqlbinlog 完成恢復，治療效果杠杠滴，去東京的旅途記憶又回來啦。

mysqlbinlog /usr/local/mysql/data/mysql-bin.000003 --start-position 962 --stop-position 1240 | mysql -u root -p travel

病理二：Python 菇涼一怒之下，刪除了所有的旅途記憶。

望聞問切：查看 mysql-bin.000003 日誌文件中記錄的 Python 菇涼的操作，找到上一步的狀態位置。

show binlog events in 'mysql-bin.000003';

確診：從 binlog 的事件中可以看斷出執行 Python 菇涼執行 drop table memories 語句前的 position 節點為 1873，所以恢復開始的 pos 節點為 154，停止的 pos 節點為 1873 。

施藥：採用 mysqlbinlog 完成恢復，治療效果杠杠滴，神奇的是所有的旅途記憶都回來啦。

mysqlbinlog /usr/local/mysql/data/mysql-bin.000003 --start-position 154 --stop-position 1873 | mysql -u root -p travel

病理三：Python 菇涼一怒之下，把資料庫都刪掉了。

望聞問切：查看 mysql-bin.000003 日誌文件中記錄的 Python 菇涼的操作，找到上一步的狀態位置。

show binlog events in 'mysql-bin.000003';

確診：從 binlog 的事件中可以看斷出執行 Python 菇涼執行 drop database t_t 語句前的 position 節點為 3938，所以恢復開始的 pos 節點為 3847，停止的 pos 節點為 3938 。

施藥：採用 mysqlbinlog 完成恢復，治療效果杠杠滴，神奇的是資料庫也回來啦。

mysqlbinlog /usr/local/mysql/data/mysql-bin.000003 --start-position 3847 --stop-position 3938 | mysql -u root -p

秘訣三：應試技巧

又到年底了，有人已經按奈不住想試試機會啦！

靈魂一問：MySQL 主從複製怎麼實現的？不多說，就放一圖，自行感悟！

靈魂二問：MySQL binlog 的格式有幾種？

binlog 的格式有三種：STATEMENT、ROW、MIXED 。
STATMENT：每一條會修改數據的 SQL 語句會記錄在 binlog 中。
ROW：不記錄每一條 SQL語句的上下文信息，僅記錄哪條記錄被修改。
MIXED：以上兩種模式的混合使用，一般的複製使用STATEMENT模式保存binlog，對於STATEMENT模式無法複製的操作使用ROW模式保存binlog，MySQL會根據執行的 SQL 語句選擇日誌保存方式。

好了，今天的分享，到這就結束啦，希望你們能夠喜歡。