备案控制台
探索云世界
开发者社区 数据库 文章 正文

MySQL中binlog cache使用流程解惑

2018-07-03 4115
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
云数据库 RDS MySQL Serverless，0.5-2RCU 50GB
推荐场景：
学生管理系统数据库设计 搭建个人博客
简介： 水平有限整理自己的学习笔记，如果有误请谅解。 最近老是看到有朋友报错如下：ERROR 1197 (HY000): Multi-statement transaction required more than 'max_binlog_cache_size' bytes of storage; increase this mysqld variable and try again虽然错误提示非常明确，但是我还是对binlog cache的使用方式进行了学习整理下来，这部分也是我一直疑惑的地方，也希望通过本文接触读者的疑惑。

水平有限整理自己的学习笔记，如果有误请谅解。

最近老是看到有朋友报错如下：
ERROR 1197 (HY000): Multi-statement transaction required more than 'max_binlog_cache_size' bytes of storage; increase this mysqld variable and try again
虽然错误提示非常明确，但是我还是对binlog cache的使用方式进行了学习整理下来，这部分也是我一直疑惑的地方，也希望通过本文接触读者的疑惑。

本文约定：

  • binlog cache：实际上就是参数binlog_cache_size指定的大小，它指定的是一段内存空间用于存储生成的binlog event，是事物级别的参数。
  • binlog cache 临时文件：实际上就是参数max_binlog_cache_size指定的大小，它指定是一个临时磁盘文件存储由于binlog cache不足溢出的binlog event，其名字由"ML"打头，是事物级别的参数。
  • binlog file：代表就是我们平时说的binglog 文件，由max_binlog_size指定大小。
  • binlog event：代表是各种各样的binlog中的记录比如MAP_EVENT/QUERY EVENT/XID EVENT/WRITE EVENT等。

本文源码版本：

  • percona 5.7.14

一、通常事物binlog event的写入流程

这里首先给出写入过程，让大家有一个大概的理解。

注意这个流程都是对于一个事物来讲的。一旦事物提交，binlog cache和binlog 临时文件都会释放掉，因为binlog已经固化到了binlog file。同时如果事物中包含多个DML语句，那么他们共享的一套的binlog cache和binlog 临时文件。

  1. 事物开启。
  2. 执行dml语句，在dml语句第一次执行的时候会分配内存空间binlog cache。
  3. 执行dml语句期间生成的event不断写入到binlog cache。
  4. 如果binlog cache的空间已经满了，则将binlog cache的数据写入到binlog临时文件，同时清空binlog cache。如果binlog临时文件的大小大于了max_binlog_cache_size的设置则抛错ERROR 1197 (HY000)。
  5. 事物提交，整个binlog cache和binlog临时文件数据全部写入到binlog file中进行固化，释放binlog cache和binlog临时文件。但是注意此时binlog cache的内存空间留用供下次事物使用，但是binlog临时文件被截断为0，保留文件描述符。其实也就是IO_CACHE(参考后文)保留，并且保留IO_CACHE中的分配的内存空间，和物理文件描述符。
  6. 断开连接，这个过程会释放IO_CACHE同时释放其持有的binlog cache内存空间以及持有的binlog 临时文件。

本文研究就是步骤3和步骤4的写入过程，和binlog cache以及binlog 临时文件的实现方式。同时本文不描述binlog_stmt_cache_size和max_binlog_stmt_cache_size的作用，因为他们和binlog_cache_size、max_binlog_cache_size参数的函数一致，只是存储是非事物语句的binlog event，但是在讨论数据结构的时候还是给出部分解释。

二、相关数据结构简介

  • binlog_cache_mngr类：
    这个类中包含了两个cache实际上就是binlog cache和binlog stmt cache，如下:

    1. binlog_stmt_cache_data stmt_cache;
    2. binlog_trx_cache_data trx_cache;
      其中包含一些方法用于访问这两个cache。同时将整个binlog event写入到binlog file的方法也在其中叫做flush，栈帧如下：
#0  binlog_cache_mngr::flush (this=0x7fff58ca17c0, thd=0x7fff58012930, bytes_written=0x7ffff0358918, wrote_xid=0x7ffff0358917)
    at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:739
#1  0x0000000001857152 in MYSQL_BIN_LOG::flush_thread_caches (this=0x2e02c80, thd=0x7fff58012930) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:8484
#2  0x0000000001857383 in MYSQL_BIN_LOG::process_flush_stage_queue (this=0x2e02c80, total_bytes_var=0x7ffff0358a88, rotate_var=0x7ffff0358a87, 
    out_queue_var=0x7ffff0358a78) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:8546
#3  0x000000000185899f in MYSQL_BIN_LOG::ordered_commit (this=0x2e02c80, thd=0x7fff58012930, all=false, skip_commit=false)
    at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:9189
#4  0x000000000185700c in MYSQL_BIN_LOG::commit (this=0x2e02c80, thd=0x7fff58012930, all=false) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:8440

可以说他是一个访问binlog cache和binlog stmt cache的统一的对外接口。

  • binlog_trx_cache_data类和binlog_stmt_cache_data类：

他们都继承来自统一的父类binlog_cache_data。因为binlog_trx_cache_data要实现更多的功能，因为要支持事物，支持事物的回滚等功能，所以必须增加额外的功能呢但是。binlog_stmt_cache_data则不需要。

  • binlog_cache_data类：

实现了主要成员包含：

  1. IO_CACHE cache_log：Cache to store data before copying it to the binary log.实际上所谓的binlog cache(binlog stmt cache)/max binlog cache(max stmt binlog cache)都是他实现的。
  2. Rows_log_event *m_pending：Pending binrows event. This event is the event where the rows are currently written.
  3. my_off_t saved_max_binlog_cache_size：参数max_binlog_cache_size/max_binlog_stmt_cache_size的大小。
  4. ulong *ptr_binlog_cache_use：状态binlog_cache_use/binlog_stmt_cache_use的值的指针。
  5. ulong *ptr_binlog_cache_disk_use：状态binlog_cache_disk_use/binlog_stmt_cache_disk_use的值的指针。
  • IO_CACHE类：

实际上binlog event的写入binlog 或者 binlog临时文件都是由 IO_CACHE子系统实现的，本子系统实现了类似写缓存如果缓存不够写入物理文件的功能，从而降低了物理写入的次数，提升了性能。它封装了包含读缓存，写缓存以及物理文件等信息。如下：

  1. 读缓存 uchar *buffer;
  2. 写缓存 uchar *write_buffer;
  3. 物理文件描述符 File file;

其使用方式也分多种模式如：

  1. READ_CACHE模式
  2. WRITE_CACHE模式
  3. SEQ_READ_APPEND模式

当然IO_CACHE还用到其他地方，比如我们熟悉的filesort，进行内存和磁盘排序也是通过这个子系统作为存储方式完成的。栈帧参考结束附录，对于这个子系统更加详细的参考信息可以自行百度我发现有朋友写得很清楚，本文主要说明是binlog cache的使用方式而不是这个子系统。但是在涉及到源码部分的时候以binlog cache和binlog临时文件的写入为列子。

最后我们画一张这几个类的关系图，同时给出binlog cache(binlog stmt cache)和binlog临时文件(binlog stmt临时文件)的表示，如下：

QQ图片20180703183344.png

这张图解释了他们的关系。

三、binlog_cache_size作用及其初始化

本节使用的binlog_cache_size大小为32678及默认值。

binlog_cache_size参数在官方文档的描述大概为如果开启了binlog功能，则在事物期间用于保存binlog event的缓存。如果经常使用大事物应该加大这个缓存，避免过多的磁盘使用，从Binlog_cache_use和Binlog_cache_disk_use可以看出是否使用了binlog cache或binlog 临时文件用于保存binlog event。
当然如我开头所说这部分是完全内存的。
实际上当我们的事物需要记录事物的binlog event的时候我们就会使用到binlog cache，其初始化栈帧如下：

#0  init_io_cache_ext (info=0x7fff58ca17c8, file=-1, cachesize=32768, type=WRITE_CACHE, seek_offset=0, use_async_io=0 '\000', cache_myflags=20, file_key=10)
    at /root/mysql5.7.14/percona-server-5.7.14-7/mysys/mf_iocache.c:154
#1  0x00000000018c8b48 in init_io_cache (info=0x7fff58ca17c8, file=-1, cachesize=32768, type=WRITE_CACHE, seek_offset=0, use_async_io=0 '\000', cache_myflags=20)
    at /root/mysql5.7.14/percona-server-5.7.14-7/mysys/mf_iocache.c:299
#2  0x00000000018c6b96 in open_cached_file (cache=0x7fff58ca17c8, dir=0x2fa1d70 "/root/mysql5.7.14/percona-server-5.7.14-7/mysql-test/var/tmp/mysqld.1", 
    prefix=0x2277d4e "ML", cache_size=32768, cache_myflags=16) at /root/mysql5.7.14/percona-server-5.7.14-7/mysys/mf_cache.c:60
#3  0x00000000018599b2 in THD::binlog_setup_trx_data (this=0x7fff58012930) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:9641
#4  0x0000000001859cb3 in binlog_start_trans_and_stmt (thd=0x7fff58012930, start_event=0x7ffff0359350) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:9742
#5  0x000000000185a0a6 in THD::binlog_write_table_map (this=0x7fff58012930, table=0x7fff58d98260, is_transactional=false, binlog_rows_query=false)
    at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:9835
#6  0x0000000000f7299f in write_locked_table_maps (thd=0x7fff58012930) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/handler.cc:8019
#7  0x0000000000f72bf6 in binlog_log_row (table=0x7fff58d98260, before_record=0x7fff58d99120 "\375\001", after_record=0x0, 
    log_func=0xf77f7d <Delete_rows_log_event::binlog_row_logging_function(THD*, TABLE*, bool, uchar const*, uchar const*)>)
    at /root/mysql5.7.14/percona-server-5.7.14-7/sql/handler.cc:8089

我们可以在THD::binlog_setup_trx_data找到binlog_cache_size的作如下：

open_cached_file(&cache_mngr->trx_cache.cache_log, mysql_tmpdir,
                       LOG_PREFIX, binlog_cache_size, MYF(MY_WME)))

大概解释一下部分参数的含义。

  • &cache_mngr->trx_cache.cache_log 就是一个IO_CACHE实例。
  • mysql_tmpdir 为参数tmpdir的定义目录。
  • LOG_PREFIX 为如果使用临时文件临时文件的前缀，如果是binlog的临时磁盘文件则为"ML"，如果是filesort的临时排序文件则为"MY"。
  • cache_size 当然就是你参数binlog_cache_size设置的大小。

最终参数binlog_cache_size的值会通过init_io_cache函数传入到init_io_cache_ext中。我们关注一下以下几个传入到init_io_cache_ext的参数。

  • file=-1：初始换缓存的情况下，不会非配实际的临时文件。索引用-1表示文件描述符
  • cachesize=32768：binlog_cache_size设置的大小。
  • type=WRITE_CACHE：IO_CACHE的使用模式。

下面是init_io_cache_ext函数关于binlog cache分配的重点代码部分：

      info->file= file;(-1)
      info->pos_in_file= seek_offset;(0)
      info->pre_close = info->pre_read = info->post_read = 0;
          info->arg = 0;
          info->alloced_buffer = 0;
          info->buffer=0;
          info->seek_not_done= 0;
            
      buffer_block= cachesize; //他们和binlog_cache_size参数指定相等(有对其操作)
      if ((info->buffer= (uchar*) my_malloc(key_memory_IO_CACHE,
                                            buffer_block, flags)) != 0)//为binlog cache分配实际的内存其大小就是binlog_cache_size指定的大小(有对其操作)
      {
        info->write_buffer=info->buffer;//write_buffer和buffer指向了同一片内存区域，及我们的binlog cache缓存区域
        info->alloced_buffer=1;
      }
      info->read_length=info->buffer_length=cachesize; //此处将缓存的长度记录为binlog_cache_size指定的大小(有对其操作)
      info->request_pos= info->read_pos= info->write_pos = info->buffer;//初始化各种位置为info->buffer指针指向的位置
      
      if (type == WRITE_CACHE)
      info->write_end= info->buffer+info->buffer_length- (seek_offset & (IO_SIZE-1));//将缓存的边界设置为(info->buffer指针指向位置+binlog_cache_size参数指定的大小)

此后IO_CACHE对象已经分配了一块binlog_cache_size参数指定相等大小的内存，则使我们说的binlog cache已经初始化分配完成。

四、binlog临时文件的使用和分配方式

及当我们事物需要存储的binlog event已经不能在binlog cache中存下的时候，我们需要开启我们binlong临时文件来存储。其文件存放到tmpdir的定义的目录下，文件名为”ML”开头。但是这个文件不能用ls看到，因为使用了LINUX临时文件建立的方法，以避免其他进程使用这个文件而破坏这个文件的内容。也就是说，这个文件是mysqld进程内部专用的，在LINUX中MySQL使用mkstemp系统调用完成这个功能。对于这个文件可以使用lsof|grep delete看到最后我会给出一个例子。

分配栈帧如下：

#0  create_temp_file (to=0x7ffff0359040 "/root/mysql5.7.14/percona-server-5.7.14-7/mysql-test/var/tmp/mysqld.1/MLIdFGCH", 
    dir=0x7fff580167c0 "/root/mysql5.7.14/percona-server-5.7.14-7/mysql-test/var/tmp/mysqld.1", prefix=0x7fff58016830 "ML", mode=514, MyFlags=16)
    at /root/mysql5.7.14/percona-server-5.7.14-7/mysys/mf_tempfile.c:141
#1  0x00000000018c693d in inline_mysql_file_create_temp (key=10, src_file=0x2296d78 "/root/mysql5.7.14/percona-server-5.7.14-7/mysys/mf_cache.c", src_line=80, 
    to=0x7ffff0359040 "/root/mysql5.7.14/percona-server-5.7.14-7/mysql-test/var/tmp/mysqld.1/MLIdFGCH", 
    dir=0x7fff580167c0 "/root/mysql5.7.14/percona-server-5.7.14-7/mysql-test/var/tmp/mysqld.1", pfx=0x7fff58016830 "ML", mode=514, myFlags=16)
    at /root/mysql5.7.14/percona-server-5.7.14-7/include/mysql/psi/mysql_file.h:1048
#2  0x00000000018c6c87 in real_open_cached_file (cache=0x7fff58ca17c8) at /root/mysql5.7.14/percona-server-5.7.14-7/mysys/mf_cache.c:77
#3  0x00000000018cb4a9 in my_b_flush_io_cache (info=0x7fff58ca17c8, need_append_buffer_lock=0) at /root/mysql5.7.14/percona-server-5.7.14-7/mysys/mf_iocache.c:1528
#4  0x00000000018cad03 in _my_b_write (info=0x7fff58ca17c8, Buffer=0x7fff58de751a "", Count=186) at /root/mysql5.7.14/percona-server-5.7.14-7/mysys/mf_iocache.c:1330
#5  0x00000000018cb156 in my_b_safe_write (info=0x7fff58ca17c8, Buffer=0x7fff58de55e0 "\376\001", Count=8180)
    at /root/mysql5.7.14/percona-server-5.7.14-7/mysys/mf_iocache.c:1437
#6  0x000000000180e7b2 in Log_event::wrapper_my_b_safe_write (this=0x7fff58972bb0, file=0x7fff58ca17c8, buf=0x7fff58de55e0 "\376\001", size=8180)
    at /root/mysql5.7.14/percona-server-5.7.14-7/sql/log_event.cc:977
#7  0x000000000182b392 in Rows_log_event::write_data_body (this=0x7fff58972bb0, file=0x7fff58ca17c8)
    at /root/mysql5.7.14/percona-server-5.7.14-7/sql/log_event.cc:11356
#8  0x0000000001835e63 in Log_event::write (this=0x7fff58972bb0, file=0x7fff58ca17c8) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/log_event.h:825
#9  0x0000000001845899 in binlog_cache_data::write_event (this=0x7fff58ca17c0, thd=0x7fff58012930, ev=0x7fff58972bb0)
    at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:1120
#10 0x0000000001853625 in MYSQL_BIN_LOG::flush_and_set_pending_rows_event (this=0x2e02c80, thd=0x7fff58012930, event=0x7fff58954fd0, is_transactional=false)
    at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:7075

当我们不断的写入binlog event的情况下，我们最终会将binlog cache写满(对于小事物肯定不会写满)。我们来梳理一下binlog 临时文件是怎么打开的，我们从my_b_safe_write函数开始：
注意这里实际对于IO_CACHE来讲是通用的方法我只是以binlog 临时文件建立的流程为例子，因为不同的模式走的逻辑不一样

  • my_b_safe_write

这个函数在每次binlog event写入到binlog cache的时候都会调用。
在WRITE_CACHE的模式下会调用宏my_b_write，这是一个关键点宏的定义如下：

#define my_b_write(info,Buffer,Count) \
 ((info)->write_pos + (Count) <=(info)->write_end ?\
  (memcpy((info)->write_pos, (Buffer), (size_t)(Count)),\
   ((info)->write_pos+=(Count)),0) : \
   (*(info)->write_function)((info),(uchar *)(Buffer),(Count)))

很简单如果binlog cache缓存当前写入的位置加上本次写入的总量大于了binlog cache的内存地址的边界则我们需要进行通过*(info)->write_function这个回调函数将binlog cache的内容写到磁盘了，这样才能腾出空间给新的binlog event存放。这里这个回调函数应该就是_my_b_write。

  • _my_b_write

这个函数只会在binlog cache不够用的时候需要进行临时物理文件写入的时候调用。
大概逻辑如下：

rest_length= (size_t) (info->write_end - info->write_pos); //统计出此时binlog cache剩余的空间
  memcpy(info->write_pos,Buffer,(size_t) rest_length); //写满这些剩余的空间
  Buffer+=rest_length;//既然已经写了一部分那么待写入的数据应该减去写入的部分
  Count-=rest_length;//写入的总量也应该的减去已经写入的部分
  info->write_pos+=rest_length;//binlog cache的写入位置应该增加

  if (my_b_flush_io_cache(info,1))//创建临时文件(如果没有创建的话)并且写入数据到临时文件
  
  memcpy(info->write_pos,Buffer,(size_t) Count);//刷新完成后。binlog cache已经腾空可以继续使用了
  info->write_pos+=Count;//简单的增加binlog cache指针的位置
  • my_b_flush_io_cache

这个函数主要负责了当binlog cache 写满后将binlog cache的数据全部写入到binlog 临时文件和清空binlog cache，当然最后会增加Binlog_cache_disk_use。
大概逻辑如下：

if (info->file == -1)//如果是第一次建立临时文件，这里的文件描述为-1，前面已经分析过了
    {
      if (real_open_cached_file(info))//打开临时文件返回文件描述符 !!!!!
      
length=(size_t) (info->write_pos - info->write_buffer)//统计本次写入临时文件数据的大小      
pos_in_file=info->pos_in_file;      
info->pos_in_file+=length;//将当前文件写入位置加上本次写入数据的大小及为下次文件写入的位置
if (mysql_file_write(info->file,info->write_buffer,length,info->myflags | MY_NABP))//将数据写入到临时文件中。
info->append_read_pos=info->write_pos=info->write_buffer; //此处将info->write_pos指针指向到binlog cache缓冲开始的位置及binlog cache缓冲全部释放
++info->disk_writes;//Binlog_cache_disk_use增加
  • create_temp_file
    这个函数没什么说的就是调用mkstemp来完成临时文件的建立，我们关注一下输入两个参数即可
  1. to 临时文件的绝对路径
  2. dir 及临时文件所在的目录
  3. prefix 临时文件的前缀,这里是ML

注意对于filesort的临时文件也是通过这个函数建立，前缀为MY。

到这里我们的binlog cache内存空间已经分配，并且由于事物写入的binlog event大于了binlog cache设置的大小，binlog 临时文件已经分配并且进行了一次binlog cache数据写入到binlog 临时文件的操作。这就是整个流程。

五、max_binlog_cache_size设置过小的报错

报错如下：

(root@localhost)[06:19:12] [test ;]> insert into t1 select * from t1;
ERROR 1197 (HY000): Multi-statement transaction required more than 'max_binlog_cache_size' bytes of storage; increase this mysqld variable and try again

当然报错也很清晰告诉你原因，但是在整个流程中到底是哪里抛错出来的呢？实际上就是函数_my_b_write中进行的判断。先来看看这个错误的错误码如下：

{ "ER_TRANS_CACHE_FULL", 1197, "Multi-statement transaction required more than \'max_binlog_cache_size\' bytes of storage; increase this mysqld variable and try again" },

在函数_my_b_write中可以看到如下代码：

if (pos_in_file+info->buffer_length > info->end_of_file) //判断binlog临时文件的位置加上本次需要写盘的数据大于info->end_of_file的大小则抛错
  {
    errno=EFBIG;
    set_my_errno(EFBIG);
    return info->error = -1;
  }

而抛错的代码在MYSQL_BIN_LOG::check_write_error函数中如下：

    if (is_transactional)
    {
      my_message(ER_TRANS_CACHE_FULL, ER(ER_TRANS_CACHE_FULL), MYF(MY_WME));
    }

其中info->end_of_file的大小正是来自于我们的参数max_binlog_cache_size，不再给出代码。

六、如何观察到binlog 临时文件的存在

前文已经说过可以使用lsof|grep delete来观察到这种文件，据我观察这个文件会以64k的倍数上涨如下：

[root@test ~]# lsof|grep delete|grep ML
mysqld    21414      root   77u      REG              252,3     65536    1856092 /root/mysql5.7.14/percona-server-5.7.14-7/mysql-test/var/tmp/mysqld.1/MLUFzokf (deleted)
[root@test ~]# lsof|grep delete|grep ML
mysqld    21414      root   77u      REG              252,3    131072    1856092 /root/mysql5.7.14/percona-server-5.7.14-7/mysql-test/var/tmp/mysqld.1/MLUFzokf (deleted)
[root@test ~]# lsof|grep delete|grep ML
mysqld    21414      root   77u      REG              252,3    163840    1856092 /root/mysql5.7.14/percona-server-5.7.14-7/mysql-test/var/tmp/mysqld.1/MLUFzokf (deleted)
[root@test ~]# lsof|grep delete|grep ML
mysqld    21414      root   77u      REG              252,3    229376    1856092 /root/mysql5.7.14/percona-server-5.7.14-7/mysql-test/var/tmp/mysqld.1/MLUFzokf (deleted)

七、总结

写了这么多，这里需要总结一下参数的具体含义，以及注意点。

  • binlog_cache_size：事物级别的参数，用于指定存储整个事物生成的binlog event的内存大小，对于大事物来讲很可能超过这个参数的设置，则需要开启binlog 临时文件用于存储。
  • max_binlog_cache_size：事物级别的参数，用于指定当某个事物的binlog event超过了binlog_cache_size大小的设置开启binlog 临时文件的可用大小，如果事物的binlog event生成量超过了max_binlog_cache_size+binlog_cache_size设置的大小则会抛错：
ERROR 1197 (HY000): Multi-statement transaction required more than 'max_binlog_cache_size' bytes of storage; increase this mysqld variable and try again
  • 不管是binlog cache还是binlog 临时文件都是在事物没有提交之前用于存储binlog event的场所，一旦事物提交完成后，所有的binlog event都已经固化到binlog file，则它们可以释放和重用。
  • binlog_stmt_cache_size/ max_binlog_stmt_cache_size：这一套参数和上面的两个参数含义差不多，但是针对的是非事物型的binlog event，显然对于innodb当道的今天大部分的event还是事物级别的，所以我没有过多研究，但是根据debug来看DDL语句返回的是非事物级别的，如下判断
断点 MYSQL_BIN_LOG::write_event函数，代码片段如下：
    bool is_trans_cache= event_info->is_using_trans_cache();//DDL这里返回的false
    binlog_cache_mngr *cache_mngr= thd_get_cache_mngr(thd);//得到cache_mngr指针地址，有了它不管是stmt缓存还是trx缓存都能找到如前文所述
    binlog_cache_data *cache_data= cache_mngr->get_binlog_cache_data(is_trans_cache);//这里如果是非事物级别使用stmt缓存区

八、备注信息

最后留下一些有用的接口信息：

  • 事物提交临时文件被截断为0
    这个接口实际上就是binlog_cache_mngr::flush->binlog_cache_data::flush->binlog_cache_data::reset->my_chsize
  • 事物提交binlog cache内存空间留用
    这个接口可能是binlog_cache_mngr::flush->bMYSQL_BIN_LOG::write_cache->MYSQL_BIN_LOG::do_write_cache->reinit_io_cache
  • 断开连接整个IO CACHE全部释放掉
    这个接口就是close_cached_file如下：
File file=cache->file;
    cache->file= -1;    /* Don't flush data */
    (void) end_io_cache(cache);//释放整个IO_CACHE
    if (file >= 0)
    {
      (void) mysql_file_close(file, MYF(0));//关闭临时文件
    }

作者微信：
微信.jpg

文章标签：
云数据库 RDS MySQL 版
SQL
关系型数据库
存储
缓存
MySQL
关键词：
云数据库 RDS MySQL 版binlog
mysql binlog
binlog mysql
云数据库 RDS MySQL 版流程
云数据库 RDS MySQL 版binlog流程
相关实践学习
基于CentOS快速搭建LAMP环境
本教程介绍如何搭建LAMP环境，其中LAMP分别代表Linux、Apache、MySQL和PHP。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心，利用清洁计算为万物互联的新世界提供源源不断的能源动力，目前开服的区域包括中国（华北、华东、华南、香港）、新加坡、美国（美东、美西）、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程，来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品：云服务器ECS 云服务器 ECS（Elastic Compute Service）是一种弹性可伸缩的计算服务，助您降低 IT 成本，提升运维效率，使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
重庆八怪
目录
相关文章
liuyunshengsir
|
12天前
|
存储 安全 关系型数据库
Mysql 的binlog日志的优缺点
MySQL的binlog（二进制日志）是一个记录数据库更改的日志文件，它包含了所有对数据库执行的更改操作，如INSERT、UPDATE和DELETE等。binlog的主要目的是复制和恢复。以下是binlog日志的优缺点： ### 优点： 1. **数据恢复**：当数据库出现意外故障或数据丢失时，可以利用binlog进行点恢复（point-in-time recovery），将数据恢复到某一特定时间点。 2. **主从复制**：binlog是实现MySQL主从复制功能的核心组件。主服务器将binlog中的事件发送到从服务器，从服务器再重放这些事件，从而实现数据的同步。 3. **审计**：b
liuyunshengsir
23 1
风水道人
|
21天前
|
SQL 关系型数据库 MySQL
mysql的binlog恢复数据
mysql的binlog恢复数据
风水道人
20 0
海风极客
|
2月前
|
存储 SQL 安全
浅谈MySQL Binlog
浅谈MySQL Binlog
海风极客
45 0
爱吃糖的范同学
|
18天前
|
SQL 关系型数据库 MySQL
【MySQL】慢SQL分析流程
【4月更文挑战第1天】【MySQL】慢SQL分析流程
爱吃糖的范同学
29 1
一只牛博
|
2月前
|
监控 关系型数据库 MySQL
MySQL Binlog实战：在生产环境中的应用与最佳实践【实战应用】
MySQL Binlog实战：在生产环境中的应用与最佳实践【实战应用】
一只牛博
35 0
一只牛博
|
2月前
|
SQL 监控 关系型数据库
MySQL Binlog深度解析：进阶应用与实战技巧【进阶应用】
MySQL Binlog深度解析：进阶应用与实战技巧【进阶应用】
一只牛博
42 0
诸葛子房
|
4月前
|
缓存 关系型数据库 MySQL
MySQL Binlog--事务日志和BINLOG落盘参数对磁盘IO的影响
MySQL Binlog--事务日志和BINLOG落盘参数对磁盘IO的影响
诸葛子房
44 0
一只牛博
|
2月前
|
SQL 存储 关系型数据库
解析MySQL Binlog：从零开始的入门指南【binlog入门指南】
解析MySQL Binlog：从零开始的入门指南【binlog入门指南】
一只牛博
934 0
基层搬砖的Panda
|
3月前
|
关系型数据库 MySQL 数据库
Mysql数据库redo log及binlog的写入
Mysql数据库redo log及binlog的写入
基层搬砖的Panda
39 0
warmhearted
|
5月前
|
关系型数据库 MySQL Shell
如何用shell脚本获取mysql的binlog日志
如何用shell脚本获取mysql的binlog日志
warmhearted
63 1

热门文章

最新文章

  • 1
    Mysql 的binlog日志的优缺点
  • 2
    mysql的binlog恢复数据
  • 3
    超1/3中国500强企业都在用的「汇联易」，为什么选用阿里云RDS？
  • 4
    详解MySQL字符集和Collation
  • 5
    RDS MySQL 数据库运维简述
  • 6
    阿里云mysql数据库价格购买和使用教程
  • 7
    阿里云MySQL云数据库优惠价格、购买和使用教程分享！
  • 8
    阿里云MySQL数据库价格、购买、创建账号密码和连接数据库教程
  • 9
    使用阿里云的数据传输服务DTS（Data Transmission Service）进行MySQL 5.6到MySQL 8.0的迁移
  • 10
    Docker安装详细步骤及相关环境安装配置（mysql、jdk、redis、自己的私有仓库Gitlab 、C和C++环境以及Nginx服务代理）
  • 1
    连接和管理RDS
    24
  • 2
    购买和初始化阿里云RDS
    26
  • 3
    rds教程
    27
  • 4
    TiDB与MySQL、PostgreSQL等数据库的比较分析
    81
  • 5
    OBCP实践 - 迁移 MySQL 数据到 OceanBase 集群
    33
  • 6
    Flink CDC产品常见问题之mysql整库同步到starrock时任务挂掉如何解决
    34
  • 7
    TIDB和MySQL的区别
    158
  • 8
    Flink CDC产品常见问题之mysql整库同步到starrock时任务挂掉如何解决
    59
  • 9
    [MySQL]事务原理之redo log,undo log
    41
  • 10
    [MySQL]SQL优化之sql语句优化
    51

    • 相关课程

    更多
  • MySQL企业常见架构与调优经验分享
  • 云数据库MySQL版快速上手教程
  • 阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
  • MySQL实战进阶
  • 数据库及SQL/MySQL基础
  • 云数据库MySQL快速入门

    • 相关电子书

    更多
  • 搭建电商项目架构连接MySQL
  • 搭建4层电商项目架构，实战连接MySQL
  • PolarDB MySQL引擎重磅功能及产品能力盛大发布

    • 相关实验场景

    更多
  • 测试场景（RDS无优惠）
  • MySQL引擎及架构优化
  • 基于EBS部署高性能的MySQL服务
  • 使用Python完成RDS数据开发及分析
  • Excel文件转存到RDS数据库
  • 使用CloudLens采集RDS日志并进行审计分析

    • 推荐镜像

    更多
  • mysql
  • mariadb
  • postgresql
    • 下一篇
    阿里云oss简介和使用流程