一、起因
昨天刷个人博客还是好好的，今天晚上突然就进不去了
来时好好的咋就回不去了呢
按照以往的经验来看，还是数据库出了问题，可能是服务器内存不足了(服务器是2核8G的，上面跑了几个自用的系统包括数据库)导致请求响应超时，但是上周刚花了200块大洋升级了一下服务器应该也不会出这个问题，带着疑惑我登录了服务器，查看docker的运行情况
mysql没有挂、后端服务也没有挂掉
会不会是nginx挂掉了？ 于是查看了一下nginx配置发现nginx运行也依然很正常，并且查看了服务器内存使用也是正常的
好吧。。 事情到这儿，需要更深层次的一探究竟了，于是尝试链接数据库。。 惊人的一句报错出现了
我去！！！这是数据库没了？赶紧docker登录下mysql，输入账号密码之后
show databases;
duang的一下。里面居然没有博客的数据库
会不会是登录账号的权限被收回了？
show grants for root;
结果显示正常的。 结论已经很明显了：有人删库了，但是我不知道谁删的
虽然到饭点了，但还是解决问题先
于是乎我连做好的饭，都没来得及吃上，想赶紧把这个事解决掉。
二、处理
1）当时安装mysql比较匆忙，先查看下binlog有没有开启吧 如果开启了，可以通过binlog是确定是不是删了库了
show variables like 'log_bin';
幸运的是开启了binlog
2）既然开启了那么binlog存在哪里呢？
cd /var/lib/mysql
这里还真有binlog
3）那么4和5到底是哪个文件呢？
show binary logs;
两个log文件到底是哪个呢？
show master status;
ok果然是这个占用空间多的
4）找到这个文件了，怎么去恢复log呢?到底能不能行，不试试怎么知道行不行。多方查询资料 mysql提供了一个专门操作二进制文件的命令:mysqlbinlog。好那么用这个恢复binlog应该没错了。 先看下这个log内容
show binlog events in 'binlog.000005';
好的找到证据了，就是有人删我库了
里面记录了mysql事务操作节点，那么根据这个命令使用的话恢复起来应该也不难
终端输入
mysqlbinlog
果然没那么顺利！这个命令在mysql里执行起来并不是那么顺畅。但是坚信恢复数据就是这个命令的我，决定说什么也要执行一次。
5）直接到/usr/bin 去找
cd /usr/bin
脚本果然在里面
6）那么见证奇迹的时候就来了
把整理好的命令脚本的形式执行
./mysqlbinlog --stop-position=2467444 /var/lib/mysql/binlog.000005 | mysql -uroot -p
刷新网页：haozengrun.com
可以访问了！ok很开心。
在看下ok数据都在。
7）记录下mysqlbinlog的常用参数
开始pos点--start-position=321
结束pos点--stop-position=120
起始时间点--start-datetime='2022-03-26 00:00:00'
结束时间点--stop-datetime='2022-03-26 00:00:00'
数据库--database=abc
8）整理下其他场景使用，以备不时之需
问题1: 为什么有这么多log
答：每次服务器（数据库）重启，服务器会调用 flush logs; 新创建一个binlog日志
问题2: pos开始点和结束点到底按照什么去执行？
答：指定数据库的话，按照数据库去执行
没指定数据库按照整个log进行恢复
指定时间按照时间去恢复
问题3: 恢复的数据和现有的数据冲突怎么办？
答：会有脏数据，解决办法，大事化小，小事化了，尽可能按照时间去恢复数据吧。。
