【MySQL】利用二进制文件进行数据恢复

查看二进制文件是否开启

show variables like ‘log_bin’

二进制文件存放的地址

此处是在window下

利用二进制文件恢复数据

关于MysqLbinlog的使用参考官网： https://dev.MysqL.com/doc/refman/5.7/en/MysqLbinlog.html
这里没有截图，按照这个顺序走即可，这里只是实现一个简单的数据恢复，后期在深入来了解这部分

-- 先创建一个数据库做操作：community
CREATE DATABASE `community` ;
USE community;

-- 添加测试的数据表
CREATE TABLE `count` (
  `prefix` char(255) NOT NULL,
  `count` smallint(8) DEFAULT NULL COMMENT '当天插入记录条数',
  `historyCount` int(20) DEFAULT NULL COMMENT '历史插入记录',
  PRIMARY KEY (`prefix`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

-- 添加对应的测试数据
insert into count values('dd1', 1, 0);
insert into count values('dd2', 0);
insert into count values('dd3', 0);

-- 查看日志文件列表
SHOW BINARY LOGS;

-- 查看日志文件的具体信息
show binlog events in 'MysqL-bin.000001';

-- 导入到sql文件中
MysqLbinlog --skip-gtids /usr/local/MysqL/data/MysqL-bin.000001 > /usr/local/MysqL/data/community.sql

运行检测内容
vim /usr/local/MysqL/data/community.sql;

MysqL57 -u root -p -e "source /usr/local/MysqL/data/community.sql"

然后可以做一个比较暴力或者直接的操作；把数据表count删除
drop table `count`;

-- 或者执行

delete from `count`;
然后进行数据的还原：
MysqL57 -u root -p -e "source /usr/local/MysqL/data/community.sql"

关于binlog的写入时间节点

sync_binlog=0: 对于日志刷新到磁盘基本上MysqL是不会自己控制刷新，由文件系统自己控制它的缓存刷新。这时候的性能最好，但是风险也是最大的。因为一旦系统出问题在binlog_cache中的所有binlog信息都会被丢失

sync_binlog=1: 启用在事务提交之前将二进制日志同步到磁盘。这是最安全的设置，但是由于磁盘写操作的增加，可能会对性能产生负面影响。在发生电源故障或操作系统崩溃时，二进制日志中缺少的事务只处于准备状态。这允许自动恢复例程回滚事务，从而确保二进制日志中没有丢失任何事务。

sync_binlog=N：其中N是0或1之外的值:在收集了N个二进制日志提交组之后，将二进制日志同步到磁盘。在发生电源故障或操作系统崩溃时，服务器可能提交了未刷新到二进制日志的事务。由于磁盘写的数量增加，此设置可能对性能产生负面影响。值越大，性能越好，但是数据丢失的风险越大。

在MysqL8.0中默认是值1