5. Mysql的binlog介绍

参考：InnoDB学习（三）之BinLog

1. BinLog介绍

BinLog又称为二进制日志，是MySQL服务层的数据日志，MySQL所有的存储引擎都支持BinLog。

BinLog记录了MySQL中的数据更新和可能导致数据更新的事件，可以用于主从复制或数据恢复。

服务层日志与Mysql使用的引擎(innodb、myisam)无关，存储引擎层日志与引擎有关。

文章目录

[1. BinLog介绍](#1. BinLog介绍)
[2. 查看](#2. 查看)
[3. BinLog的格式](#3. BinLog的格式)
- [3.1 Statement格式](#3.1 Statement格式)
- [3.2 Row格式](#3.2 Row格式)
- [3.3 Mixed格式](#3.3 Mixed格式)
- [3.4 优缺点](#3.4 优缺点)
[4. binlog的作用](#4. binlog的作用)
- [4.1 数据恢复](#4.1 数据恢复)
- [4.2 主从复制](#4.2 主从复制)
- [4.3 主从复制步骤](#4.3 主从复制步骤)
[5. binlog 结构解析](#5. binlog 结构解析)
总结

2. 查看

需要确认安装的mysql的 binglog是开启的

查看有多少个binlog

bash 复制代码

show binary logs;

3. BinLog的格式

MySQL有三种BinLog格式，各有优劣：

Statement格式的BinLog：此模式下MySQL会记录所有可能会变更数据的SQL语句；
Row格式的BinLog：：此模式下会记录数据库每一行数据的变化情况；
Mixed格式的BinLog：Statement和Row格式的混合；

3.1 Statement格式

Statement格式的BinLog会记录每一条可能修改数据库数据的sql语句，主从复制或数据恢复时可以在对应机器上执行同样的SQL来达到数据的一致。然而Statement不支持一些特殊的SQL语句，如语句中包含UUID函数/LOAD DATA IN FILE语句等。

3.2 Row格式

Row格式的BinLog会记录每一行数据被修改的情况，但是Row格式的BinLog往往会比较大。比如对于SQL语句update user_info set name='test' where 1=1，Statement格式的BinLog只会存储这条SQL语句，但是对于Row格式的BinLog，生成日志的大小就取决于表的大小，如果表中有1亿条数据，那么就需要生成1亿条BinLog记录。

Row格式的BinLog也有不同的记录方式，可以通过参数binlog_row_format设置。FULL: 记录修改行的所有列数据；MINIMAL: 仅记录修改行中有发生数据变化的列；NOBOLB: 和FULL方式相似，仅仅是当blog或text这些列没有进行修改时，不会记录这些属性的列

3.3 Mixed格式

Mixed格式的BinLog结合了Statement和Row格式的优点，对于普通的SQL语句使用Statement格式的BinLog记录，对于一些特殊的SQL（如包含UUID的SQL），使用ROW格式的BinLog记录。

对于数据库隔离级别为读已提交或读未提交的场景，Mixed会使用会使用ROW格式的BinLog存储记录。

3.4 优缺点

Statement格式：
- 优点：日志量小，节约磁盘和网络IO；
- 缺点：需要记录语句的上下文(如时间等)，不具有确定性的函数(如UUID)无法复制；
Row格式：
- 优点：可以记录数据库的所有变更；
- 缺点：如果单个SQL语句涉及的行均比较多，那么会导致日志量非常大；

4. binlog的作用

MySQL的BinLog主要有以下两个作用

数据恢复：数据库数据丢失后，我们可以从某个时间节点的数据备份和该时间点之后的BinLog来恢复数据库的数据；
主从复制：主从复制过程中，主数据库将自身的BinLog发送给从数据库，从数据库通过解析BinLog同步主数据库的数据变更，从而达到主从数据一致；

4.1 数据恢复

MySQL数据库可以恢复某个时间点的状态，这个恢复过程就是通过BinLog实现的。BinLog会记录数据库所有的逻辑操作，并且是采用"追加写"的形式。如果你的DBA承诺说半个月内可以恢复，那么备份系统中一定会保存最近半个月的所有BinLog，同时系统会定期做整库备份。这里的"定期"取决于系统的重要性，可以是一天一备，也可以是一周一备。

当需要恢复到指定的某一秒时，比如某天下午两点发现中午十二点有一次误删表，需要找回数据，那你可以这么做：

首先，找到最近的一次全量备份，如果你运气好，可能就是昨天晚上的一个备份，从这个备份恢复到临时库；

然后，从备份的时间点开始，将备份的BinLog依次取出来，重放到中午误删表之前的那个时刻。

这样你的临时库就跟误删之前的线上库一样了，然后你可以把表数据从临时库取出来，按需要恢复到线上库去。

4.2 主从复制

MySQL的主从复制是一个异步的复制过程，数据将从一个MySQL数据库（Master）复制到另一个MySQL数据库（Slave），在Master和Slave之间实现整个主从复制的过程是由三个线程参与完成的。其中两个线程（SQL线程和IO线程）在Slave端，另一个线程（I/O线程）在Master端。

MySQL主从复制的步骤如下所示：

4.3 主从复制步骤

MYSQL主从复制包含以下步骤：

在Slave服务器上执行start slave命令开启主从复制开关，开始进行主从复制。
Slave服务器的IO线程会通过在master上已经授权的复制用户权限请求连接Master服务器，并请求从执行binlog日志文件中的指定位置（日志文件名和位置就是在配置主从复制服务时执行change master命令指定的）之后开始发送binlog日志内容。
Master服务器接收来自Slave服务器的IO线程的请求后，其上负责复制的IO线程会根据Slave服务器的IO线程请求的信息分批读取指定binlog日志文件指定位置之后的binlog日志信息，然后返回给Slave端的IO线程。返回的信息中除了binlog日志内容外，还有在Master服务器端记录的IO线程。
当Slave服务器的IO线程获取到Master服务器上IO线程发送的日志内容、日志文件及位置点后，会将binlog日志内容依次写到Slave端自身的RelayLog（即中继日志）文件（http://Mysql-relay-bin.xxx）的最末端，并将新的binlog文件名和位置记录到master-info文件中，以便下一次读取master端新binlog日志时能告诉Master服务器从新binlog日志的指定文件及位置开始读取新的binlog日志内容
Slave服务器端的SQL线程会实时检测本地Relay Log 中IO线程新增的日志内容，然后及时把Relay LOG 文件中的内容解析成sql语句，并在自身Slave服务器上按解析SQL语句的位置顺序执行应用这样sql语句，并在http://relay-log.info中记录当前应用中继日志的文件名和位置点.

5. binlog 结构解析

总结

1.binlog文件会随服务的启动创建一个新文件

2.通过flush logs 可以手动刷新日志，生成一个新的binlog文件

3.通过show master status 可以查看binlog的状态

4.通过reset master 可以清空binlog日志文件

5.通过mysqlbinlog 工具可以查看binlog日志的内容

6.通过执行dml，mysql会自动记录binlog