mysql中的binlog:

概述

MySQL中的binlog是记录所有数据库表结构变更(例如 CREATE、ALTER TABLE)

以及表数据的修改(INSERT、UPDATE、DELETE)的二进制文件,,binlog 不会记录查询相关的操作,因为这类操作对于表的结构和数据本省没有进行修改.这些查询操作是可以通过查看系统通用日志来查看相关语句.

binlog的主要目的是复制和恢复，且是事务安全型的。

binlog以事件形式记录.记录的操作都有对应的事件,statement格式中的DML操作对应的是query_event ;类型,row 格式下的DML操作对应的是rows_event类型.

binlog主要有三种格式：

• statement ： 是基于SQL语句模式。某些语句和函数如 UUID, LOAD DATA INFILE 等在复制过程可能导致数据不一致甚至出错。
• row： 基于行的模式，记录的是行的变化，很安全。但是 binlog 会比其他两种模式大很多，在一些大表中清除大量数据时在 binlog 中会生成很多条语句，可能导致从库延迟变大。
• mixed： 混合模式，根据语句来选用是 statement 还是 row 模式。

binlog日志对于mysql数据库来说是十分重要的。在数据丢失的紧急情况下，可以尝试用binlog日志功能进行数据恢复操作。

正是由于binlog日志以上的特性，在实际的案件取证中也可以通过binlog日志来恢复删除数据。

在与数据库相关的服务和操作都需要用到它.

操作

在mysql命令行中查看binlog备份功能是否开启,如图所示部分为on,则是开启的.

如果不是: 可以编辑配置文件: /etc/my.cnf

在文件末尾追加:

log-bin=/usr/local/data/mysql-bin

server-id=1

然后重启mysql.

systemctl restart mysqld

同时在/etc/my.cnf ,也可以配置一些其他相关binlog的设置参数.

默认的mysql的binlog文件是存放在 /var/lib/mysql 目录中,是根据时间记录的

同时在命令行中,或在mysql运行界面中,执行命令都会重新刷新一个新的binlog文件的生成

在mysql命令行中数据flush logs 命令就会刷新出一个新的binlog文件，这个文件是记录从这一时刻往后的所有操作。,每当mysql服务重启时,会自动执行这个命令,刷新binlog日志文件,在mysqldump 备份时加上-F选项也会刷新binlog日志文件,

在使用普通的cat命令是查看不出这种文件的内容，只是一堆乱码。使用两种方式查看:

1,在命令中输入:  mysqlbinlog  binlog.0000*

但读取的日志内容较多,不容易分辨出pos点信息.

2. mysql> show binlog events [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count];

选项解析：
IN 'log_name' 指定要查询的binlog文件名(不指定就是第一个binlog文件)
FROM pos 指定从哪个pos起始点开始查起(不指定就是从整个文件首个pos点开始算)
LIMIT [offset,] 偏移量(不指定就是0)
row_count 查询总条数(不指定就是所有行)

使用show binary logs 命令可以查看当前有多少个binlog文件

show master status; 命令: .查看master状态，即最后(最新)一个binlog日志的编号名称，及其最后一个操作事件pos结束点(Position)值

reset master; 则是会清空所有binlog日志(谨慎使用)

show binlog events 命令 查看到binlog的事件

这里显示的每一行:

log_name :当前事件所在binlog文件名称

pos : 当前事件的开始位置,每个时间都占用固定的字节大小,.同时,第一行的pos是从4开始的,这里mysql通过文件的前4个字节来判断文件是不是一个binlog文件.

event_type:表示事件的类型

server_id : 表示这个产生这个时间的mysql的id

end_log_pos :事件结束位置

info: 是对当前事件的sql语句描述信息

binlog的写入流程

事务执行过程中，binlog 首先会被写到 binlog cache 中；事务提交的时候，再讲binlog cache 写到 binlog 文件中。一个事务的 binlog 是原子的，无论多大都需要保证完整性。

系统为每个客户端线程分配一个 binlog cache ,其大小由 binlog_cache_size控制,如果binlog_cache 超过限值,就会历史持久化到磁盘中,当事务提交的时候,在将binlog cache中完整事务持久化到磁盘中,并清空binlog_cache

从上面可以看出，每个客户端线程都有自己独立的 binlog cache，但是会共享一份 binlog files。

上面的 write 是指把binlog cache 写到文件系统的 page cache，并没有写入到磁盘中，因此速度较快。

fsync 是实际的写盘操作，占用磁盘的 IOPS。

write 和 fsync 的写入时机，是由sync_binlog 控制的：

sync_binlog=0：每次事务提交都只 write，不 fsync；

sync_binlog=1：每次事务提交都会fsync；

sync_binlog=N（N>1）：每次提交事务都会 write，累计N 个后再执行 fsync。

在出现 IO 瓶颈的情况下，可以考虑将 sync_binlog 设置成一个大的值。比较常见的是将 N设置为 100~1000。但是存在的风险是，当主机异常重启时会丢失 N 个最近提交的事务 binlog。

原文链接：https://blog.csdn.net/fouy_yun/article/details/103743793