mysql 日志

  • 事务的四大特性？怎么实现？主次关系

　　A 原子性 用undolog来保证

　　C数据的一致性

　　I隔离性：读写锁+mvcc机制

　　D：持久性 用redolog 和双写缓冲区保证

　　数据的一致性是目的，原子性、隔离性、持久性就手段；

  • 事务实现永久性的三个机制

　　WAL write-ahead log 先写日志  日志写好就代表事务提交了

　　CL commit logging 数据持久化后才代表数据提交了

　　shadow paging(影子分页)　　

  • redolog的记录内容

　　记录数据页产生的所有变化，包括page header 中的数据记录 槽数量、changebuffer对应的数据页更改、max rowid的变化等

　　是记录多种数据页 不单指常用的数据表中的数据。

　　在数据库正常运行的情况下，redolog 的功能是用不到的，数据永久化是通过刷脏页到磁盘的方式；在断电宕机需要crash的情况下才用到redolog的功能，保证数据不丢失。crash时数据的原子性（宕机时未提交 需要undolog的记录的redolog）还有持久性

  • redolog的type

　　有53种 包含简单的 MLOG-8byte  MLOG-1byte  MLOG-2byte  MLOG-4byte

　　复杂的redolog

  • redolog的缓存 log buffer，缓存大小redolog 磁盘持久化

　　redolog内存空间：默认是16M,分块一块512字节。 show variables like 'innodb_log_buffer_size';

　　根据参数设置可持久到磁盘中

　　show variables like "%innodb_log_file_size%"; 磁盘中存储redolog的空间 默认是48M

　　show variables like "%innodb_log_files_in_group%"; 磁盘中存储redolog的文件个数，默认是两个，最多设置成100个

　　都是循环写入，当脏页持久化到磁盘后，对应的redolog 日志删除

  • innodb_flush_log_at_trx_commit

　　0：事务提交的时候不持久到磁盘中  等待后台线程 每隔一秒刷新到磁盘，当断电 或者 mysql 崩溃的时候 可能丢失数据

　　1：缺省设置，事务提交的时候 调用fsync()函数强制刷新到磁盘中；

　　2.：事务提交的时候，将数据刷新到系统缓冲区中，当myqsl 异常的时候不会丢失数据

  • LSN

 　　log squence number 日志的序列号 开始为8704

　　根据此序列号可以确定 内存中的脏页和redolog 保持一致；联合check point 可以检查redolog 日志文件有没有写满 

　　show engine innodb status \G 

       

　　Log sequence number：代表系统中的lsn值，也就是当前系统已经写入的redo日志量，包括写入log buffer中的日志。

　　Log flushed up to：代表flushed_to_disk_lsn的值，也就是当前系统已经写入磁盘的redo日志量。

　　Pages flushed up to：代表flush链表中被最早修改的那个页面对应的oldest_modification属性值。

　　Last checkpoint at：当前系统的checkpoint_lsn值。

  • redolog 什么时候刷盘

　　log buffer 达到总容量的一半时

　　事务提交 innodb_flush_log_at_trx_commit 参数为1的时候

　　后台线程每隔一秒刷新一次

　　mysql 正常关闭的时候

  • redolog和binlog的区别

　　redolog:用于恢复因为系统崩溃引起的数据丢失，记录的是具体的表空间的具体页面的具体位置发生的变化逻辑；循环写入文件；根据LSN可以分辨可以和脏页数据保持一致：引擎层 innodb

　　binlog:用于客户端数据丢失恢复数据的文件，记录的是语句改变的逻辑；追加写入；不能替代redolog, 因为没有LSN和脏页保持一致；server层，依赖于原数数据库的备份文件，在备份文件恢复的基础上进行恢复数据

　　两者都是记录的数据更改逻辑，都需要依赖原始数据进行更改，

  • redolog和双写缓冲区的区别

　　redolog 恢复数据是要依赖原数据完整的条件下，把数据变化更提到数据页上；

　　双写缓冲区是在数据页损坏的情况下进行恢复数据页；两者恢复损毁数据的时间段不同

  • redolog和change buffer的区别

　　change buffer 也会记录日志到redolog中，

　　change buffer 主要记录非唯一的二级索引的变化。

　　merge的时间点：数据需要访问的时候、正常关闭mysql的时候

  • redolog和binlog保证数据一致的2PC

　　两段式提交 prepare commit

  • redolog和undolog的关系

　　undolog 也会记录日志到redolog中

  • 程序持久化磁盘的过程

  •  undolog是什么

　　是撤销日志，为了保证事务的原子性采用的日志策略。

　　以数据页的形式存储。所以也需要记录redo日志 是FIL_PAGE_UNDO_LOG形式的数据页。

　　insert的回滚日志：需要记录主键id ,回滚时删除聚簇索引和二级索引的数据。

　　delete的回滚日志：需要记录删除的数据，回滚时好找到原数据；

　　update的回滚日志：需要记录更改的数据；

  • 事务id

　　　对于只读事务（create/start transation read only）中的外部临时表 和读写事务（create/start transation (read write)）中的表来说，第一次进行增删改的时候会分配一个trx_id；

　　　trx_id 类似于row_id 是个全局变量，当时256的倍数时 持久化到磁盘里。当重启mysql时会读取到内存中+256作为当前trx_id;

  • 版本链

　　

 

 

 

　　　每当数据库执行一个新的DML操作时 就将上一次更改的相反操作记录在undolog版本链中，当前数据行的roll_ptr指向undolog版本链。

　　

　　1.DDL（DataDefinitionLanguage）：数据定义语言，用来定义数据库对象：库、表、列等；

　　2.DML（DataManipulationLanguage）：数据操作语言，用来定义数据库记录（数据）；

　　3.DQL（DataQueryLanguage）：数据查询语言，用来查询记录（数据）；

　　4.DCL（DataControlLanguage）：数据控制语言，用来定义访问权限和安全级别。

  • insert操作的回滚

　　undo日志只需要记录这条插入语句的id 即可，日志类型为：trx_undo_insert_REC ,当需要回滚的时候，用这个id在主键索引和二级索引中删除即可

  • delete操作的回滚

　　

 

 

             

 

 

 　　　

 

 

 

　　记录的日志类型是 TRX_UNDO_DEL_MARK_REC；

　　删除一条记录有两个阶段，删除后未提交的阶段，成为delete mark阶段。此阶段delete_mark被修改成了1，但是记录没有从正常数据的版本链中去除（保证了mvcc机制）；

　　当事务提交后，对delete mark比较成1 的记录进行了回收，从正常数据列表中去除，链接到了垃圾列表中，等待被复用，这个阶段成为purge阶段。在page header 中由page free 指向该列表；

　　当事务没有提交，删除数据处于delete mark阶段时进行回滚，可根据版本链直接修改 数据记录的delete mark的标志

  • update操作的回滚

　　分为三种情况：

　　1.更改主键：先删除（更改delete mark标志） 再在增加（mvcc机制，别的事务也可以看见这天更改未提交的数据）；有两条undo 日志 TRX_UNDO_DEL_MARK REC 和 TRX_UNDO_INSERT_REC

　　2.不更改主键并且数据大小有变化：针对变长的数据类型 有可能数据增加或者减小了，原来的空间不合适，所以需要把原来的数据记录删除（直接删除）再重新增加一条数据；

　　3.不更改主键且数据大小无变化：原地更改数据；in place update 

  • 正常事务执行流程

              

  • 事务回滚的流程

                

 

posted @ 2022-06-29 14:51  超超小仙女  阅读(137)  评论(0)  编辑  收藏  举报