MySQL 日志模块

原文《MySQL实战45讲》

redo log (重做日志)

​ redo log 是 InnoDB 引擎特有的日志,主要是为了实现 crash-safe能力。保证即使数据库发生异常重启,之前提交的记录都不会丢失,这个能力称为crash-safe。

​ 当有一条记录需要更新的时候,InnoDB 引擎就会先把记录写到 redo log 里面,并更新内存,这个时候更新就算完成了。同时,InnoDB 引擎会在适当的时候,将这个操作记录更新到磁盘里面,而这个更新往往是在系统比较空闲的时候做。InnoDB 的 redo log 是固定大小的,从头开始写,写到末尾就又回到开头循环写。

img

​ write pos 是当前记录的位置,一边写一边后移,写到文件末尾就重头开始写。checkpoint 是当前要擦除的位置,也是往后推移并且循循环的,擦除记录前要把记录更新到数据文件。write pos 和 checkpoint 之间的空间可以存入新的更新,如果 write pos 追上了 checkpoint ,这个时候不能再执行新的更新了,需要把 checkpoint 推进一下。

binlog (归档日志)

​ redo log 是 InnoDB 引擎特有的日志,而Server层也有自己的日志,为binlog(归档日志)。binlog日志只能用于归档,没有crash-safe的能力。binlog 是 MySQL 的 Server 层实现的,所有引擎都可以使用。

redo log 和 binlog 的区别

  • redo log 是物理日志,记录的是“在某个数据页上做了什么修改”;binlog 是逻辑日志,记录的是这个语句的原始逻辑,比如“给某一行的 某字段数值+1”。

  • redo log 是循环写的,空间固定的,会用完;binlog 是追加写入的(binlog 文件写道一定大小后会切换到下一个,不会覆盖以前的日志)。

  • 一个更新语句的的执行流程图,图中浅色框表示是在 InnoDB 内部执行的,深色框表示是在执行器中执行的。

    • 更新语句

      update T set c=c+1 where ID=2;
      
    • 执行流程图

      img

MySQL 相关设置项

  • innodb_flush_log_at_trx_commit 这个参数设置成1的时候,表示每次事务的 redo log 都直接 flush(刷到磁盘)。这个参数设置成1,可以保证 MySQL 异常重启之后数据不会丢失。

    • 如果innodb_flush_log_at_trx_commit设置为0,将事务的变更每秒一次地写入 redo log 中,并且 redo log 的flush(刷到磁盘)操作同时进行。该模式下,在事务提交的时候,不会主动触发写入磁盘的操作。
    • 如果innodb_flush_log_at_trx_commit设置为2,每次事务提交时MySQL都会把事务的数据写入 redo log。但是flush(刷到磁盘)操作并不会同时进行。该模式下,MySQL会每秒执行一次 flush(刷到磁盘)操作。
    • 注意:由于进程调度策略问题,这个“每秒执行一次 flush(刷到磁盘)操作,并不是保证100%的“每秒”。
  • sync_binlog 这个参数设置成1的时候,表示每次失误的 binlog 都持久化到磁盘。这个参数设置成1,可以保证MySQL 异常重启之后 binlog 不丢失。

    • sync_binlog 默认为0,表示 MySQL 不控制 binlog 的刷新,由文件系统自己控制它的缓存刷新。这时候的性能是最好的,但是风险也是最大的。因为一旦发生系统 crash,在 binlog_cache 中的所有 binlog 信息都会丢失。
    • 如果 sync_binlog > 0, 设为 n,表示每 n 次事务提交, MySQL 调用文件系统的刷新操作将 binlog 日志持久化。当 sync_binlog = 1 的时候是最安全的,表示每次事务提交, MySQL 都会把 binlog 持久化,但是这时候的性能损耗也是最大的。这样的话,在数据库所在的主机操作系统损坏或者突然掉电的情况下,系统才有可能丢失一个事务数据。有些时候,可以将 sync_binlog 设置为 0 或者 100,牺牲一定的一致性,以获得更高的并发和性能。
    • 注意:如果启用了 autocommit,那么每一个语句statement就会有一次写操作;否则每个事务对应一个写操作。

binlog 使用

  1. 开启 binlog 日志(Docker安装的MySQL)

    # 进入mysql容器
    docker exec -it [mysql容器id] /bin/bash
    # 进入配置文件目录下
    cd /etc/mysql/mysql.conf.d/
    # 开启binlog
    echo 'log-bin=/var/lib/mysql/mysql-bin' >> mysqld.cnf
    echo 'server-id=123454' >> mysqld.cnf
    # 修改binlog格式
    echo 'binlog-format=ROW' >> mysqld.cnf
    
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 217,084评论 6 503
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,623评论 3 392
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 163,450评论 0 353
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,322评论 1 293
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,370评论 6 390
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,274评论 1 300
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,126评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,980评论 0 275
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,414评论 1 313
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,599评论 3 334
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,773评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,470评论 5 344
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,080评论 3 327
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,713评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,852评论 1 269
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,865评论 2 370
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,689评论 2 354

推荐阅读更多精彩内容