jsp建网站,wordpress 插件api,企业营销案例,网络移动公司的网站建设MySQL 日志#xff1a;undo log、redo log、binlog 有什么用#xff1f; 一、前言
在MySQL数据库中#xff0c;undo log、redo log和binlog这三种日志扮演着至关重要的角色#xff0c;它们各自承担着不同的功能#xff0c;共同保障了数据库的正常运行和数据的完整性。了解…MySQL 日志undo log、redo log、binlog 有什么用 一、前言
在MySQL数据库中undo log、redo log和binlog这三种日志扮演着至关重要的角色它们各自承担着不同的功能共同保障了数据库的正常运行和数据的完整性。了解它们的工作原理和作用对于深入理解MySQL数据库的运行机制以及进行性能优化和故障排查都具有重要意义。
二、基础篇
MySQL的数据存储于磁盘读写操作若频繁直接访问磁盘效率较低。为提升性能InnoDB存储引擎设计了缓冲池Buffer Pool以页默认16KB为单位缓存数据包括索引页、数据页、Undo页等。
三、undo log
一undo log的作用
事务回滚undo log由InnoDB存储引擎生成用于实现事务的原子性。在事务执行“增删改”操作时MySQL会隐式开启事务undo log会记录更新前的数据。若事务执行中途MySQL崩溃可利用undo log回滚到事务之前的数据状态。MVCC多版本并发控制对于“读提交”和“可重复读”隔离级别的事务其快照读通过Read View undo log实现。不同隔离级别创建Read View的时机不同从而控制并发事务访问同一记录时的行为。
二undo log的记录方式
当InnoDB引擎对记录进行操作修改、删除、新增时会把回滚所需信息记录到undo log中。如插入记录时记录主键值删除记录时记录内容更新记录时记录被更新列的旧值。不同操作产生的undo log格式不同且每条记录的更新操作产生的undo log都有roll_pointer指针和trx_id事务id可串成版本链。
三undo log的刷盘机制
undo log和数据页的刷盘策略一致都需通过redo log保证持久化。buffer pool中有undo页对undo页的修改会记录到redo logredo log每秒刷盘提交事务时也刷盘以此保证undo log的持久化。
四、redo log
一redo log的作用
实现事务持久性Buffer Pool基于内存为防止断电导致数据丢失InnoDB引擎在更新数据时先更新内存标记为脏页再将修改以redo log形式记录事务提交时只需将redo log持久化到磁盘无需等待脏页写入磁盘。系统崩溃重启后可依据redo log恢复数据保证已提交记录不丢失即crash - safe能力。提升写入性能写入redo log采用追加操作是顺序写而写入数据是随机写磁盘顺序写比随机写高效得多WAL技术将MySQL的写操作从随机写变为顺序写提升了写入性能。
二redo log的缓存与刷盘时机
缓存执行事务过程中产生的redo log先写入redo log buffer其默认大小16MB可通过innodb_log_Buffer_size参数调整。刷盘时机 MySQL正常关闭时当redo log buffer中记录的写入量大于其内存空间一半时InnoDB的后台线程每隔1秒每次事务提交时由innodb_flush_log_at_trx_commit参数控制默认值为1取值0表示事务提交时redo log留在buffer中取值2表示事务提交时redo log写入文件但不保证写入磁盘。
三redo log文件组与循环写机制
默认InnoDB存储引擎有1个重做日志文件组由2个redo log文件ib_logfile0和ib_logfile1组成大小固定且一致。以循环写方式工作write pos表示当前记录位置checkpoint表示可擦除位置。当write pos追上checkpoint即redo log文件满时会暂停执行新更新操作将脏页刷新到磁盘擦除旧记录移动checkpoint然后恢复正常运行。
五、binlog
一binlog的作用
数据备份与恢复记录了所有数据库表结构变更和表数据修改的日志不记录查询操作。当数据库数据丢失或损坏时可利用binlog进行数据恢复。主从复制MySQL的主从复制依赖于binlog主库将binlog传输到从库从库通过回放binlog实现数据同步。
二binlog与redo log的区别
适用对象binlog是MySQL的Server层实现的日志所有存储引擎都可使用redo log是InnoDB存储引擎实现的日志。文件格式binlog有STATEMENT逻辑日志记录SQL语句、ROW记录行数据最终修改结果、MIXED包含前两种模式三种格式redo log是物理日志记录数据页的修改。写入方式binlog是追加写写满创建新文件保存全量日志redo log是循环写空间固定保存未刷盘的脏页日志。用途binlog用于备份恢复、主从复制redo log用于掉电等故障恢复。
三主从复制的实现与模型
实现过程主库写binlog日志并提交事务更新本地数据从库I/O线程连接主库log dump线程接收binlog写入relay log中继日志从库回放线程读relay log回放binlog更新数据实现主从数据一致性。复制模型 同步复制主库提交事务线程等待所有从库复制成功响应性能差、可用性低。异步复制默认主库提交事务线程不等待从库复制主库宕机可能丢数据。半同步复制MySQL 5.7版本新增事务线程等待部分从库复制成功响应兼顾性能和数据安全。
四binlog的刷盘时机
事务执行中先将日志写入binlog cache事务提交时把binlog cache写入binlog文件。MySQL通过sync_binlog参数控制刷盘频率取值0表示只write不fsync交由操作系统决定持久化时机取值1表示每次提交事务都write并fsync取值NN1表示累积N个事务后fsync。
六、两阶段提交
一两阶段提交的原因
事务提交时redo log和binlog都要持久化到磁盘若出现半成功状态会导致两份日志逻辑不一致在主从架构中造成数据不一致问题。为避免此问题MySQL采用两阶段提交。
二两阶段提交的过程
prepare阶段将XID内部XA事务的ID写入redo log将事务状态设置为prepare然后将redo log持久化到磁盘。commit阶段把XID写入binlog将binlog持久化到磁盘接着调用引擎提交事务接口将redo log状态设置为commit。
三异常重启的处理
在两阶段提交不同时刻MySQL异常重启若redo log处于prepare状态重启后会根据binlog中是否存在相同XID决定事务提交或回滚。若存在则提交不存在则回滚以此保证两份日志一致性。
四两阶段提交的问题与优化
问题 磁盘I/O次数高“双1”配置下每个事务提交进行两次fsync一次redo log刷盘一次binlog刷盘。锁竞争激烈早期通过prepare_commit_mutex锁保证事务提交顺序并发量大时锁争用严重性能不佳。 优化 - 组提交 binlog组提交将多个binlog刷盘操作合并减少磁盘I/O次数。commit阶段拆分为flush将binlog从cache写入文件、sync对binlog文件fsync合并刷盘、commit各个事务按顺序做InnoDB commit操作三个过程每个阶段有队列和锁保护第一个进入队列事务为leader负责整队操作。redo log组提交MySQL 5.7将prepare阶段融合在flush阶段延迟redo log刷盘到flush阶段sync阶段之前实现redo log组写入。 #mermaid-svg-IOV42a0tk4ylFNkE {font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}#mermaid-svg-IOV42a0tk4ylFNkE .error-icon{fill:#552222;}#mermaid-svg-IOV42a0tk4ylFNkE .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-IOV42a0tk4ylFNkE .edge-thickness-normal{stroke-width:2px;}#mermaid-svg-IOV42a0tk4ylFNkE .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-IOV42a0tk4ylFNkE .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-IOV42a0tk4ylFNkE .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-IOV42a0tk4ylFNkE .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-IOV42a0tk4ylFNkE .marker{fill:#333333;stroke:#333333;}#mermaid-svg-IOV42a0tk4ylFNkE .marker.cross{stroke:#333333;}#mermaid-svg-IOV42a0tk4ylFNkE svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-IOV42a0tk4ylFNkE .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-IOV42a0tk4ylFNkE .cluster-label text{fill:#333;}#mermaid-svg-IOV42a0tk4ylFNkE .cluster-label span{color:#333;}#mermaid-svg-IOV42a0tk4ylFNkE .label text,#mermaid-svg-IOV42a0tk4ylFNkE span{fill:#333;color:#333;}#mermaid-svg-IOV42a0tk4ylFNkE .node rect,#mermaid-svg-IOV42a0tk4ylFNkE .node circle,#mermaid-svg-IOV42a0tk4ylFNkE .node ellipse,#mermaid-svg-IOV42a0tk4ylFNkE .node polygon,#mermaid-svg-IOV42a0tk4ylFNkE .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-IOV42a0tk4ylFNkE .node .label{text-align:center;}#mermaid-svg-IOV42a0tk4ylFNkE .node.clickable{cursor:pointer;}#mermaid-svg-IOV42a0tk4ylFNkE .arrowheadPath{fill:#333333;}#mermaid-svg-IOV42a0tk4ylFNkE .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-IOV42a0tk4ylFNkE .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-IOV42a0tk4ylFNkE .edgeLabel{background-color:#e8e8e8;text-align:center;}#mermaid-svg-IOV42a0tk4ylFNkE .edgeLabel rect{opacity:0.5;background-color:#e8e8e8;fill:#e8e8e8;}#mermaid-svg-IOV42a0tk4ylFNkE .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-IOV42a0tk4ylFNkE .cluster text{fill:#333;}#mermaid-svg-IOV42a0tk4ylFNkE .cluster span{color:#333;}#mermaid-svg-IOV42a0tk4ylFNkE div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-IOV42a0tk4ylFNkE :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 前言 基础概念 undo log 作用事务回滚MVCC 记录方式 刷盘机制 redo log 作用事务持久提升写入 缓存与刷盘 文件组与循环写 binlog 作用备份恢复主从复制 与redo log区别 主从复制实现与模型 刷盘时机 两阶段提交 原因避免日志不一致 过程preparecommit 异常处理 问题与优化组提交 总结
