删库了一定要跑路吗？爱情 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_%';
病理一：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 语句选择日志保存方式。
好了，今天的分享，到这就结束啦，希望你们能够喜欢。
