Mysql - binlog日志、主从复制过程

    Mysql级别的日志比较多：主要有：Error log、General Query log、DDL log，可能我们比较关注的还是慢日志（Slow log）和binlog。现在只是分析binlog的一些特性，以及binlog在高可用集群（复制）中的应用，至于更复杂的binlog与redolog怎么保证一个事务语句的一致性和持久化（即崩溃恢复保证crash safe能力），后面单独分析。Binlog日志用于描述数据库更改（DML、DCL）的事件，不记录select、show等语句。

binlog包括两种文件：

    索引文件：后缀是.index

    日志文件：后缀是.00000*，分为两部分，一部分在缓存，一部分在硬盘，缓冲达到一定次数，会刷到磁盘里。

 

binlog的一些相关命令（在my.cnf(或者Windows中的my.ini)进行设置）有：

log_bin = on; 开关配置项：

show variables like 'log_bin'; 查看binglog是否开启

inlog_format = row; 设置binlog的模式

show variables like 'binlog_format'；查看当前服务器的binlog日志格式

set session binlog_format = 'ROW'; 也可以设置客户端会话级别的格式

show binary logs：查询binlog的文件列表，等同于主从中的主节点执行：show master logs；

 

binlog日志有三种格式：statement、row、mixed：

statement：记录的是发送的语句，当发送到其他slave节点上时，可以直接执行“sql”。记录如：update、delete、alter table等；

    优点：与Row模式相比，不需要记录每一行的数据变化，减少bin-log日志量，节约磁盘IO，提高新能；缺点：容易出现主从复制不一致

row：行模式。虽然是行模式，但是 create table、alter table、drop table等还是基于语句的格式。

    优点：能清楚的记录每一行数据修改的细节；缺点：数据量太大

mixed：混合模式可以理解成 statement + row。

 

使用binlog格式的场景有哪些要求？

1、如果InnoDB表，并且事务隔离级别为 Read committed、Read uncommitted事务隔离级别，只能使用行模式。

2、基于副本复制的情况下，只能使用Row、mixed模式

3、mi想模式中许多比较特殊的情况下会使用row记录，最明显的就是执行函数时，更多mixed模式使用行记录的情况https://dev.mysql.com/doc/refman/5.7/en/binary-log-mixed.html

 

binlog主要的用途：崩溃恢复，副本复制（都是解决单机性能问题，解决高可用问题）。下面只分析复制，情况比较多，比如：主从读写分离场景复制、主主复制、主从从等模式，根据项目情况搭建。下面是比较经典的主从复制场景，如下图（怕自己画的不好也是添加了一张比较标准的）：