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