mysql学习笔记-MySql事务日志&其他日志

1、redo日志

1.1、为什么需要REDO日志？

重做日志，提供再写入操作，恢复提交事务修改的页操作，用来保证事务的持
久性。数据库宕机，保证数据不丢失。
redo log:是存储引擎层(innodb)生成的日志，记录的是"物理级别"上的页修改操作，比如页号xxx、偏移量yyy写入了’zzz"数据。主要为了保证数据的可靠性;
undo log:是存储引擎层(innodb)生成的日志，记录的是 逻辑操作 日志，比如对某一行数据进行了INSERT语句操作，那么 undo log就记录一条与之相反的DELETE操作。主要用于 事务的回滚(undo log记录的是每个修改操作的 逆操作)和 一致性非锁定读 (undo log,回滚行记录到某种特定的版本—MVCC，即多版本并发控制)。

1.2、REDO日志的好处、特点

好处：
redo日志降低了刷盘频率
redo日志占用的空间非常小
特点
redo日志是顺序写入磁盘的
事务执行过程中，redo log不断记录

1.3、redo的组成

重做日志的缓冲 (redo log buffer) ，保存在内存中，是易失的。
重做日志文件 (redo log file) ，保存在硬盘中，是持久的。

1.4、redo整体流程

第1步:先将原始数据从磁盘中读入内存中来，修改数据的内存拷贝第
2步:生成一条重做日志并写入redologbuffer，记录的是数据被修改后的值
第3步:当事务commit时，将redo log buffer中的内容刷新到 redo log file，对 redo log fi1e采用追加写的方式
第4步:定期将内存中修改的数据刷新到磁盘中

1.5、redo log的刷盘策略

InnoDB给出 innodb_flush_log_at_trx_commit 参数，该参数控制 commit提交事务时，如何将 redo log buffer 中的日志刷新到 redo log file 中。它支持三种策略
设置为0:表示每次事务提交时不进行刷盘操作。(系统默认master thread每隔1s进行一次重做日志的同步)
设置为1:表示每次事务提交时都将进行同步，刷盘操作(默认值)
设置为2:表示每次事务提交时都只把redo logbufer 内容写入page cache，不进行同步。由os自己决定什么时候同步到磁盘文件。

2、Undo日志

2.1、如何理解Undo日志

事务需要保证 原子性 ，也就是事务中的操作要么全部完成，要么什么也不做。但有时候事务执行到一半会出现一些情况，比如:
情况一:事务执行过程中可能遇到各种错误，比如服务器本身的错误， 操作系统错误 ，甚至是突然 断电 导致的错误。
情况二:程序员可以在事务执行过程中手动输入ROLLBACK语句结束当前事务的执行。以上情况出现，我们需要把数据改回原先的样子，这个过程称之为 回滚，这样就可以造成一个假象:这个事务看起来什么都没做，所以符合 原子性 要求。
插入一条记录时：记录主键值对应的记录删掉就好了。
删除了一条记录：至少要把这条记录中的内容都记下来
修改了一条记录：至少要把修改这条记录前的旧值都记录下来，这样之后回滚时再把这条记录更新为旧值
此外，undolog会产生redo 10g，也就是undo log的产生会伴随着redolog的产生，这是因为undo log也需要持久性的保护。

2.2、Undo日志作用？

作用1:回滚数据
作用2:MVCC
即在innoDB存储引擎中MVCC的实现是通过undo来完成。当用户读取一行记录时，若该记录已经被其他事务占用，当前事务可以通过undo读取之前的行版本信息，以此实现非锁定读取。

2.3、Undo的存储结构？

1. 回滚段与undo页
   InnoDB对undo log的管理采用段的方式，也就是 回滚段（rollback segment） 。每个回滚段记录了
   1024 个 undo log segment ，而在每个undo log segment段中进行 undo页 的申请。
2. undo页的重用
   undo页就被设计的可以重用了，当事务提交时，并不会立刻删除undo页。因为重用，所以这个undo页可能混杂着其他事务的undo log。undolog在commit后，会被放到一个链表 中，然后判断undo页的使用空间是否 小于3/4，如果小于3/4的话，则表示当前的undo页可以被重用，那么它就不会被回收，其他事务的undolog可以记录在当前undo页的后面。由于undo log是 离散的，所以清理对应的磁盘空间时，效率不高。
3. 回滚段与事务
   ①每个事务只会使用一个回滚段，一个回滚段在同一时刻可能会服务于多个事务。
   ②当一个事务开始的时候，会制定一个回滚段，在事务进行的过程中，当数据被修改时，原始的数据会被复制到回滚段。
   ③在回滚段中，事务会不断填充盘区，直到事务结束或所有的空间被用完。如果当前的盘区不够用，事务会在段中请求扩展下一个盘区，如果所有已分配的盘区都被用完，事务会盖最初的盘区或者在回滚段允许的情况下扩展新的盘区来使用。
   ④回滚段存在于undo表空间中，在数据库中可以存在多个undo表空间，但同一时刻只能使用一个undo表空间。

2.4、回滚段中的数据分类

1、未提交的回滚数据(uncommitted undo information):该数据所关联的事务并未提交，用于实现读一致性，所以该数据不能被其他事务的数据覆盖。
2.已经提交但未过期的回滚数据(committed undo information):该数据关联的事务已经提交，但是仍受到undo retention参数的保持时间的影响。
3.事务已经提交并过期的数据(expired undo information):事务已经提交，而且数据保存时间已经超过undo retention参数指定的时间，属于已经过期的数据。当回滚段满了之后，会优先覆盖“事务已经提交并过期的数据”。
事务提交后并不能马上删除undo log及undo log所在的页。这是因为可能还有其他事务需要通过undolog来得到行记录之前的版本。故事务提交时将undolog放入一个链表中，是否可以最终删除undolog及undo log所在页由purge线程来判断。

2.5、undo log的生命周期

1.简要生成过程

1.start transaction;
2.记录 A=1 到undo log;
3.update A=3:
4.记录 A=3 到redo 1og;
5.记录 B=2 到undo log;
6.update B=4;
7.记录B=4到redo 1og:
8.将redo log刷新到磁盘
9. commit

2.6、小结

undo log是逻辑日志，对事务回滚时，只是将数据库逻辑地恢复到原来的样子。
redo log是物理日志，记录的是数据页的物理变化，undolog不是redo log的逆过程。

3、其他数据库日志分类

1、慢查询日志:记录所有执行时间超过long_query_time的所有查询，方便我们对查询进行优化。
2、通用查询日志:记录所有连援的起始时间和终止时间，以及连接发送给数据服务器的所有指令，对我们复原操作的实际场景、发现问题，基至是对数据库操作的重计都有很大的助。
3、错误日志:记录MySQL服务的启动、运行或停止MySQL服务时出现的问题，方便我们了解服务器的状态，从而对服务器进行维护。
4、二进制日志:记录所有更改数据的语句，可以用于主从服务器之间的数据同步，以及服务器遇到故障时数据的无损失恢复。
5、中继日志:用于主从服务器架构中，从服务器用来存放主服务器二进制日志内容的一个中间文件。从服务器通过谈取中继日志的内容，采同步主服务器上的操作。
6、数据定义语句日志:记录数据定义语句执行的元数据操作。

4、 binlog与redolog对比

redo log 它是 物理日志，记录内容是“在某个数据页上做了什么修改”，属于 InnoD8 存储引擎层产生的。
而 binlog是 逻辑日志，记录内容是语句的原始逻辑，类似于“给ID=2 这一行的c字段加 1”，属于MySQL Server 层。
虽然它们都属于持久化的保证，但是则重点不同。
oredo log让InnoDB存储引擎拥有了崩溃恢复能力。
obinlog保证了MySQL集群架构的数据一致性，

5、中继日志(relay log)

中继日志只在主从服务器架构的从服务器上存在。从服务器为了与主服务器保持一致，要从主服务器读取二进制日志的内容，并且把读取到的信息写入 本地的日志文件 中，这个从服务器本地的日志文件就叫 中继日志。然后，从服务器读取中继日志，并根据中继日志的内容对从服务器的数据进行更新，完成主从服务器的 数据同步。搭建好主从服务器之后，中继日志默认会保存在从服务器的数据目录下。文件名的格式是:从服务器名 -relay-bin.序号。中继日志还有一个索引文件:从服务器名 -relay-bin.index，用来定位当前正在使用的中继日志。