日志系统
日志系统
redo log重做日志
redo log为InnoDB引擎特有的物理日志,记录了:“在某个数据页上做了什么修改” 的操作,循环写入,具备着占用空间小、顺序写磁盘的优点
write pos作为当前记录的位置,一边写一边顺时针移动;checkpoint作为当前要擦除的位置,一边擦出一边顺时针移动,在擦除记录前要把数据落盘
write pos和checkpoint之间的空白 就可以用来记录新的操作,如果write pos追上了checkpoint,就需要停止更新,将记录落盘以推进checkpoint
通过redo log就能保证数据库异常重启后,之前提交的记录不丢失,即crash-safe
redolog的写入机制
在事务执行过程中,生成的日志会写入到redo log buffer,直到最终真正执行commit 的时候才会将redo log buffer中的日志写入到redo log文件中
redo log可能有的三种状态:存在buffer中(内存);write到磁盘但没有fsync持久化(page cache);持久化(磁盘)
redo log写入到redo log buffer
在实际的过程中,redolog是以组的形式写入到redo log buffer中的,即是以一个mtr里所有的redo日志为基本单位整体写入的
每组redo日志都对应着一个LSN值,即日志逻辑序列号,表示当前系统写入buffer中 的redo log量(LSN = 当前所占用的所有redo log buffer的空间总和),每次写入长度为length的redo log,LSN的值就会再加上length,它也会被写入到InnoDB数据页中,用来确保数据页不会多次执行重复的redo log
如果有多个并发事务,当trx1开始写盘时,此时组里已有trx2和trx3(LSN=160),那么trx1写盘时带的值就是LSN=160(此时的redo log buffer里面已经包含到LSN=160的redo log了);因此等trx1返回时,所有LSN<160的redo log已经被持久化了,这时候的trx2和trx3可以直接返回
在这种组提交机制下,组员越多,节约磁盘IOPS的效果越好,
redo log buffer刷盘到磁盘
事务执行期间如果MySQL发生异常重启,则redo log buffer会丢失其中的redo log,但由于事务没有提交,所以丢失redo log并没有影响
InnoDB有一个后台线程,每隔1秒就会把redo log buffer中的日志,调用write写入到文件系统的page cache,然后调用fsync持久化到磁盘
由于事务执行过程中的redo log也会直接写在redo log buffer中,这些redo log也会被后台线程一起持久化到磁盘,所以一个没有提交事务的redo log也有可能已经持久化了
同时,redo log buffer 占用的空间即将达到 innodb_log_buffer_size 一半的时候,后台线程会主动写盘,且并行的事务提交的时候,顺带将这个事务的 redo log buffer 持久化到磁盘
可以通过参数innodb_flush_log_at_trx_commit控制redo log写入策略
- = 0:每次事务提交只是把redo log 留在 redo log buffer
- = 1:每次事务提交都将redo log 持久化(在两阶段提交中的prepare阶段 即 fsync,commit阶段只write)
- = 2:每次事务提交都只把redo log写到page cache
binlog归档日志
binlog是MySQL的Server层实现的逻辑日志,记录语句的原始逻辑,比如:”给ID=2这一行的c字段+1“,作为追加写的日志,binlog写到一定大小后会切换到下一个,不会覆盖之前的日志
binlog的格式
statement格式的binlog最后有COMMIT,row格式的binlog最后有XID event,同时引入binlog-checksum参数,通过这三个方面可以让MySQL验证binlog的完整性
statement格式下的binlog日志就是存储着执行的语句原文,如:
但在这种格式下,因为delete带着limit,可能会因为删除选取的索引不同,而导致用于主备时导致主备数据不一致
row格式下的binlog日志记录了server id,table_map(在哪个库上面做的操作)以及真正操作的行主键id,如:
这就避免了statement格式下可能导致的主备数据不一致的问题,在越来越多的场景下使用row都更方便数据恢复
但row格式下的binlog日志耗费空间严重,同时耗费传输binlog时的IO资源影响执行速度,所以出现了兼备statement格式和row格式的mixed格式
单纯的binlog是 不具备 crash-safe 的,原因是:binlog没有能力恢复数据页,由于WAL技术,执行事务写完内存和日志,事务就算完成了,如果发生崩溃需要依赖日志来恢复数据页,因为binlog并没有记录数据页的更新细节,系统很难判断需要从哪个事务的binlog开始重放
相比redo log,binlog用处主要有2个:
- 归档:相比redolog的循环写,binlog是追加写,可以保留历史日志
- 复制:作为实现主从复制一部分的binlog二进制日志,可以支持从库做增量复制
利用binlog做数据恢复:系统定期做整库备份,需要数据恢复时找到最近一次全量备份,然后从备份的时间点开始以此取出binlog,重放到想要的时刻
binlog的写入机制
事务执行过程中,先把日志写到binlog cache,提交时再把binlog cache写入到binlog文件中,一个事务的binlog不能拆开,需要确保一次性写入
每个线程都有自己的binlog cache,但共用一份binlog files
每个线程通过write将日志写到文件系统的page cache;随后再通过fsync将binlog files持久化到磁盘(此时才占磁盘的IOPS)
可以通过参数sync_binlog控制write和fsync的时机
- = 0 每次commit 事务只write,不fsync;
- = 1每次都会fsync;
- =N,累计N个事务后才fsync
在出现IO瓶颈时,会将它设置为一个比较大的值提升性能,但会有丢失最近N个事务的binlog日志的风险
WAL 与 两阶段提交
update T set c=c+1 where ID=2;
的执行过程如下
引擎将新数据更新到内存中,会先把更新操作记录到redo log,令其处于prepare状态,然后告知执行器执行完成,可提交事务;执行器生成该操作的binlog并写入磁盘;执行器提交事务,引擎将刚才的redo log改成commit状态
两阶段提交:将redo log的写入拆成了两个步骤 prepare 和 commit,由于redolog 和 binlog 都可以用于表示事务的提交状态,所以两阶段提交的目的就是保证两个日志之间的逻辑一致
如果没有两阶段提交,就要么先写入redolog再写binlog,或先写binlog再写redolog,如果在写完一个日志后系统崩溃,就会导致主从数据库不一致、恢复后数据与原数据不一致的情况发生
binlog和redolog都有一个数据字段:XID,基于两阶段提交进行崩溃恢复:
- 顺序扫描redo log,碰到既有prepare又有commit的redo log,说明该事务已经顺利commit,则直接提交事务
- 如果碰到只有prepare没有commit的redo log,就用XID去找到该事务对应的binlog,如果binlog是完整的,则提交事务,否则回滚事务
组提交机制优化:实际上会将redo log的fsync 以及 binlog 的fsync 放在一起,让一次fsync所带的组员更多,从而实现binlog的组提交
WAL:write-ahead-logging,关键点在于先写日志,再写磁盘,当一条记录需要更新的时候,InnoDB会先把记录写到日志中并更新内存,此时视为更新完成,直至系统空闲时将这个操作记录写入磁盘,提高磁盘IO效率的原因来自:
- redo log和binlog都是顺序写,磁盘的顺序写比随机写速度要快
- 组提交机制,可以大幅度降低磁盘的IOPS消耗