InnoDB的log写入策略及主从同步

标签: 数据库 bin-log mysql redo log 主从同步 | 发表时间:2011-02-18 11:58 | 作者:dingqi 彦强
出处:http://rdc.taobao.com/blog/cs

      ib_logfile是InnoDB的事务日志文件。ib_logfile与bin-log共同控制事务恢复。本文简要说明其写入时机、写入策略, 以及分析系统异常对主从数据一致性的影响。

1、              基本概念 

     a)        ib_logfile文件个数由innodb_log_files_in_group配置决定,若为2,则在datadir目录下有两个文件,命令从0开始,分别为ib_logfile0和ib_logfile1.

     b)        文件为顺序写入,当达到最后一个文件末尾时,会从第一个文件开始顺序复用。

     c)        lsn: Log Sequence Number,是一个递增的整数。 Ib_logfile中的每次写入操作都包含至少1个log,每个log都带有一个lsn。在内存page修复过程中,只有大于page_lsn的log才会被使用。

     d)        lsn的保存在全局变量log_sys中。递增数值等于每个log的实际内容长度。即如果新增的一个log长度是len,则log_sys->lsn += len.

     e)        ib_logfile每次写入以512(OS_FILE_LOG_BLOCK_SIZE)字节为单位。实际写入函数 log_group_write_buf (log/log0log.c)

     f)         每次写盘后是否flush,由参数innodb_flush_log_at_trx_commit控制。

2、              log_sys介绍 

                  log_sys是一个全局内存结构。以下说明几个成员的意义。

lsn 表示已经分配的最后一个lsn的值。
written_to_all_lsn n表示实际已经写盘的lsn。需要这个值是因为并非每次生成log后就写盘。
flushed_to_disk_lsn 表示刷到磁盘的lsn。需要这个值是因为并非每次写盘后就flush。
buf 待写入的内容保存在buf中
buf_size buf的大小。由配置中innodb_log_buffer_size决定,实际大小为innodb_log_buffer_size /16k * 16k。
buf_next_to_write buf中下一个要写入磁盘的位置
buf_free buf中实际内容的最后位置。当buf_free> buf_next_to_write时,说明内存中还有数据未写盘。

 

3、相关更新

    用一个简单的更新语句来说明log_sys以及ib_logfile的更新内容的过程。假设我们的更新只涉及到非索引的固定长度字段。

     a)        在log_sys->buf中写入undo log。 对于一个单一的语句,需要先创建一个undolog头。

     b)        在log_sys->buf中写入undo log的实际内容。

     c)        在log_sys->buf中写入buffer page的更新内容。此处保存了更新的完整信息。

     d)        在log_sys->buf中写入启动事务(trx_prepare)的日志

     e)        将a~d的所有log内容写入ib_logfile中。

     f)         写bin-log

     g)        在log_sys->buf中写入事务结束(trx_commit)的日志

     h)        将f步骤的log内容写入ib_logfile中。

4、              流程说明 

     1)        完成上述所有操作时,数据文件还没有更新。

     2)        每次写入log_sys->buf时同时更新lsn和buf_free。 每次写ib_logfile时同时更新written_to_all_lsn和buf_next_to_write;

     3)        每次写ib_logfile时以512字节为对齐,如需写入600字节,则实际写入1k。写到最后一个文件末尾则从第一个文件重复使用。

     4)        若涉及到索引更新,在步骤c之后会增加索引更新的log。由于索引可能有merge过程,因此在merge过程中会另外增加写入一个log。但事务完全提交仍在步骤g中。索引的更新由于已经写盘,并不会因此丢失。

5、              日志策略与数据安全 

     ib_logfile和bin-log的作用之一是保证系统异常时的数据安全,可以分析一下上述流程过程中出现数据库异常关闭时数据安全性。从上述流程看到:

     1)        在a~d过程中若出现异常关闭,由于没有写入到磁盘中,因此整个事务放弃;

     2)        若在e刚完成时出现异常关闭,虽然事务内容已经写盘,但没有提交。在重启恢复的时候,发现这个事务还没有提交,逻辑上整个事务放弃。      (重启日志中会有Found 1 prepared transaction(s) in InnoDB, rollback xid…字样)。

     3)        在f或g完成后出现异常关闭,bin-log写入成功后,则异常重启后能够根据bin-log恢复事务的修改。(重启日志中会有Found 1 prepared transaction(s) in InnoDB, commit xid…字样)。

     4)        在h完成后出现异常关闭,由于事务日志完整,因此事务能够正常恢复。

6、              日志策略与主从同步 

     主从同步关心的问题是

     1) 会不会由于主库能够根据ib_logfile恢复数据,而由于bin-log没写导致从库同步时少了这个事务?

     2) 或者反之,bin-log写成功,而ib_logfile没有写完,导致从库执行事务,而主库不执行?

     先来看控制log写入的主要流程

源码sql/handler.cc:

ha_commit_trans{  …  if ((err= ht->prepare(ht, thd, all))) —-a)

  …

  tc_log->log_xid(thd, xid)       —–b)

  …

  error=ha_commit_one_phase(thd, all)  —c)

}

     说明:可以看到, InnoDB的log分成两段更新,前提是开启bin-log。(条件是有超过1个引擎需要更新日志,而bin-log也是引擎之一,因此至少两个)。

     从上面的分析流程可以看到

     ☆    假设在阶段a)结束之后程序异常, 此时没有写入bin-log。 则从库不会同步这个事务。 主库上,在重启之后,从恢复日志中这个事务没有trx_commit,因此会被回滚。 逻辑上主从库都不会执行这个事务。

     ☆    假设在阶段b)结束后程序异常,此时bin-log已经写入,则从库会同步这个事务。 主库上,根据恢复日志和bin-log,也能够正常恢复此事务。

     也就是说,若bin-log写入完成,则主从库都会正常完成事务;bin-log没有写入,则主从库都完成事务。不会出现主从不一致的问题。

7、              redo log丢失造成的主从不一致

     上述的流程并不是天衣无缝的。ib_logfile的写盘是能够被设置成非实时flush的。假设在bin-log写入完成后,系统崩溃,则可能出现这样的情况:bin-log写入所以从库能够执行事务。但主库中trx_prepare的日志没有被写入到ib_logifle中,导致主库不执行事务。这样就会出现主从不一致的情况—主库没执行事务,而从库执行。

     参数innodb_flush_log_at_trx_commit决定了出现这种情况的可能场景。

     a)      值为0

     此时事务完成后并不马上写ib_logfile。 因此在bin-log写入完成后主库异常关闭(数据库崩溃),则可能出现上述情况。

     b)      值为2

     此时事务完成后写ib_logfile但不flush。因此在bin-log写入完成后主库系统异常(操作系统崩溃),则可能造成上述情况。

     因此比较安全的做法是设置值为1,每次事务完成都写盘并flush,代价是io负载增大。退一步设置为2,则只在操作系统崩溃时才会造成不一致。

[附]恢复代码流程(sql/handler.cc)

xarecover_handlerton{     sql_print_information(“Found %d prepared transaction(s) in %s”,    got, ha_resolve_storage_engine_name(hton));

    foreach (trx)

   {

      if (found in bin-log)

      {

        sql_print_information(“commit xid %s”, xid_to_str(buf, info->list+i));

        hton->commit_by_xid(hton, info->list+i);

      }

      else

      {

         sql_print_information(“rollback xid %s”,xid_to_str(buf, info->list+i));

         hton->rollback_by_xid(hton, info->list+i);

      }

   }

}

相关 [innodb log 策略] 推荐:

InnoDB的log写入策略及主从同步

- 彦强 - 淘宝核心系统团队博客
      ib_logfile是InnoDB的事务日志文件. ib_logfile与bin-log共同控制事务恢复. 本文简要说明其写入时机、写入策略, 以及分析系统异常对主从数据一致性的影响. 1、              基本概念 .      a)        ib_logfile文件个数由innodb_log_files_in_group配置决定,若为2,则在datadir目录下有两个文件,命令从0开始,分别为ib_logfile0和ib_logfile1..

Oracle Tuning Log File Sync 等待事件的几种策略

- - CSDN博客数据库推荐文章
    在一个频繁 commit/rollback 或磁盘 I/O 有问题、大量物理读写争用.    那么、我们便会经常瞧见 LOG FILE SYNC 等待事件出现在 TOP EVENTS 中.    评估 LOG FILE SYNC等待事件的指标是平均等待时间、以及 AWR 后续的 WAIT EVENT HISTOGRAM.

Log调试

- - ITeye博客
在开发中我们一定不能避免使用Log类,但是这个类存在一个问题就是,当你在程序中使用了大量的Log,那么在程序开发完毕的时候,这将是一个问题,因为,你需要将所有的Log记录注释掉(当然,你不注释也是可以的). 我们可以写一个类,将Log类包装起来,使用一个boolean来控制所有的Log记录的显示. public static final boolean isDebug = true;//这里控制所有Log的显示情况.

log file sync总结

- - 数据库 - ITeye博客
log file sync等待时间发生在redo log从log buffer写入到log file期间. 下面对log file sync做个详细的解释. 1.commit或者rollback. 3.log buffer 1/3满或者已经有1M的redo数据.       更精确的解释:_LOG_IO_SIZE 大小默认是LOG_BUFFER的1/3,当log buffer中redo数据达到_LOG_IO_SIZE 大小时,发生日志写入.

Mysql InnoDB锁

- - 数据库 - ITeye博客
抄自:http://www.cnblogs.com/qq78292959/archive/2013/01/30/2882745.html. Mysql常用存储引擎的锁机制. MyISAM和MEMORY采用表级锁(table-level locking). BDB采用页面锁(page-leve locking)或表级锁,默认为页面锁.

Oracle online redo log 扫盲

- - CSDN博客数据库推荐文章
Oracle 的日志分为:ONLINE REDO LOG 和 archived log. 一个数据库至少要有2组 redo log,每组 redo log 至少要有一个 member(出于安全考虑,建议每组 redo log 至少有 2 个多元化的 redo log member). redo log 循环使用,当一组日志写满后,就会切换到下一组日志.

必须了解的MySQL三大日志:binlog、redo log和undo log

- - DockOne.io
日志是 MySQL数据库的重要组成部分,记录着数据库运行期间各种状态信息. MySQL日志主要包括错误日志、查询日志、慢查询日志、事务日志、二进制日志几大类. 作为开发,我们重点需要关注的是二进制日志( binlog)和事务日志(包括 redo log和 undo log),本文接下来会详细介绍这三种日志.

Mysql-innodb-B+索引

- - 掘金后端
这是读书笔记,Mysql,innodb系列一共3篇. Mysql-innodb-B+索引(本篇). Mysql-innodb-锁(预计20200523). Mysql-innodb-事务预计20200530). CREATE TABLE `aid_***_detail` ( //省略所有字段 PRIMARY KEY (`id`), KEY `range_idx` (`range_id`,`is_delete`,`range_detail_num`,`goods_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4复制代码.

静态cache之log共现词分析

- - 搜索技术博客-淘宝
搜索引擎的log数据可以用于query理解、user理解、doc理解和ranking. 我们运行共现词分析,挖掘出引擎的query log里面共现的词,离线建静态cache,用于提升引擎的性能. 分析query log里query的平均的term数,值为5. 我们对query log依次进行一至四元共现词分析,高于四元的我们推荐用fullcache解决,而且高元的离线计算成本也太高.

[转]用mysqldumpslow分析mysql的slow query log

- - 小彰
mysql有一个功能就是可以log下来运行的比较慢的sql语句,默认是没有这个log的,为了开启这个功能,要修改my.cnf或者在mysql启动的时候加入一些参数. 如果在my.cnf里面修改,需增加如下几行. long_query_time 是指执行超过多久的sql会被log下来,这里是1秒. log-slow-queries 设置把日志写在那里,可以为空,系统会给一个缺省的文件 host_name-slow.log,我生成的log就在mysql的data目录.