查看二进制文件是否开启
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个二进制日志提交组之后，将二进制日志同步到磁盘。在发生电源故障或操作系统崩溃时，服务器可能提交了未刷新到二进制日志的事务。由于磁盘写的数量增加，此设置可能对性能产生负面影响。值越大，性能越好，但是数据丢失的风险越大。
