说说MySQL里面的日志种类

约定不等于承诺〃 2022-12-16 06:43 79阅读 0赞

*  redo log（重做日志）
    
     *  作用：防止事务提交的数据未写入磁盘，可以根据redo日志进行重做，保持事务一致性。
     *  内容：记录物理页需要修改的信息
     *  开始：随着事务的产生而产生
     *  结束：当事务提交后，脏页数据被写入磁盘则完成了任务
     *  文件形式：ib\_logfile1&ib\_logfile2
     *  相关配置：
        
         *  innodb\_log\_group\_home\_dir 指定日志文件组所在的路径，默认./ ，表示在数据库的数据目录下。
         *  innodb\_log\_files\_in\_group 指定重做日志文件组中文件的数量，默认2
         *  innodb\_log\_file\_size 重做日志文件的大小。
         *  innodb\_mirrored\_log\_groups 指定了日志镜像文件组的数量，默认1
     *  执行流程：事务开始之后逐步写入重做日志文件，重做日志有一个缓存区Innodb\_log\_buffer，Innodb\_log\_buffer的默认大小为8M(这里设置的16M),Innodb存储引擎先将重做日志写入innodb\_log\_buffer中。
     *  日志刷盘情况
        
         *  Master Thread 每秒一次执行刷新Innodb\_log\_buffer到重做日志文件。
         *  每个事务提交时会将重做日志刷新到重做日志文件。
         *  当重做日志缓存可用空间 少于一半时，重做日志缓存被刷新到重做日志文件  
            ![在这里插入图片描述][20201019144314912.png_pic_center]  
            ![在这里插入图片描述][20201019144338412.png_pic_center]
 *  undo log（撤销日志）
    
     *  作用：保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读（MVCC），也即非锁定读
     *  内容：逻辑格式的日志，在执行undo的时候，仅仅是将数据从逻辑上恢复至事务之前的状态，而不是从物理页面上操作实现的，这一点是不同于redo log的。
     *  开始：事务开始之前，将当前是的版本生成undo log，undo 也会产生 redo 来保证undo log的可靠性
     *  结束：当事务提交之后，判断是否有别的事务正在使用对应的MVCC记录有的话就继续保留。
     *  文件形式：ibdata1，注意该日志文件还记录了以下其他内容
        
         *  数据字典，也就是 InnoDB 表的元数据
         *  变更缓冲区
         *  双写缓冲区
         *  撤销日志
     *  相关配置：
        
         *  innodb\_undo\_directory = /data/undospace/ –undo独立表空间的存放目录
         *  innodb\_undo\_logs = 128 –回滚段为128KB
         *  innodb\_undo\_tablespaces = 4 –指定有4个undo log文件
     *  如果undo使用的共享表空间，这个共享表空间中又不仅仅是存储了undo的信息，共享表空间的默认为与MySQL的数据目录下面，其属性由参数innodb\_data\_file\_path配置。
     *  执行流程：undo是在事务开始之前保存的被修改数据的一个版本，产生undo日志的时候，同样会伴随类似于保护事务持久化机制的redolog的产生。默认情况下undo文件是保持在共享表空间的，也即ibdatafile文件中，当数据库中发生一些大的事务性操作的时候，要生成大量的undo信息，全部保存在共享表空间中的。因此共享表空间可能会变的很大，默认情况下，也就是undo 日志使用共享表空间的时候，被“撑大”的共享表空间是不会也不能自动收缩的。

![在这里插入图片描述][20201019144416320.png_pic_center]

![这里写图片描述][93fe3a1b27a0ef19d42001141c661818.png]

*  binlog
    
     *  作用：用户主从复制中，从库利用主库上的binlog进行重播，实现主从同步。用户数据基于时间点的还原
     *  格式：参见https://blog.csdn.net/hayre/article/details/109082486
     *  开始：当事务提交的时候记录到binlog
     *  结束：记录完成的时候则结束
     *  文件形式：mysql-bin
     *  与redo日志的区别：redo日志主要记录的是物理层的数据变动信息，支持从物理层面做数据库还原数据库。而binlog主要是从逻辑层面去回滚数据。关于事务提交时，redo log和binlog的写入顺序，为了保证主从复制时候的主从一致（当然也包括使用binlog进行基于时间点还原的情况），是要严格一致的，MySQL通过两阶段提交过程来完成事务的一致性的，也即redo log和binlog的一致性的，理论上是先写redo log，再写binlog，两个日志都提交成功（刷入磁盘），事务才算真正的完成  
        ![在这里插入图片描述][20201019144429368.png_pic_center]
 *  errorlog
    
     *  mysql的错误日志，主要用来定位排查MySQL启动报错，内存泄漏的等问题
 *  slow query log
    
     *  慢查询日志，用于定位系统中慢查询的SQL语句
 *  general log
    
     *  一般查询日志
 *  relay log
    
     *  中继日志，在从库上面出现，用户同步主库binlog拷贝到本地的relaylog中

参考：

https://blog.csdn.net/u012834750/article/details/79533866

[20201019144314912.png_pic_center]: /images/20221123/75801d1607b149e5a80ad13c28353d30.png
[20201019144338412.png_pic_center]: /images/20221123/4000b257c2b8427698c02e683cb83a34.png
[20201019144416320.png_pic_center]: /images/20221123/6d516ffdb3be4e5ca10925bdd9afe04b.png
[93fe3a1b27a0ef19d42001141c661818.png]: /images/20221123/4c3566d332aa46e8aaed9d3641a44876.png
[20201019144429368.png_pic_center]: /images/20221123/04a48cdbeebc487886aad2486e9a6908.png