(十一)MySQL日志篇之undo-log、redo-log、bin-log…..傻傻分不清！

导言

本文为社区首发签约文章，14天内制止转载，14天后未获授权制止转载，侵权必究！

任何项目都会有日志，MySQL也不破例，而且MySQL更是其间的佼佼者，日志品种繁复，而本篇的目的便是全解MySQL中的各类日志，如吊销日志、过错日志、慢查询日志、中继日志、回滚日志…..

其实日志的效果不言而喻，不论是线上排查，亦或是功能优化，几乎都需求从日志中来取得信息作为依据，而MySQL中，许多许多的功用也都需求基于日志完结，比方业务回滚、数据耐久化、数据康复、数据迁移、MVCC机制…..，因而本篇去阐述日志，也是为了方便撰写后续的其他文章。

OK，废话不多说了，我们现在就开始吧~

一、Undo-log吊销日志

Undo即吊销的意思，但我们通常也习惯称它为回滚日志，在日常开发进程中，假如代码敲错了，一般会习惯性的按下Ctrl+Z吊销，而Undo-log的效果也是如此，但它是用来给MySQL吊销SQL操作的。

在之前的《SQL履行篇》中曾聊到过，当一条写入类型的SQL履行时，都会记载Undo-log日志，会生成相应的反SQL放入到Undo-log中，例如：

• 假如现在是insert刺进操作，则生成一个对应的delete操作。
• 假如现在是delete删去操作，InnoDB中会修改隐藏字段deleted_bit=1，则生成改为0的句子。
• 假如现在的update修改操作，比方将姓名从竹子改成了熊猫，那就生成一个从熊猫改回竹子的操作。

当业务中某条SQL履行失利时，MySQL就需求回滚业务中其他履行成功的SQL，此刻就会找到这个业务在Undo-log中生成的反SQL，然后将库中的数据改回业务发生前的样子。

我们看这段话，好像没有啥问题对不？也包括我之前的文章中也是这样去描绘的，但这儿其实存在少许误导，在之前的《SQL履行篇》中，我们说一条写SQL履行前，会生成对应的反SQL记载在Undo-log中，但实践上并不会生成反SQL，这样去叙说仅是为了方便我们了解算了。

那我们怎样证明不会生成反SQL呢？假如我们有仔细研讨过MySQL的日志，应该会发现Undo-log并不存在单独的日志文件，也便是磁盘中并不会存在xx-undo.log这类的文件，那Undo-log存在哪儿呢？InnoDB默许是将Undo-log存储在xx.ibdata同享表数据文件傍边，默许选用段的方法存储。

也便是当一个业务测验写某行表数据时，首先会将旧数据仿制到xx.ibdata文件中，将表中行数据的隐藏字段：roll_ptr回滚指针会指向xx.ibdata文件中的旧数据，然后再写表上的数据。

那Undo-log究竟在xx.ibdata文件中怎样存储呢？在同享表数据文件中，有一块区域名为Rollback Segment回滚段，每个回滚段中有1024个Undo-log Segment，每个Undo段可存储一条旧数据，而履行写SQL时，Undo-log便是写入到这些段中。

不过在MySQL5.5版别前，默许只要一个Rollback Segment，而在MySQL5.5版别后，默许有128个回滚段，即支撑128*1024条Undo记载一起存在。

1.1、关于业务回滚原理的纠正

结合上述纠正后的内容，我们再对业务的回滚原理稍作更正，实践受骗一个业务需求回滚时，本质上并不会以履行反SQL的方式还原数据，而是直接将roll_ptr回滚指针指向的Undo记载，从xx.ibdata同享表数据文件中仿制到xx.ibd表数据文件，掩盖掉原本改动过的数据。

仍是上个图简略了解一下吧，如下：

一条写SQL履行的流程如上图中的序号所示，当需求回滚业务时，直接用Undo旧记载掩盖表中修改正的新记载即可！

假如是insert操作，由于刺进之前这条数据都不存在，那么就不会发生Undo记载，此刻回滚时怎么删去这条记载呢？由于刺进操作不会发生Undo旧记载，因而隐藏字段中的roll_ptr=null，因而直接用null掩盖刺进的新记载即可，这样也就完结了删去数据的效果~

1.2、基于Undo版别链完结MVCC

仔细阅读过《MySQL-MVCC机制原理分析》的小伙伴关于这点并不生疏，Undo-log中记载的旧数据并不只是只要一条，一条相同的行数据或许存在多条不同版别的Undo记载，内部会经过roll_ptr回滚指针，组成一个单向链表，而这个链表则被称之为Undo版别链，事例如下：

-- 业务T1：trx_id=1（两次修改同一条数据）
UPDATE `zz_users` SET user_name = "竹子" WHERE user_id = 1;
UPDATE `zz_users` SET user_sex = "男" WHERE user_id = 1;

Undo-log中的旧数据版别链示意图大致如下：

当然，关于怎么利用版别链完结MVCC机制，这点就不重复赘述了，没了解过的能够去看关于MVCC原理分析的那篇文章。

1.3、Undo-log的内存缓冲区

InnoDB在MySQL发动时，会在内存中构建一个BufferPool，而这个缓冲池首要存放两类东西，一类是数据相关的缓冲，如索引、锁、表数据等，另一类则是各种日志的缓冲，如Undo、Bin、Redo....等日志。

而当一条写SQL履行时，不会直接去往磁盘中的xx.ibdata文件写数据，而是会写在undo_log_buffer缓冲区中，由于作业线程直接去写磁盘太影响效率了，写进缓冲区后会由后台线程去刷写磁盘。

OK~，那么假如当一个业务提交时，Undo的旧记载会不会立马被删去呢？由于业务都提交了，不需求再回滚改动过的数据，好像用不上Undo旧记载了，对吗？的确如此，但不会立马删去Undo记载，关于旧记载的删去作业，InnoDB中会有专门的purger线程担任，purger线程内部会维护一个ReadView，它会以此作为判别依据，来决议何时移除Undo记载。

为什么不是业务提交后立马删去Undo记载呢？由于或许会有其他业务在经过快照，读Undo版别链中的旧数据，直接移除或许会导致其他业务读不到数据，因而删去的作业就交给了purger线程。

1.4、Undo-log相关的参数

最终再来看看关于Undo-log的一些参数，其实在MySQL5.5之前没有太多参数，如下：

• innodb_max_undo_log_size：本地磁盘文件中，Undo-log的最大值，默许1GB。
• innodb_rollback_segments：指定回滚段的数量，默许为1个。

除开上述两个参数外，其他参数基本上是在MySQL5.6才有的，如下：

• innodb_undo_directory：指定Undo-log的存放目录，默许放在.ibdata文件中。
• innodb_undo_logs：指定回滚段的数量，默许为128个，也便是之前的innodb_rollback_segments。
• innodb_undo_tablespaces：指定Undo-log分成几个文件来存储，有必要敞开innodb_undo_directory参数。
• innodb_undo_log_truncate：是否敞开Undo-log的在线紧缩功用，即日志文件超越巨细一半时主动紧缩，默许OFF封闭。

没错，在MySQL5.5版别今后，Undo-log日志支撑单独存放，而且多出了几个参数能够调整Undo-log的区域。

二、Redo-log重做日志

详细聊理解了Undo-log后，紧接着再来看看它的同胞兄弟：Redo-log日志，为啥说它两是同胞兄弟呢？由于这两日志都是InnoDB引擎独有的，Undo-log首要用于完结业务回滚和MVCC机制，而Redo-log则用来完结数据的康复。还记住在《MySQL业务篇》中聊到的数据康复机制嘛？

Redo-log日志的效果就在于此，下面详细的聊一下它。

2.1、为何需求Redo-log日志？

众所周知的一点：MySQL绝大部分引擎都是是基于磁盘存储数据的，但如若每次读写数据都走磁盘，其效率必定十分低下，因而InnoDB引擎在规划时，当MySQL发动后就会在内存中创立一个BufferPool，运转进程中会将很多操作汇集在内存中进行，比方写入数据时，先写到内存中，然后由后台线程再刷写到磁盘。

虽然使用BufferPool提升了MySQL全体的读写功能，但它是基于内存的，也就意味着跟着机器的宕机、重启，其间保存的数据会消失，那当一个业务向内存中写入数据后，MySQL突然宕机了，岂不代表这条未刷写到磁盘的数据会丢掉吗？答案是Yes，也正由于该原因，Redo-log应运而生！

由于数据写到内存后有丢掉危险，这明显违背了业务ACID准则中的耐久性，所以Redo-log的呈现便是为了处理该问题，Redo-log是一种预写式日志，即在向内存写入数据前，会先写日志，当后续数据未被刷写到磁盘、MySQL溃散时，就能够经过日志来康复数据，保证一切提交的业务都会被耐久化。

可是要留意：作业线程履行SQL前，写的Redo-log日志，也是写在了内存中的redo_log_buffer缓冲区。

已然Redo-log日志也是先写内存，那Redo-log有没有丢掉的危险呢？这跟Redo-log的刷盘战略有关。

2.2、Redo-log的刷盘战略

关于内存中的redo_log_buffer缓冲区，其间写入的数据会何时被刷写到磁盘？关于这点在之前《SQL履行篇-写SQL履行时的日志操作》中简略的说到过：

简略来说便是刷盘的时机由innodb_flush_log_at_trx_commit参数来操控，默许是处于第二个等级，也便是每次提交业务时都会刷盘，这也就意味着一个业务履行成功后，相应的Redo-log日志绝对会被刷写到磁盘中，因而无需担心会呈现丢掉危险。

那假如业务还未提交时，MySQL宕机怎样办？关于这个问题在业务篇的那个截图中有，不再重复赘述！

但再来考虑一个问题：已然Redo-log要写磁盘，那为何不在写日志的时分，直接把数据写到磁盘里边去呢？

2.3、Redo-log中为何“多此一举”？

先刷写一次Redo-log日志到磁盘，后台线程再依据Redo-log日志把数据落盘，这个动作好像看起来有些剩余对吧？但实践上这样做优点很大：

• ①日志比数据先落入磁盘，因而就算MySQL溃散也能够经过日志康复数据。
• ②写日志时是以追加方法写到结尾，而写数据时则是核算数据方位，随机刺进。

关于第一点优点就不多说了，要点来聊一聊第二点，由于写日志的时分，只需求将记载追加到日志文件的尾部即可，这是按顺序写入，但写入表数据时，还需求先先核算数据的方位，比方修改一条数据时，需求先判别这条数据在磁盘文件中的那个方位，找到了方位再写入，这是随机写入，顺序写入的速度会比随机写入快许多许多。

由于写日志会比写数据落盘快，因而日志落盘后回来，比数据落盘后回来要快，关于客户端而言，呼应时刻会更短~

2.4、Redo-log相关的参数

这儿也列举出几个Redo-log日志中，较为重要的体系参数：

• innodb_flush_log_at_trx_commit：设置redo_log_buffer的刷盘战略，默许每次提交业务都刷盘。
• innodb_log_group_home_dir：指定redo-log日志文件的保存路径，默许为./。
• innodb_log_buffer_size：指定redo_log_buffer缓冲区的巨细，默许为16MB。
• innodb_log_files_in_group：指定redo日志的磁盘文件个数，默许为2个。
• innodb_log_file_size：指定redo日志的每个磁盘文件的巨细约束，默许为48MB。

其间首要讲一下Redo-log的本地磁盘文件个数，为啥默许是两个呢？由于MySQL经过来回写这两个文件的方法记载Redo-log日志，用两个日志文件组成一个“环形”，如下：

先来简略解释一下图中存在的两根指针：

• write pos：这根指针用来表明当时Redo-log文件写到了哪个方位。
• check point：这根指针表明现在哪些Redo-log记载现已失效且能够被擦除（掩盖）。

两根指针中间区域，也便是图中的赤色区域，代表是能够写入日志记载的可用空间，而蓝色区域则表明日志落盘但数据还未落盘的记载，这句话怎样了解呢？

当一个业务写了redo-log日志、并将数据写入缓冲区后，但数据还未写到本地的表数据文件中，此刻这个业务对应的redo-log记载就为上图中的蓝色，而当一个业务所写的数据也落盘后，对应的redo-log记载就会变为赤色。

当write pos指针追上check point指针时，赤色区域就会消失，也就代表Redo-log文件满了，再当MySQL履行写操作时就会被堵塞，由于无法再写入redo-log日志了，所以会触发checkpoint刷盘机制，将redo-log记载对应的业务数据，全部刷写到磁盘中的表数据文件后，堵塞的写业务才干持续履行。

触发checkpoint刷盘机制后，跟着数据的落盘，check point指针也会不断的向后移动，赤色区域也会不断增长，因而堵塞的写业务才干持续履行。

OK~，再补齐一些关于checkpoint机制的体系参数：

• innodb_log_write_ahead_size：设置checkpoint刷盘机制每次落盘动作的巨细，默许为8K，假如你要设置，有必要要为4k的整数倍，这跟read-on-write问题有关，详细的能够参考：《这篇文章》。
• innodb_log_compressed_pages：是否对Redo日志敞开页紧缩机制，默许ON，这跟InnoDB的页紧缩技术有关，后续《特性篇》聊。
• innodb_log_checksums：Redo日志完整性效验机制，默许敞开，有必要要敞开，否则有或许刷写数据时，只刷一半，呈现相似于“网络粘包”的问题。

后续几个参数略微有些复杂，由于首要跟MySQL5.6之后的优化有关，后续在《MySQL特性篇》中会再次细聊。

三、Bin-log改动日志

Bin-log日志也被称之为二进制日志，效果与Redo-log相似，首要是记载一切对数据库表结构改动和表数据修改的操作，关于select、show这类读操作并不会记载。bin-log是MySQL-Server等级的日志，也便是一切引擎都能用的日志，而redo-log、undo-log都是InnoDB引擎专享的，无法跨引擎收效。

OK~，再看到这张写SQL的履行流程图，要点调查里边的第⑨步，不论当时表使用的是什么引擎，实践上都需求完结记载bin-log日志这步操作，和之前分析的两种日志相同，bin-log也由内存日志缓冲区+本地磁盘文件两部分组成，这也就意味着：写bin-log日志时，也会先写缓冲区，然后由后台线程去刷盘。

3.1、bin-log的缓冲区

为啥要单独把bin-log的缓冲区拎出来讲呢？由于它跟redo-log、undo-log的缓冲区并不同，前面分析的两种日志缓冲区，都坐落InnoDB创立的同享BufferPool中，而bin_log_buffer是坐落每条线程中的，联系图如下：

也便是说，MySQL-Server会给每一条作业线程，都分配一个bin_log_buffer，而并不是放在同享缓冲区中，这是为啥呢？由于MySQL规划时要兼容一切引擎，直接将bin-log的缓冲区，规划在线程的作业内存中，这样就能够让一切引擎通用，而且不同线程/业务之间，由于写的都是自己作业内存中的bin-log缓冲，因而并发履行时也不会冲突！

bin_log_buffer的规划，就相似于我们之前讲《并发编程》时讲过的《ThreadLocal线程变量副本》。

OK~，简略了解bin-log缓冲区的规划后，关于bin-log的刷盘战略就不重复赘述了，便是经过sync_binlog参数操控，与之前redo-log相似（上面有）。

3.2、Bin-log本地日志文件的格局

bin-log的本地日志文件，选用的是追加写的方式，也便是一直向文件结尾写入新的日志记载，当一个日志文件写满后，会创立一个新的bin-log日志文件，每个日志文件的命名为mysql-bin.000001、mysql-bin.000002、mysql-bin.00000x....，能够经过show binary logs;指令检查已有的bin-log日志文件。

接着再来聊聊bin-log文件的内部格局~

在bin-log的本地文件中，其间存储的日志记载共有Statment、Row、Mixed三种格局，别离是啥意思呢？

Statment：每一条会对数据库发生改动的SQL句子都会记载到bin-log中。

咋了解这句话呢？举个比方：

-- 查询一次用户表数据，如下：
SELECT * FROM `zz_users`;
+---------+-----------+----------+----------+---------------------+
| user_id | user_name | user_sex | password | register_time       |
+---------+-----------+----------+----------+---------------------+
|       1 | 熊猫      | 女       | 6666     | 2022-08-14 15:22:01 |
|       2 | 竹子      | 男       | 1234     | 2022-09-14 16:17:44 |
|       3 | 子竹      | 男       | 4321     | 2022-09-16 07:42:21 |
|       4 | 猫熊      | 女       | 8888     | 2022-09-27 17:22:59 |
|       9 | 黑竹      | 男       | 9999     | 2022-09-28 22:31:44 |
+---------+-----------+----------+----------+---------------------+
-- 将用户表中一切 ID>3的暗码重置
update `zz_users` set `password` = "1111" where user_id > 3;

比方上述这个业务履行时，MySQL会将第二条update句子记载在bin-log日志中，但关于select句子则不会记载（在记载SQL时，还会记载一下SQL的上下文信息，如履行时刻、业务ID、日志量……）。

这种方法的优势很明显，由于只记载对数据库发生改动操作的SQL，所以不会发生太大的日志量，节约空间，康复数据时由于数据量小，所以磁盘IO次数少，因而功能会比较不错。一起做主备等高可用架构时，数据同步也会较小，因而比较节约带宽。

但虽然优势不小，但缺点页很明显，即康复数据、主从同步数据时，有时会呈现数据不一致的状况，如SQL中使用了sysdate()、now()这类函数，比方举个简略的比方：

insert into `zz_users` values(11,"棕熊","男","3333",sysdate());

比方这条刺进句子，由于对用户表发生了改动操作，所以会被记载到bin-log中，但当主从架构之间做数据同步时，假设将这条SQL同步到从机上履行，此刻问题就来了，sysdate()函数会获取机器的当时时刻，但主机和从机履行这条SQL明显不是同一时刻，因而就会导致ID=11的这条数据，在主机和从机的用户表中，注册时刻会呈现不一致。

Row：这种方式便是为了处理Statment方式的缺陷，Row方式中不再记载每条形成改动的SQL句子，而是记载详细哪一个分区中的、哪一个页中的、哪一行数据被修改了。

这又怎样了解呢？仍是以前面的重置暗码的比方来说：

-- 将用户表中一切 ID>3的暗码重置（ID=4、9的两条数据会被重置）
update `zz_users` set `password` = "1111" where user_id > 3;

在这种方式下，就不会记载这条update句子，而是记载发生改动的行数据，即ID=4、9的两条用户数据，会将其更改后的值记载到bin-log日志中。

这种方法由于不记载SQL，而是记载修改后的值，因而有个很大的优点是：当主从同步数据时，仿制的是主机上的数据，因而不会呈现主从数据不一致的状况。但缺陷相同很明显，比方表中有800W数据，现在我对ID<600W的一切数据进行了修改操作，哪也就意味着会有600W条记载写入bin-log日志，这个数据量可想而知，其磁盘IO、网络带宽开销会很高。

Mixed：这种被称为混合方式，即Statment、Row的结合版，由于Statment方式会导致数据呈现不一致，而Row方式数据量又会很大，因而Mixed方式结合了两者的优劣势，关于能够仿制的SQL选用Statment方式记载，关于无法仿制的SQL选用Row记载。

这样即保留了Statment方式的数据量小，又具有Row方式的数据精准性，鱼和熊掌兼得焉~

其实看到这儿，假如比较了解Redis4.x版别的小伙伴应该会有种了解感，Redis的RDB、AOF耐久化方式，正好对应MySQL的Statment、Row方式，而Redis4.0引入了混合耐久化机制，MySQL5.1版别也引入了混合日志方式~

3.2、为什么有了Redo-log还需求Bin-log？

Redo-log、Bin-log都是记载更新数据库的操作，但为什么会一起规划两个呢？这其实跟InnoDB有关，如若对MySQL旧史较为了解的小伙伴应该知道，MySQL自己的官方引擎实践上开始是MyISAM，InnoDB是Innobase-Oy公司开发的一款可拔插式引擎，由于InnoDB被MySQL支撑后使用频率越来越高，后边MySQL官刚才用InnoDB替换了MyISAM作为默许引擎。

那这跟上面的问题有啥联系呢？其实联系很大，MySQL-Server、MyISAM是出自于官方的产品，因而MyISAM中并未规划记载改动操作的日志，记载改动操作由MySQL-Server来经过Bin-log完结。

但由于MyISAM不支撑业务，所以MySQL-Server规划的Bin-log无法用于灾祸康复，因而InnoDB在规划时，又重新规划出Redo-log日志，能够利用该日志完结crash-safe灾祸康复能力，保证任何业务提交后数据都不会丢掉。

3.3、Redo-log、Bin-log两者的差异

关于Redo-log、Bin-log两者的差异，首要能够从四个维度上来说：

• ①收效规划不同，Redo-log是InnoDB专享的，Bin-log是一切引擎通用的。
• ②写入方法不同，Redo-log是用两个文件循环写，而Bin-log是不断创立新文件追加写。
• ③文件格局不同，Redo-log中记载的都是改动后的数据，而Bin-log会记载改动SQL句子。
• ④使用场景不同，Redo-log首要完结毛病状况下的数据康复，Bin-log则用于数据灾备、同步。

3.4、不小心删库后应该跑路吗？

首先来说一下，为啥要评论这个问题呢，这是由于之前《MySQL架构篇》的评论区的一位小伙伴提出的：

这儿有两个问题：①删库后跑路会不会被人发现？②MySQL能不能和Oracle相同具有闪回功用？

先来简略聊聊第一个问题，假如你在线上真的删库了，哪就先别想着跑路，你跑不掉！由于bin-log日志中会记载履行SQL的衔接会话信息，一起一般规划较大的企业，都会建立完善的监控体系，会监控服务的网络衔接，因而当你删库后，能够顺着bin-log → session → network-connection这条线确认履行删库SQL的IP！假如你还未断开衔接，直接经过MySQL的指令就能定位到删库的IP，因而基本上删库了，是能够定位到责任人的！

当然，假如项目装备的监控体系不够完善，一起你的衔接现已断开，而且电脑换了一个局域网，一起时刻来到了三天今后，假如还没人发现你，哪基本上跑路也不会有人发现，但这样干，会存在少许做贼心虚的嫌疑~

OK~，不过多的评论这个话题了，总归你跑路必定不能跑，误删了数据就要想办法康复，咋康复呢？经过日志康复，但Redo-log、Bin-log都会记载数据库的改动操作，因而用谁比较适宜呢？

答案是Bin-log，由于Redo-log选用循环写的方法，一边写会一边擦，里边无法得到完整的数据，而Bin-log是追加写的方式，你不去主动删去磁盘的日志文件，而且磁盘的空间还满足，一般Bin-log日志文件都会在本地，因而当你删库后，能够直接去本地找Bin-log的日志文件，然后仿制出来一份，再翻开最终一个文件，把里边删库的记载手动移除，再利用mysqlbinlog东西导出xx.SQL文件，最终履行该SQL文件即可康复删库前的数据。

这儿就叙说大体逻辑，详细的数据康复操作，会在后续的《MySQL线上排查与数据康复篇》细讲，其实也能够经过Flashback东西供给的闪回功用康复数据，但今后再细聊~

3.5、bin-log相关的参数

• log_bin：是否敞开bin-log日志，默许ON敞开，表明会记载改动DB的操作。
• log_bin_basename：设置bin-log日志的存储目录和文件名前缀，默许为./bin.0000x。
• log_bin_index：设置bin-log索引文件的存储方位，由于本地有多个日志文件，需求用索引来确认现在该操作的日志文件。
• binlog_format：指定bin-log日志记载的存储方法，可选Statment、Row、Mixed。
• max_binlog_size：设置bin-log本地单个文件的最大约束，最多只能调整到1GB。
• binlog_cache_size：设置为每条线程的作业内存，分配多大的bin-log缓冲区。
• sync_binlog：操控bin-log日志的刷盘频率。
• binlog_do_db：设置后，只会搜集指定库的bin-log日志，默许一切库都会记载。
• ......：省掉其他不常用参数。

3.6、Redo-log的两阶段提交

详细我们应该听说过MySQL业务两阶段提交计划，啥叫做业务两阶段提交呢？实则是指Redo-log分两次写入，如下：

留意看之前给出的写SQL履行流程图，其间第⑤、⑩步，别离会写两次Redo-log日志，这个日志的效果前面讲的很理解了，首要用来做溃散康复，但为什么要分两次写呢？写一次不可嘛？

其实想要弄理解这个问题，要结合bin-log日志一起来聊。

假如只写一次的话，那到底先写bin-log仍是redo-log呢？

先写bin-log，再写redo-log：当业务提交后，先写bin-log成功，结果在写redo-log时断电宕机了，再重启后由于redo-log中没有该业务的日志记载，因而不会康复该业务提交的数据。但要留意，主从架构中同步数据是使用bin-log来完结的，而宕机前bin-log写入成功了，就代表这个业务提交的数据会被同步到从机，也就意味着从机会比主机多出一条数据。

先写redo-log，再写bin-log：当业务提交后，先写redo-log成功，但在写bin-log时宕机了，主节点重启后，会依据redo-log康复数据，但从机依旧是依靠bin-log来同步数据的，因而从机无法将这个业务提交的数据同步曩昔，毕竟bin-log中没有撒，最终从机会比主机少一条数据。

经过上述分析后可得知：假如redo-log只写一次，那不论谁先写，都有或许形成主从同步数据时的不一致问题呈现，为了处理该问题，redo-log就被规划成了两阶段提交方式，设置成两阶段提交后，整个履行进程有三处溃散点：

• redo-log(prepare)：在写入预备状态的redo记载时宕机，业务还未提交，不会影响一致性。
• bin-log：在写bin记载时溃散，重启后会依据redo记载中的业务ID，回滚前面已写入的数据。
• redo-log(commit)：在bin-log写入成功后，写redo(commit)记载时溃散，由于bin-log中现已写入成功了，所以从机也能够同步数据，因而重启时直接再次提交业务，写入一条redo(commit)记载即可。

经过这种两阶段提交的计划，就能够保证redo-log、bin-log两者的日志数据是相同的，bin-log中有的主机再康复，假如bin-log没有则直接回滚主机上写入的数据，保证整个数据库体系的数据一致性。

OK~,最终再简略补充一点：为什么bin-log又被叫做二进制日志呢？由于记载日志时，MySQL写入的是二进制数据，而并非字符数据，也就意味着直接用cat/vim这类东西是无法翻开的，有必要要经过MySQL供给的mysqlbinlog东西解析检查。

四、Error-log过错日志

前面现已将最重要的undo-log、redo-log、bin-log三大日志讲理解了，这三个日志都是用来辅佐MySQL、InnoDB在线上正常运转的，但凡其间一个呈现问题，都有或许导致MySQL无法正常作业。

接下来再看几个辅佐性的日志，即error-log、slow-log、relay-log。

• error-log：MySQL线上MySQL由于非外在因素（断电、硬件损坏…）导致溃散时，辅佐线上排错的日志。
• slow-log：体系呼应缓慢时，用于定位问题SQL的日志，其间记载了查询时刻较长的SQL。
• relay-log：建立MySQL高可用热备架构时，用于同步数据的辅佐日志。

接下来先看error-log，这个日志的效果很明显，从姓名都能得知它是用于记载MySQL报错信息的，其间涵盖了MySQL-Server的发动、中止运转的时刻，以及报错的确诊信息，也包括了过错、正告和提示等多个等级的日志概况。

经过过错日志，一方面能够用来监控MySQL的运转状态，便于防备毛病、发现毛病，一起也能够在呈现问题时，用来辅佐排查问题、修正毛病，由于MySQL-Server的过错日志是默许敞开的，而且无法手动封闭！

一般来说，error-log日志文件默许是在MySQL装置目录下的data文件夹中，但假如你想要改动方位，哪也能够经过log-error这个参数，来手动指定保存的方位与文件名。

假如你不清楚过错日志的方位，也能够经过SHOW VARIABLES LIKE 'log_error';指令来检查。

最终略微提一嘴，怎么依据过错日志来排错问题呢？实践上十分简略，在MySQL毛病的状况下，翻开error-log文件，然后搜索Error、Waiting等级的日志记载，然后参考确诊信息即可。

五、Slow-log慢查询日志

关于线上呼应缓慢的问题，一步步的排查进程之后还未找到问题，最终就会来到数据库，测验对SQL或索引调优，但一个项目中，存在成千上万条SQL，到底是由于哪条SQL形成的呼应缓慢，假如一条条去分析，其作业量定然十分吃力，为了排查问题时满足轻松，MySQL官方支撑敞开慢查询日志。

慢查询日志是什么呢？也便是当一条SQL履行的时刻超越规定的阈值后，那么这些耗时的SQL就会被记载在慢查询日志中，当线下呈现呼应缓慢的问题时，能够直接经过检查慢查询日志定位问题，定位到发生问题的SQL后，再用explain这类东西去生成SQL的履行计划，然后依据生成的履行计划来判别为什么耗时长，是由于没走索引，仍是索引失效等状况导致的。

不过关于慢查询SQL的监控，MySQL默许是封闭的，也便是说MySQL默许不会记载慢查询日志，由于为了后续线上问题好排查，项目上线前一定要记住敞开！

• slow_query_log：设置是否敞开慢查询日志，默许OFF封闭。
• slow_query_log_file：指定慢查询日志的存储目录及文件名。

能够经过这两个参数来敞开慢查询日志，假如不设置存储目录，默许放在MySQL的详细库的目录下。当敞开慢查询日志的监控后，能够经过设置long_query_time参数，来指定查询SQL的阈值：

set global long_query_time = 1;

其默许单位是秒，因而假如要指定更细粒度的时刻，能够经过0.01这种方法设置，0.01表明10ms。当然，该参数也可不设置，不指定阈值的状况下，默许为10s，即履行时刻超越10s的查询SQL才会记载到慢查询日志中。

关于阈值的设置，并不是随我们率性而为，这个参数一定要设置合理！由于该参数的巨细会直接影响MySQL的功能，比方设置一个0.2s，但假如很多业务SQL履行时都会超出该时长，那最终会导致MySQL十分频频的往慢查询日志中写数据。

要记住：慢查询日志在内存中是没有缓冲区的，也就意味着每次记载慢查询SQL，都有必要触发磁盘IO来完结，因而阈值设的太小，容易使得MySQL功能下降；假如设的太大，又会导致无法检测到问题SQL，因而该值一定要设置一个合理值。

问题来了，这个值设成多大合理呢？能够先敞开general log，调查后实践的业务状况后再决议。

General-log查询日志

general log即查询日志，MySQL会向其间写入一切收到的查询指令，如select、show等，一起要留意：不论SQL的语法正确仍是过错、也不论SQL履行成功仍是失利，MySQL都会将其记载下来。关于该日志能够经过下述参数敞开：

• general_log：是否敞开查询日志，默许OFF封闭。
• general_log_file：指定查询日志的存储路径和文件名（默许在库的目录下，主机名+.log）。

项目测试阶段，能够先敞开查询日志，然后压测一切业务，紧接着再分析日志中SQL的平均耗时，再依据正常的SQL履行时刻，设置一个偏大的慢查询阈值即可（这是个笨办法，假如项目规划较大，直接设置一个大约值，然后上灰度发布，走正式的运营场景效果会更佳）。

当然，压测阶段完毕后，项目正式上线前，一定要记住封闭普通查询日志！！

六、Relay-log中继日志

relay log在单库中是见不到的，该类型的日志仅存在主从架构中的从机上，主从架构中的从机，其数据基本上都是仿制主机bin-log日志同步过来的，而从主机仿制过来的bin-log数据放在哪儿呢？也便是放在relay-log日志中，中继日志的效果就跟它的姓名相同，只是只是作为主从同步数据的“中转站”。

当主机的增量数据被仿制到中继日志后，从机的线程会不断从relay-log日志中读取数据并更新本身的数据，relay-log的结构和bin-log一模相同，相同存在一个xx-relaybin.index索引文件，以及多个xx-relaybin.00001、xx-relaybin.00002....数据文件。

关于这个日志的详细参数、作业进程，放在后续的《MySQL高可用-主从读写别离篇》阐述。

七、日志篇总结

叨叨絮絮下来，就大致将MySQL中的一些常见、较为重要的日志讲理解啦，其实要点搞清楚undo-log、redo-log、bin-log即可，其他的会在后续华章中再次说到，最终略微总结一下这三个比较中心的日志：

• undo-log：首要用于完结业务ACID准则中的原子性和MVCC机制。
• redo-log：首要用于完结业务准则中的耐久性，保证业务提交后就不会丢掉。
• bin-log：首要结合redo-log完结业务准则中的一致性，保证业务提交前后，数据的一致。

关于其他几类日志，在本篇中也仅讲明了大约，毕竟后边的章节中会再呈现，而关于上述三大日志也就基本上不会说到了，因而分析的较为全面，那么我们下篇见~，下面预备讲：《MySQL内存篇》，其实也首要是讲InnoDB Buffer Pool缓冲区，至于为什么半道出家的InnoDB能替换掉官方的MyIASM引擎，最大原因也在于此。