介绍
日志主要分为错误日志、慢查日志、查询日志、事物日志、二进制日志类型。
像数据备份、主主、主备、主从、故障恢复等都需要通过binlog来做数据同步。
当MySQL执行增删改时都会在binlog
中留下记录日志，对于数据表的变更操作也会留下记录。
binlog记录的数据
- DDl 用户操作数据库、表、行的记录。例如：Create、Drop、Alter
- DML 用户对数据的操作，例如：Insert、Update、Delete
- TCL 事物控制语言 Commit、Rollback
以下MySQl语言则不会记录在binlog中。
- DCL 用来控制权限，例如Grant
- DQL 数据库查询语句，例如 Select
Binlog操作
查看当前MySQl对与binlog相关配置
1 | show variable like "%bin_log%" |
- bin_log: binlog日志记录是否开启
- bin_log_basename: binlog保存所在的文件夹
- bin_log_index: binlog的索引文件，通过索引文件可以查找到所有binlog文件
- sql_log_bin: 用于主从复制，如果关闭，数据的变更则不会记录到binlog日志中，而不会复制到丛库。
查看使用的类型
1 | show variables like "%binlog_format%" |
展示当前记录binlog的类型。
Binlog日志类型
Stament:
记录数据库表变更操作，生成的文件相对较小。
Row:
记录变更的数据内容，记录了整行内容，会导致文件较大。批量操作会产生大量日志，alter table会让数据大量增加。
Mixed:
混合使用Stament和Row，因为是系统自动选择使用某种方式，可能会选择不够理想的记录方式，导致一些不一致或性能影响。
同步机制
MySQL Binlog主要解决主从复制功能，通过Binlog同步有三种方式，异步复制、同步复制、半同步复制。
异步复制
MySQL在接收到执行命令，执行事务结束完后将日志记入Binlog中就直接返回客户端。
并不关心从库是否同步成功。
这样的隐患是，当主库执行完成记录binlog成功后，从库在未同步成功之前，主库当机了，这时从库变成主库，就导致这段Binlog内容丢失。
同步复制
MySQL接收到执行命令，执行写入后，写入Binlog。
通知从库开始同步。
所有从库同步完成后发送ACK消息给主库。
主库再提交事务。
然后才会返回给客户端结果。
这种同步机制会导致执行效率下降。
半异步复制
MySQL接收到执行命令，执行写入后，将日志写入Binlog。
通知一个从库进行同步。
从库同步完成后发送ACK给主库。
主库再执行事务提交。
然后主库才会返回客户端成功。
因为也是需要等待从库同步成功的ACK消息，所以性能上也会有一定缺失。
MySQL5.7.2之后默认就是半异步复制机制