MySQL:Innodb:innodb_flush_log_at_trx_commit参数影响的位置

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,高可用系列 2核4GB
简介:

  • 源码5.7.22
  • 影响阶段:MYSQL_BIN_LOG::ordered_commit 的flush阶段

一、影响的函数

innobase_flush_logs函数,函数如下其实注释也写得很清楚了。binlog_group_flush 参数为1。

/** Flush InnoDB redo logs to the file system.
@param[in]    hton            InnoDB handlerton
@param[in]    binlog_group_flush    true if we got invoked by binlog
group commit during flush stage, false in other cases.
@return false */
static
bool
innobase_flush_logs(
    handlerton*    hton,
    bool        binlog_group_flush)
{
    DBUG_ENTER("innobase_flush_logs");
    DBUG_ASSERT(hton == innodb_hton_ptr);

    if (srv_read_only_mode) {
        DBUG_RETURN(false);
    }

    /* If !binlog_group_flush, we got invoked by FLUSH LOGS or similar.
    Else, we got invoked by binlog group commit during flush stage. */

    if (binlog_group_flush && thd_flush_log_at_trx_commit(NULL) == 0) {
        /* innodb_flush_log_at_trx_commit=0
        (write and sync once per second).
        Do not flush the redo log during binlog group commit. */
        DBUG_RETURN(false);
    }

    /* Flush the redo log buffer to the redo log file.
    Sync it to disc if we are in FLUSH LOGS, or if
    innodb_flush_log_at_trx_commit=1
    (write and sync at each commit). */
    log_buffer_flush_to_disk(!binlog_group_flush
                 || thd_flush_log_at_trx_commit(NULL) == 1); 

    DBUG_RETURN(false);
}

二、可能的组合

  • innodb_flush_log_at_trx_commit参数为 0
    binlog_group_flush && thd_flush_log_at_trx_commit(NULL) == 0 条件成立,因此直接return了,那么这种情况下log_buffer_flush_to_disk函数不会调用,因此不会做redo刷盘。依赖master线程。
  • innodb_flush_log_at_trx_commit参数为 1
    !binlog_group_flush|| thd_flush_log_at_trx_commit(NULL) == 1 返回为1即为True,因此调用log_buffer_flush_to_disk(True),因此需要做redo刷盘,也要做sync。
  • innodb_flush_log_at_trx_commit参数为 2
    !binlog_group_flush|| thd_flush_log_at_trx_commit(NULL) == 1 返回为0即为Flase,因此调用

log_buffer_flush_to_disk(Flase),因此需要做redo刷盘,不做sync。依赖OS的刷盘机制。

三、调用栈帧

#0  innobase_flush_logs (hton=0x2e9edd0, binlog_group_flush=true) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/handler/ha_innodb.cc:4385
#1  0x0000000000f65893 in flush_handlerton (thd=0x0, plugin=0x7ffff01558e8, arg=0x7ffff0155944) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/handler.cc:2606
#2  0x00000000015d7716 in plugin_foreach_with_mask (thd=0x0, func=0xf65835 <flush_handlerton(THD*, plugin_ref, void*)>, type=1, state_mask=4294967287, 
    arg=0x7ffff0155944) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_plugin.cc:2318
#3  0x0000000000f658ef in ha_flush_logs (db_type=0x0, binlog_group_flush=true) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/handler.cc:2617
#4  0x000000000185733d in MYSQL_BIN_LOG::process_flush_stage_queue (this=0x2e01c80, total_bytes_var=0x7ffff0155a88, rotate_var=0x7ffff0155a87, 
    out_queue_var=0x7ffff0155a78) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:8541
#5  0x000000000185899f in MYSQL_BIN_LOG::ordered_commit (this=0x2e01c80, thd=0x7fff2c000b70, all=false, skip_commit=false)
    at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:9189
#6  0x000000000185700c in MYSQL_BIN_LOG::commit (this=0x2e01c80, thd=0x7fff2c000b70, all=false) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:8440
#7  0x0000000000f63df8 in ha_commit_trans (thd=0x7fff2c000b70, all=false, ignore_global_read_lock=false)
    at /root/mysql5.7.14/percona-server-5.7.14-7/sql/handler.cc:1818
#8  0x00000000016b3e5d in trans_commit_stmt (thd=0x7fff2c000b70) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/transaction.cc:458
#9  0x00000000015ac677 in mysql_execute_command (thd=0x7fff2c000b70, first_level=true) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_parse.cc:5239
#10 0x00000000015adcd6 in mysql_parse (thd=0x7fff2c000b70, parser_state=0x7ffff0158600) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_parse.cc:5836
#11 0x00000000015a1b95 in dispatch_command (thd=0x7fff2c000b70, com_data=0x7ffff0158d70, command=COM_QUERY)
    at /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_parse.cc:1447
#12 0x00000000015a09c6 in do_command (thd=0x7fff2c000b70) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_parse.cc:1010
#13 0x00000000016e29d0 in handle_connection (arg=0x3803f30) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/conn_handler/connection_handler_per_thread.cc:312
#14 0x0000000001d7b4b0 in pfs_spawn_thread (arg=0x3810b80) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/perfschema/pfs.cc:2188
#15 0x0000003f74807aa1 in start_thread () from /lib64/libpthread.so.0
#16 0x0000003f740e8bcd in clone () from /lib64/libc.so.6

作者微信:gaopp_22389860

相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
4天前
|
SQL 关系型数据库 MySQL
MySQL底层概述—10.InnoDB锁机制
本文介绍了:锁概述、锁分类、全局锁实战、表级锁(偏读)实战、行级锁升级表级锁实战、间隙锁实战、临键锁实战、幻读演示和解决、行级锁(偏写)优化建议、乐观锁实战、行锁原理分析、死锁与解决方案
MySQL底层概述—10.InnoDB锁机制
|
6天前
|
存储 缓存 关系型数据库
MySQL底层概述—5.InnoDB参数优化
本文介绍了MySQL数据库中与内存、日志和IO线程相关的参数优化,旨在提升数据库性能。主要内容包括: 1. 内存相关参数优化:缓冲池内存大小配置、配置多个Buffer Pool实例、Chunk大小配置、InnoDB缓存性能评估、Page管理相关参数、Change Buffer相关参数优化。 2. 日志相关参数优化:日志缓冲区配置、日志文件参数优化。 3. IO线程相关参数优化: 查询缓存参数、脏页刷盘参数、LRU链表参数、脏页刷盘相关参数。
MySQL底层概述—5.InnoDB参数优化
|
6天前
|
存储 SQL 关系型数据库
MySQL底层概述—4.InnoDB数据文件
本文介绍了InnoDB表空间文件结构及其组成部分,包括表空间、段、区、页和行。表空间是最高逻辑层,包含多个段;段由若干个区组成,每个区包含64个连续的页,页用于存储多条行记录。文章还详细解析了Page结构,分为通用部分(文件头与文件尾)、数据记录部分和页目录部分。此外,文中探讨了行记录格式,包括四种行格式(Redundant、Compact、Dynamic和Compressed),重点介绍了Compact行记录格式及其溢出机制。最后,文章解释了不同行格式的特点及应用场景,帮助理解InnoDB存储引擎的工作原理。
MySQL底层概述—4.InnoDB数据文件
|
6天前
|
存储 缓存 关系型数据库
MySQL底层概述—3.InnoDB线程模型
InnoDB存储引擎采用多线程模型,包含多个后台线程以处理不同任务。主要线程包括:IO Thread负责读写数据页和日志;Purge Thread回收已提交事务的undo日志;Page Cleaner Thread刷新脏页并清理redo日志;Master Thread调度其他线程,定时刷新脏页、回收undo日志、写入redo日志和合并写缓冲。各线程协同工作,确保数据一致性和高效性能。
MySQL底层概述—3.InnoDB线程模型
|
3月前
|
XML 安全 Java
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
本文介绍了Java日志框架的基本概念和使用方法,重点讨论了SLF4J、Log4j、Logback和Log4j2之间的关系及其性能对比。SLF4J作为一个日志抽象层,允许开发者使用统一的日志接口,而Log4j、Logback和Log4j2则是具体的日志实现框架。Log4j2在性能上优于Logback,推荐在新项目中使用。文章还详细说明了如何在Spring Boot项目中配置Log4j2和Logback,以及如何使用Lombok简化日志记录。最后,提供了一些日志配置的最佳实践,包括滚动日志、统一日志格式和提高日志性能的方法。
946 31
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
|
2月前
|
监控 安全 Apache
什么是Apache日志?为什么Apache日志分析很重要?
Apache是全球广泛使用的Web服务器软件,支持超过30%的活跃网站。它通过接收和处理HTTP请求,与后端服务器通信,返回响应并记录日志,确保网页请求的快速准确处理。Apache日志分为访问日志和错误日志,对提升用户体验、保障安全及优化性能至关重要。EventLog Analyzer等工具可有效管理和分析这些日志,增强Web服务的安全性和可靠性。
|
11天前
|
存储 SQL 关系型数据库
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log、原理、写入过程;binlog与redolog区别、update语句的执行流程、两阶段提交、主从复制、三种日志的使用场景;查询日志、慢查询日志、错误日志等其他几类日志
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
|
4月前
|
XML JSON Java
Logback 与 log4j2 性能对比:谁才是日志框架的性能王者?
【10月更文挑战第5天】在Java开发中,日志框架是不可或缺的工具,它们帮助我们记录系统运行时的信息、警告和错误,对于开发人员来说至关重要。在众多日志框架中,Logback和log4j2以其卓越的性能和丰富的功能脱颖而出,成为开发者们的首选。本文将深入探讨Logback与log4j2在性能方面的对比,通过详细的分析和实例,帮助大家理解两者之间的性能差异,以便在实际项目中做出更明智的选择。
474 3
|
1月前
|
SQL 关系型数据库 MySQL
MySQL事务日志-Undo Log工作原理分析
事务的持久性是交由Redo Log来保证,原子性则是交由Undo Log来保证。如果事务中的SQL执行到一半出现错误,需要把前面已经执行过的SQL撤销以达到原子性的目的,这个过程也叫做"回滚",所以Undo Log也叫回滚日志。
MySQL事务日志-Undo Log工作原理分析
|
2月前
|
存储 监控 安全
什么是事件日志管理系统?事件日志管理系统有哪些用处?
事件日志管理系统是IT安全的重要工具,用于集中收集、分析和解释来自组织IT基础设施各组件的事件日志,如防火墙、路由器、交换机等,帮助提升网络安全、实现主动威胁检测和促进合规性。系统支持多种日志类型,包括Windows事件日志、Syslog日志和应用程序日志,通过实时监测、告警及可视化分析,为企业提供强大的安全保障。然而,实施过程中也面临数据量大、日志管理和分析复杂等挑战。EventLog Analyzer作为一款高效工具,不仅提供实时监测与告警、可视化分析和报告功能,还支持多种合规性报告,帮助企业克服挑战,提升网络安全水平。
115 2