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

笑着哭i 提交于 2020-04-04 09:51:11

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

  

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

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!