删库了一定要跑路吗？爱情 36 技之记忆重生！

今天一位跨界老码农不知咋回事，兴奋过了头，一不小心把数据库给删掉啦，然后问我咋恢复，然后我告诉他基于 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 语句选择日志保存方式。

　　

好了，今天的分享，到这就结束啦，希望你们能够喜欢。