Mysql有多种日志,承担着不同的功能。
BinLog高可用的基石
Binlog是Mysql的server层记录的日志,包含表结构和数据的变更。Binlog有两个常用的作用,一个是用作数据库恢复,通过数据库快照和binlog,我们可以把数据库恢复到任意时刻。另一个是用于数据库复制,通过将binlog传给其他数据库副本,然后再执行binlog中的sql实现数据的同步,构建出一套高可用的数据库服务。
使用show global variables like 'log_bin';
可以查看日志是否开启。在Mysql5.7默认是不开启,可通过--log-bin=xx开启,xx代表日志文件的名称。在Mysql8.0之后是默认开启,可以使用--skip-log-bin或--disable-log-bin进行禁用。
日志格式
Binlog有三种格式,通过--binlog-format启动参数进行设置,也可以通过系统变量查看当前binlog_format的值。
show global variables like 'binlog_format';
+-------------+-----+
|Variable_name|Value|
+-------------+-----+
|binlog_format|MIXED|
+-------------+-----+
-
statment,基于语句的模式,记录原始的sql。这种模式存在不确定的问题,例如下面这条语句的now()函数取的是当前时间,在从库重新执行这个sql时,时间值跟主库执行的时间必然不同。
-- 原始SQL BEGIN; update post set updated_date = now() where id <= 10; COMMIT;-- bin log文件 # at 123456 #210714 12:34:56 server id 1 end_log_pos 123 Query thread_id=123 exec_time=0 error_code=0 SET TIMESTAMP=123456; BEGIN; update post set updated_date = now() where id <= 10; COMMIT;
-
row(默认值),基于行变更的模式,记录sql影响每条数据的变化。日志里记录的数据就比较多。
-- 原始SQL BEGIN; update post set updated_date = now() where id <= 10; COMMIT;-- bin log文件 # at 123456 #210714 12:34:56 server id 1 end_log_pos 123 Xid = 456 BEGIN #210714 12:35:00 server id 1 end_log_pos 234 Table_map: `demo`.`post` mapped to number 123 #210714 12:35:05 server id 1 end_log_pos 345 Update_rows: table id 123 flags: STMT_END_F ### UPDATE `demo`.`post` ### WHERE ### @1=1 ### SET ### @2='2023-12-01 12:34:56' #210714 12:35:10 server id 1 end_log_pos 456 Update_rows: table id 123 flags: STMT_END_F ### UPDATE `demo`.`post` ### WHERE ### @1=2 ### SET ### @2='2023-12-01 12:34:57' # ... (类似的 Update_rows 记录,覆盖 id 为 3 到 10) #210714 12:35:15 server id 1 end_log_pos 567 Xid = 456 COMMIT
-
mixed,statment和row混合模式,默认情况下使用statment格式记录日志,日志内容会少一些,在特殊情况下会使用row格式。例如,使用这些函数,UUID()、FOUND_ROWS()、ROW_COUNT()、USER()、CURRENT_USER()、LOAD_FILE()或者使用系统变量时,会用到row模式。
写日志的时机
对于innodb引擎。mysql在引擎提交事务时,先保存binlog再完成事务提交。为了保证数据一致性,完整的流程是先把redo log设置成prepare状态,再提交binlog,然后把redo log设置为commit状态。
RedoLog
redolog是innodb引擎提供的日志,日志会记录数据执行sql前后的变化。redo log在磁盘上存储时会有很多种格式类型,下面例子只是说明会记录哪些信息:
-- 原始SQL
BEGIN;
update user set name = '小李' where id = 1;
insert into user(id, name) values(2, '小红');
delete from user where id = 3;
COMMIT;-- 日志内容示意
TransactionID: 127
PageID: 462
Operation: MULTIPLE_UPDATES
Updates:- UpdateType: UPDATEBefore Image: (1, '小明')After Image: (1, '小李')- UpdateType: INSERTAfter Image: (2, '小红')- UpdateType: DELETEBefore Image: (3, '小张')
使用redo log能提升数据库写入的性能,并且在数据库奔溃时,帮助数据库恢复到崩溃前的状态。
提升写入性能
redo log以AWL(Ahead Write Log)的方式记录日志,通过顺序写日志的方式记录变更。数据库中的记录存是放在磁盘的不同位置,直接修改数据会产生随机io,性能比顺序io要差。
另外,数据库会创建几个(默认4个,8.0.30改成了32个)日志文件合成日志组,循环记录日志。当一个文件满了就会写入到下一个文件,当最后一个文件满了,又重新写入到第一个文件。为了避免新日志写入会覆盖之前的日志,当redo log提交后,会有后台线程清理掉这部分日志数据,把文件空出来。日志组有write pos和checkpoint两个指针来记录新日志写到哪个位置,以及旧日志已经清除的位置。当write pos追上checkpoint时,数据库就要停下来将一部分日志变更sync到磁盘并擦除日志,把位置空出来。
奔溃恢复
数据库发生crash,会导致部分事务的数据还没提交完成。在重启数据库的时候就需要将这部分数据恢复回去。哪些数据需要恢复是根据redo log和bin log综合进行判断。
在描述奔溃恢复逻辑之前,我们先看一下redo log和binlog的写入过程。
两阶段提交
在事务内执行变更sql会生成redo log,因为事务还没提交所以redo log还不能直接落盘。这时会把修改先记录到log buffer,在提交事务时,先把redo log的状态设置为prepare并存入磁盘,然后提交binlog存入磁盘,最后将redo log设置为commit状态存日磁盘。这也是分布式事务常用的方式,是为了保证redo log和binlog的事务性。
然后我们看下,这个过程中不同时刻数据库发生crash需要怎么恢复:
- 写入log buffer后,数据库奔溃。因为数据只是写入了内存,redo log和binlog还没记录,所以丢失后就相当于事务回滚了。
- redo log完成prepare保存,数据库奔溃。这时binlog还没提交,所以数据变更事件还没同步给从库,所以可以直接回滚本地事务。
- binlog已经提交,数据库奔溃。这时redo log已经处于prepare阶段,redo log里的内容是完整的,binlog内容也是完整的,并且binlog的数据已经同步给从库,这时候只能提交事务,把redo log设置为commit。
- redo log的commit已提交,那么说明事务已经处理成功,把事务设置成完成。
落盘策略
redo log在事务未提交前会先写入到log buffer。然后在事务提交时,再写入page cache,最后同步回磁盘。根据数据可靠性和性能的考虑,数据库提供了三种落盘策略,由innodb_flush_log_at_trx_commit参数控制:
0:redo log先写入log buffer,由后台线程每秒写入page cache并同步到磁盘。这个方式性能最高,但数据库crash会导致数据丢失。
1:redo log会马上同步到磁盘(这个是默认值),性能差一点,但数据可靠性高。
2:redo log先写入到page cache,由后台线程每秒将日志写入磁盘。这个过程数据库crash不会影响page cache的内容,但是服务器宕机会导致数据丢失。
另外,可以通过innodb_flush_log_at_timeout控制log buffer刷新到磁盘的频率,默认1秒,最大值是2700秒。
UndoLog
undo log记录了事务内的所有数据变更,用于回滚事务和实现一致性读。当数据行更新后后,会生成一条undo log,记录之前的值。然后数据行会有一个隐藏的字段Roll Pointer指针,指向上一条undo log的位置。如果同一条记录有多次更新,就会有多条undo log,形成链表。
单条日志的格式如下:
-- 原始SQL
BEGIN;
update user set name = '小李' where id = 1;
COMMIT;-- 日志内容示意
-------------------------------------
| Transaction ID | 123456
| Roll Pointer | 789012
| Transaction Type | UPDATE
| Table ID | 456
| Page Number | 789
| Slot Number | 1
| Undo Record Type | Regular Undo
| Undo Record Size | 100 bytes
| SQL Operation | UPDATE user SET name = '小李' WHERE id = 1;
| Undo Segment ID | 789012
| Segment State | ACTIVE
| Transaction State | COMMITTED
| Prev Transaction ID| 789455
| 其他记录信息
-------------------------------------
需要回滚事务,就通过记录里的Roll Pointer指针,找到上一条redo log,然后更新成原来的值。
一致性读
在可重复读的事务隔离级别,多次查询同一条记录,看到的结果是一样的,我们称这个现象为一致性读。
一致性读依赖于MVCC,MVCC的多个版本指的是一行记录存在多个版本,记录每次更新就会产生一个新版本。这里的新版本并不是说一行记录会拷贝成多份,记录只存最新的一条,然后之前的版本会各自对应一条undo log,日志里会记录变更内容的原始值。一致性读就是从最新版本开始,沿着redo log链找到当前事务可见的版本,将沿途的undo log都执行一次,就是当前事务能看到的数据状态。
例如:
- t1时刻,事务tx1,查询select name,age from user where id = 1;结果是‘小李’和25。
- t2时刻,事务tx2,将update user set name = ‘小明’ where id = 1;结果是‘小明’和25。undo log 1记录name=‘小李’
- t3时刻,事务tx3,将update user set age= 26 where id = 1;结果是‘小明’和26。undo log 2记录age=25
- t4时刻,事务tx1,再查询select name,age from user where id = 1;结果依然是‘小李’和25。这时,会从‘小明’和26开始,执行undolog 2,结果得到‘小明’和25;再执行undelog 1,结果得到‘小李’和25。
UndoLog对事务性能的影响
事务变更数据的时候需要记录undo log,undo log的数量是有限的。undo log存放于undo log segments,undo log segments会包含多个事务的undo log,但同时只能被一个事务使用。所以新事物只能等之前的事务提交或回滚之后才能,才能用它的undo log segments。undo log segments默认是数据页的1/16,innodb数据页是16k,所以undo log segments默认是1024。
undo log segments存放于rollback segments,rollback segments默认是128个,通过show global variables like 'innodb_rollback_segments';
查看。
rollback segments从undo tablespace或者global temperary tablespaces(全局临时表空间)分配。undo tablespace默认分配2个,也可以自己添加。global temperary tablespaces是1个。undo log数量公式是:
undo log数量 = tablespaces * rollback segments * undo log segments
所以,非内存表能分配2×128×1024=262144个undo log segments,内存表1×128×1024=131072个undo log segments,
一个事务会消耗的undo log数量是不一样的,有四种情况会消耗undo log:
- 非内存表的所有insert会放入一个undo log
- 非内存表的所有update或delete会放入一个undo log
- 内存表的所有insert会放入一个undo log
- 内存表的所有update或delete会放入一个undo log
如果事务里包含这四种操作,就会占用四个log rollback segment。当undo log数量不够时,就会影响事务写入。