网站留言功能,用自己主机做网站,西安公众号开发公司,扫一扫识别图片点击蓝色“JavaKeeper”关注我哟加个“星标”#xff0c;一起成长#xff0c;做牛逼闪闪的技术人Keeper导读#xff1a;日志是mysql数据库的重要组成部分#xff0c;记录着数据库运行期间各种状态信息。mysql日志主要包括错误日志、查询日志、慢查询日志、事务日志、二进制… 点击蓝色“JavaKeeper”关注我哟加个“星标”一起成长做牛逼闪闪的技术人Keeper导读日志是mysql数据库的重要组成部分记录着数据库运行期间各种状态信息。mysql日志主要包括错误日志、查询日志、慢查询日志、事务日志、二进制日志几大类。作为开发我们重点需要关注的是二进制日志(binlog)和事务日志(包括redo log和undo log)本文接下来会详细介绍这三种日志。来源https://sourl.cn/EtrNut全文共 4222 字阅读需要 8 分钟binlogbinlog用于记录数据库执行的写入性操作(不包括查询)信息以二进制的形式保存在磁盘中。binlog是mysql的逻辑日志并且由Server层进行记录使用任何存储引擎的mysql数据库都会记录binlog日志。逻辑日志可以简单理解为记录的就是sql语句。物理日志因为mysql数据最终是保存在数据页中的物理日志记录的就是数据页变更。binlog是通过追加的方式进行写入的可以通过max_binlog_size参数设置每个binlog文件的大小当文件大小达到给定值之后会生成新的文件来保存日志。binlog使用场景在实际应用中binlog的主要使用场景有两个分别是主从复制和数据恢复。主从复制在Master端开启binlog然后将binlog发送到各个Slave端Slave端重放binlog从而达到主从数据一致。数据恢复通过使用mysqlbinlog工具来恢复数据。binlog刷盘时机对于InnoDB存储引擎而言只有在事务提交时才会记录biglog此时记录还在内存中那么biglog是什么时候刷到磁盘中的呢mysql通过sync_binlog参数控制biglog的刷盘时机取值范围是0-N0不去强制要求由系统自行判断何时写入磁盘1每次commit的时候都要将binlog写入磁盘N每N个事务才会将binlog写入磁盘。从上面可以看出sync_binlog最安全的是设置是1这也是MySQL 5.7.7之后版本的默认值。但是设置一个大一些的值可以提升数据库性能因此实际情况下也可以将值适当调大牺牲一定的一致性来获取更好的性能。binlog日志格式binlog日志有三种格式分别为STATMENT、ROW和MIXED。在 MySQL 5.7.7之前默认的格式是STATEMENTMySQL 5.7.7之后默认值是ROW。日志格式通过binlog-format指定。STATMENT 基于SQL语句的复制(statement-based replication, SBR)每一条会修改数据的sql语句会记录到binlog中。优点不需要记录每一行的变化减少了binlog日志量节约了IO, 从而提高了性能缺点在某些情况下会导致主从数据不一致比如执行sysdate()、slepp()等。ROW 基于行的复制(row-based replication, RBR)不记录每条sql语句的上下文信息仅需记录哪条数据被修改了。优点不会出现某些特定情况下的存储过程、或function、或trigger的调用和触发无法被正确复制的问题缺点会产生大量的日志尤其是alter table的时候会让日志暴涨MIXED 基于STATMENT和ROW两种模式的混合复制(mixed-based replication, MBR)一般的复制使用STATEMENT模式保存binlog对于STATEMENT模式无法复制的操作使用ROW模式保存binlogredo log为什么需要redo log我们都知道事务的四大特性里面有一个是持久性具体来说就是只要事务提交成功那么对数据库做的修改就被永久保存下来了不可能因为任何原因再回到原来的状态。那么mysql是如何保证一致性的呢最简单的做法是在每次事务提交的时候将该事务涉及修改的数据页全部刷新到磁盘中。但是这么做会有严重的性能问题主要体现在两个方面因为Innodb是以页为单位进行磁盘交互的而一个事务很可能只修改一个数据页里面的几个字节这个时候将完整的数据页刷到磁盘的话太浪费资源了一个事务可能涉及修改多个数据页并且这些数据页在物理上并不连续使用随机IO写入性能太差因此mysql设计了redo log具体来说就是只记录事务对数据页做了哪些修改这样就能完美地解决性能问题了(相对而言文件更小并且是顺序IO)。redo log基本概念redo log包括两部分一个是内存中的日志缓冲(redo log buffer)另一个是磁盘上的日志文件(redo log file)。mysql每执行一条DML语句先将记录写入redo log buffer后续某个时间点再一次性将多个操作记录写到redo log file。这种先写日志再写磁盘的技术就是MySQL里经常说到的WAL(Write-Ahead Logging) 技术。在计算机操作系统中用户空间(user space)下的缓冲区数据一般情况下是无法直接写入磁盘的中间必须经过操作系统内核空间(kernel space)缓冲区(OS Buffer)。因此redo log buffer写入redo log file实际上是先写入OS Buffer然后再通过系统调用fsync()将其刷到redo log file中过程如下imgmysql支持三种将redo log buffer写入redo log file的时机可以通过innodb_flush_log_at_trx_commit参数配置各参数值含义如下参数值含义0(延迟写)事务提交时不会将redo log buffer中日志写入到os buffer而是每秒写入os buffer并调用fsync()写入到redo log file中。也就是说设置为0时是(大约)每秒刷新写入到磁盘中的当系统崩溃会丢失1秒钟的数据。1(实时写实时刷)事务每次提交都会将redo log buffer中的日志写入os buffer并调用fsync()刷到redo log file中。这种方式即使系统崩溃也不会丢失任何数据但是因为每次提交都写入磁盘IO的性能较差。2(实时写延迟刷)每次提交都仅写入到os buffer然后是每秒调用fsync()将os buffer中的日志写入到redo log file。imgredo log记录形式前面说过redo log实际上记录数据页的变更而这种变更记录是没必要全部保存因此redo log实现上采用了大小固定循环写入的方式当写到结尾时会回到开头循环写日志。如下图同时我们很容易得知在innodb中既有redo log需要刷盘还有数据页也需要刷盘redo log存在的意义主要就是降低对数据页刷盘的要求。在上图中write pos表示redo log当前记录的LSN(逻辑序列号)位置check point表示数据页更改记录刷盘后对应redo log所处的LSN(逻辑序列号)位置。write pos到check point之间的部分是redo log空着的部分用于记录新的记录check point到write pos之间是redo log待落盘的数据页更改记录。当write pos追上check point时会先推动check point向前移动空出位置再记录新的日志。启动innodb的时候不管上次是正常关闭还是异常关闭总是会进行恢复操作。因为redo log记录的是数据页的物理变化因此恢复的时候速度比逻辑日志(如binlog)要快很多。重启innodb时首先会检查磁盘中数据页的LSN如果数据页的LSN小于日志中的LSN则会从checkpoint开始恢复。还有一种情况在宕机前正处于checkpoint的刷盘过程且数据页的刷盘进度超过了日志页的刷盘进度此时会出现数据页中记录的LSN大于日志中的LSN这时超出日志进度的部分将不会重做因为这本身就表示已经做过的事情无需再重做。redo log与binlog区别redo logbinlog文件大小redo log的大小是固定的。binlog可通过配置参数max_binlog_size设置每个binlog文件的大小。实现方式redo log是InnoDB引擎层实现的并不是所有引擎都有。binlog是Server层实现的所有引擎都可以使用 binlog日志记录方式redo log 采用循环写的方式记录当写到结尾时会回到开头循环写日志。binlog 通过追加的方式记录当文件大小大于给定值后后续的日志会记录到新的文件上适用场景redo log适用于崩溃恢复(crash-safe)binlog适用于主从复制和数据恢复由binlog和redo log的区别可知binlog日志只用于归档只依靠binlog是没有crash-safe能力的。但只有redo log也不行因为redo log是InnoDB特有的且日志上的记录落盘后会被覆盖掉。因此需要binlog和redo log二者同时记录才能保证当数据库发生宕机重启时数据不会丢失。undo log数据库事务四大特性中有一个是原子性具体来说就是 原子性是指对数据库的一系列操作要么全部成功要么全部失败不可能出现部分成功的情况。实际上原子性底层就是通过undo log实现的。undo log主要记录了数据的逻辑变化比如一条INSERT语句对应一条DELETE的undo log对于每个UPDATE语句对应一条相反的UPDATE的undo log这样在发生错误时就能回滚到事务之前的数据状态。同时undo log也是MVCC(多版本并发控制)实现的关键。
