MySQL Binlog--事务日志和BINLOG落盘参数对磁盘IO的影响

本文涉及的产品
RDS MySQL DuckDB 分析主实例,集群系列 4核8GB
RDS MySQL DuckDB 分析主实例,基础系列 4核8GB
RDS AI 助手,专业版
简介: MySQL Binlog--事务日志和BINLOG落盘参数对磁盘IO的影响

mysql主从延迟,最近项目中遇到一个mysql 主从同步延迟非常严重的问题。

修改双0,立马下来。

 

innodb_flush_log_at_trx_commit这个参数关系到事务日志落地,

默认参数1 每一次事务提交或事务外的指令都需要把日志写入硬盘,io开销大

参数0 每隔一秒把log buffer刷到文件系统中去,并且调用文件系统的“flush”操作将缓存刷新到磁盘上去。这样的话,可能丢失1秒的事务数据。

参数 2 在每次事务提交的时候会把log buffer刷到文件系统中去,但是每隔一秒调用文件系统的“flush”操作将缓存刷新到磁盘上去。


这里解释下,系统文件和磁盘介质之间也有缓存,这里的0 是提交日志之后,每隔1秒将logbuffer刷到系统文件中,并马上执行落盘操作,写到到物理介质

2呢是刷到系统文件系统之后,每隔1秒调用flush,写到物理介质,并不是马上


两者的区别是,0:当mysql挂了之后,可能会损失前一秒的事务信息

2:当mysql挂了之后,如果系统文件系统没挂,不会有事务丢失

 

参数说明

innodb_flush_log_at_trx_commit和sync_binlog 两个参数是控制MySQL 磁盘写入策略以及数据安全性的关键参数,不同参数设置对磁盘IO影响不同。

 

参数innodb_flush_log_at_trx_commit


innodb_flush_log_at_trx_commit=0:每秒一次将Log Buffer中数据写入到Log File中,并且Flush到磁盘。事务提交不会主动触发写磁盘操作。
innodb_flush_log_at_trx_commit=1:每次事务提交时将Log Buffer数据写入到Log File中,并且Flush到磁盘。
innodb_flush_log_at_trx_commit=2:每次事务提交时将Log Buffer数据写入到Log File中,但不立即Flush到磁盘,MySQL会每秒一次刷新到磁盘。
由于进程调度问题,每条一次操作不能保证每一秒都执行一次。
当innodb_flush_log_at_trx_commit=0时,最近一秒的事务日志存在MySQL的Log Buffer中,无论时MySQL实例停止还是MySQL服务器宕机,都会导致最近一秒的事务日志丢失。
当innodb_flush_log_at_trx_commit=1时,最近一秒的事务日志存在操作系统的文件缓存中,MySQL实例停止不会导致事务日志丢失,但MySQL服务器宕机会导致最近一秒事务日志丢失。
上述的一秒一次刷新,取决于参数innodb_flush_log_at_timeout默认值为1,DDL或其他InnoDB内部操作并不受参数innodb_flush_log_at_trx_commit的限制。


图片来源于:https://www.h3399.cn/201809/614170.html

 

参数sync_binlog:

sync_binlog=0:每次事务提交后,将Binlog Cache中的数据写入到Binlog文件,但不立即刷新到磁盘。由文件系统(file system)决定何时刷新到磁盘中。
sync_binlog=N:每N次事务提交后,将Binlog Cache中的数据写入到Binlog文件,调用fdatasync()函数将数据刷新到磁盘中。
当sync_binlog=0(默认设置)时,不会执行强制刷盘指令,性能最好同时风险最高。
当sync_binlog=N时,当MySQL服务器宕机后,会导致最近N个事务的BINLOG丢失。

 

BINLOG和REDO/UNDO LOG的区别


1、处理层次不同,REDO/UNDO LOG由Innodb存储引擎处理,而BINLOG由MySQL 服务层处理。
2、记录内容不同,REDO/UNDO LOG记录的数据页的修改情况,REDO LOG采用物理日志+逻辑日志的方式存储,UNDO LOG采用逻辑日志方式存储,用于保证数据一致性;而BINLOG日志记录的事务操作的内容,用于主从复制。
3、记录时机不同,REDO/UNDO LOG在事务的执行过程中不断生成和写入,而BINLOG在事务最终COMMIT前写入。
4、涉及到数据更新的SELECT操作会被记录到BINLOG中(基于语句格式复制)。
5、BINLOG刷新到磁盘的行为由参数sync_binlog决定,而REDO LOG写入磁盘的行为受参数innodb_flush_log_at_trx_commit的影响。
6、可以通过会话级参数SQL_LOG_BIN来设置某事务不生成BINLOG,但不能通过参数控制是否生成事务日志。


 

某台从库存在严重的复制延迟,调整参数后性能变化:

1、主库(MySQL 5.5版本)凌晨2点开始清理历史数据。
2、从库(MySQL 5.7版本)开启多线程复制,但由于从库做多源复制且单线程复制(主库MySQL 5.5),磁盘使用率飙升至80%,出现复制延迟。
3、从库在08:35调整参数为双0,CPU使用率从3%提升至7%,磁盘使用率从75%降至8%,磁盘写次数从8500下降至2200,复制延迟开始下降。
4、从库在08:51复制无延迟,积压时间被消费完,CPU使用率恢复至1%,磁盘使用率从8%降至1%,磁盘写次数从2200下降至300。
5、从库在09:01调整参数为双1,CPU使用率无变化,磁盘使用率从1%升至8%,磁盘写次数从300升职2200。

 

IOPS测试

创建测试表:


## 创建测试表
CREATE TABLE `tb003` (
  `ID` bigint(20) NOT NULL AUTO_INCREMENT,
  `C1` int(11) DEFAULT NULL,
  `DT` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`ID`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;


创建测试脚本:

#!/bin/bash
for i in $(seq 1 10000)  
do   
/export/servers/mysql/bin/mysql --host='127.0.0.1' --port=3358 --user='root' --password="root_psw" -e 'insert into db001.tb003(c1)values(0);' 1>/dev/nul 2>&1
done

运行测试脚本发现,每秒执行230个左右事务,使用iostat -dxk 1查看发现服务器每秒写1380,事务提交次数和每秒IO写次数的比约为1:6。

 

https://www.cnblogs.com/gaogao67/p/11023837.html


相关实践学习
自建数据库迁移到云数据库
本场景将引导您将网站的自建数据库平滑迁移至云数据库RDS。通过使用RDS,您可以获得稳定、可靠和安全的企业级数据库服务,可以更加专注于发展核心业务,无需过多担心数据库的管理和维护。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。   相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情: https://www.aliyun.com/product/rds/mysql 
相关文章
|
7月前
|
SQL 运维 关系型数据库
深入探讨MySQL的二进制日志(binlog)选项
总结而言,对MySQL binlogs深度理解并妥善配置对数据库运维管理至关重要;它不仅关系到系统性能优化也是实现高可靠性架构设计必须考虑因素之一。通过精心规划与周密部署可以使得该机能充分发挥作用而避免潜在风险带来影响。
214 6
|
8月前
|
存储 SQL 关系型数据库
MySQL中binlog、redolog与undolog的不同之处解析
每个都扮演回答回溯与错误修正机构角色: BinLog像历史记载员详细记载每件大大小小事件; RedoLog则像紧急救援队伍遇见突發情況追踪最后活动轨迹尽力补救; UndoLog就类似时间机器可倒带历史让一切归位原始样貌同时兼具平行宇宙观察能让多人同时看见各自期望看见历程而互不干扰.
447 9
|
9月前
|
存储 SQL 关系型数据库
MySQL的Redo Log与Binlog机制对照分析
通过合理的配置和细致的管理,这两种日志机制相互配合,能够有效地提升MySQL数据库的可靠性和稳定性。
284 10
|
11月前
|
SQL 监控 关系型数据库
MySQL日志分析:binlog、redolog、undolog三大日志的深度探讨。
数据库管理其实和写小说一样,需要规划,需要修订,也需要有能力回滚。理解这些日志的作用与优化,就像把握写作工具的使用与运用,为我们的数据库保驾护航。
663 23
|
存储 SQL 关系型数据库
mysql 的ReLog和BinLog区别
MySQL中的重做日志和二进制日志是确保数据库稳定性和可靠性的关键组件。重做日志主要用于事务的持久性和原子性,通过记录数据页的物理修改信息来恢复未提交的事务;而二进制日志记录SQL语句的逻辑变化,支持数据复制、恢复和审计。两者在写入时机、存储方式及配置参数等方面存在显著差异。
307 6
|
canal 消息中间件 关系型数据库
Canal作为一款高效、可靠的数据同步工具,凭借其基于MySQL binlog的增量同步机制,在数据同步领域展现了强大的应用价值
【9月更文挑战第1天】Canal作为一款高效、可靠的数据同步工具,凭借其基于MySQL binlog的增量同步机制,在数据同步领域展现了强大的应用价值
2140 4
|
SQL 关系型数据库 MySQL
【揭秘】MySQL binlog日志与GTID:如何让数据库备份恢复变得轻松简单?
【8月更文挑战第22天】MySQL的binlog日志记录数据变更,用于恢复、复制和点恢复;GTID为每笔事务分配唯一ID,简化复制和恢复流程。开启binlog和GTID后,可通过`mysqldump`进行逻辑备份,包含binlog位置信息,或用`xtrabackup`做物理备份。恢复时,使用`mysql`命令执行备份文件,或通过`innobackupex`恢复物理备份。GTID模式下的主从复制配置更简便。
1817 2
|
存储 SQL 关系型数据库
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log、原理、写入过程;binlog与redolog区别、update语句的执行流程、两阶段提交、主从复制、三种日志的使用场景;查询日志、慢查询日志、错误日志等其他几类日志
1071 35
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
|
SQL 关系型数据库 MySQL
【MySQL】根据binlog日志获取回滚sql的一个开发思路
【MySQL】根据binlog日志获取回滚sql的一个开发思路
|
12月前
|
SQL 运维 关系型数据库
MySQL Binlog 日志查看方法及查看内容解析
本文介绍了 MySQL 的 Binlog(二进制日志)功能及其使用方法。Binlog 记录了数据库的所有数据变更操作,如 INSERT、UPDATE 和 DELETE,对数据恢复、主从复制和审计至关重要。文章详细说明了如何开启 Binlog 功能、查看当前日志文件及内容,并解析了常见的事件类型,包括 Format_desc、Query、Table_map、Write_rows、Update_rows 和 Delete_rows 等,帮助用户掌握数据库变化历史,提升维护和排障能力。

推荐镜像

更多