假设有A、B两个数据，值分别为1,2。 进行+2的事务 *** 作。
A.事务开始.
B.记录A=1到undo log.
C.修改A=3.
D.记录B=2到undo log.
E.修改B=4.
F.将undo log写到磁盘。
G.将数据写到磁盘。
H.事务提交
对于数据的 *** 作，都是先读到内存中，然后在内存中修改，最后将数据写到磁盘。
之所以能保证原子性，是因为：
A. 更新数据前记录Undo log。
B. 为了保证持久性，必须将数据在事务提交前写到磁盘。只要事务成功提交，数据必然已经持久化。
C. Undo log必须先于数据持久化到磁盘。如果在G,H之间系统崩溃，undo log是完整的,可以用来回滚事务。
D. 如果在A-F之间系统崩溃,因为数据没有持久化到磁盘。所以磁盘上的数据还是保持在事务开始前的状态。
缺点：每个事务提交前将数据和Undo Log写入磁盘，这样会导致大量的磁盘IO，因此性能很低。
所以，为了提升性能，可以在写数据到磁盘前，先写redolog，这就是wal预写日志机制，这样先写redolog日志，数据只需先写到内存，因为redolog是顺序写，而数据落盘则是随机写，要慢得多。 这样，当系统崩溃时，虽然数据没有持久化，但有redolog撑着，数据也不会丢。（innodb_flush_log_at_trx_commit 这个参数设置为2时，那么redolog每次不需落盘，而是写到os cache中（一定时间后再flush到磁盘），这样性能又大大提升，只要 *** 作系统不宕，即便mysql宕了，数据也不会丢）
Undo + Redo事务的简化过程
A.事务开始.
B.记录A=1到undo log.
C.修改A=3.
D.记录A=3到redo log.
E.记录B=2到undo log.
F.修改B=4.
G.记录B=4到redo log.
H.将redo log写入磁盘。
I.事务提交
通过undo保证事务的原子性，redo保证持久性。
但是！！！基于以上的过程，mysql一个事务 *** 作依旧十分繁琐，这也就是其在并发场景下需借助于nosql来提升性能
redolog和undolog属于innodb，而在mysql的server层还有一个binlog，其作用是误 *** 作后需要靠它来恢复数据以及主从复制， mysql在update一行数据的时候：
1.执行器先找引擎取id=n这一行，id是主键，引擎直接用树搜索到这一行
2.执行器拿到引擎给的行数据，把这个值加1，得到新的一行数据，再调用引擎接口写入这行新数据
3.引擎将这行数据更新到内存中，同时将这个更新 *** 作记录到redolog中，此时redolog处于prepare状态，然后告知执行器执行完成，随时可以提交事务
4.执行器生成这个 *** 作的binlig，并写入磁盘
5.执行器调用引擎的提交事务接口，引擎吧刚刚写入的redolog改成提交（commit）状态，更新完成
将redolog的写入拆成两个步骤，prepare和commit，这就是两阶段提交，其目的是为了让两份日志（redolog和binlog）之间的逻辑一致
这两个日志有三点不同：
1.redolog是innodb特有，binlog是mysql server层实现的，所有引擎都可以使用，
2.redolog是物理日志，记录的是在某个数据页上做了什么修改，binlog是逻辑日志，记录的是这个语句的原始逻辑，
3.redolog是循环写的，空间固定会用完，binlog是可以追加写入的，追加写是指binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。
redolog和binlog互相是不可替代的，redolog的作用是提升数据写入时的性能，并保证事务的持久化特性，以及崩溃恢复的能力，而binlog 是无法支持崩溃恢复，因为它没有能力恢复“数据页”。 而binlog也有着redolog无法替代的功能，一个是归档。redo log 是循环写，写到末尾是要回到开头继续写的。这样历史日志没法保留，redolog 也就起不到归档的作用。还有很多公司有异构系统中使用到的组件（比如es，redis等），这些系统就靠消费 MySQL 的 binlog 来更新自己的数据。关掉 binlog 的话，这些下游系统就没法输入了。总之，由于现在包括 MySQL 高可用在内的很多系统机制都依赖于 binlog，所以“鸠占鹊巢”redo log 还做不到。
undo日志用于存放数据修改被修改前的值，假设修改 tba 表中 id=2的行数据，把Name='B' 修改为Name = 'B2' ，那么undo日志就会用来存放Name='B'的记录，如果这个修改出现异常，可以使用undo日志来实现回滚 *** 作，保证事务的一致性。对数据的变更 *** 作，主要来自 INSERT UPDATE DELETE，而UNDO LOG中分为两种类型，一种是 INSERT_UNDO（INSERT *** 作），记录插入的唯一键值；一种是 UPDATE_UNDO（包含UPDATE及DELETE *** 作），记录修改的唯一键值以及old column记录。
在MySQL中，两者存在的意义以及性能：00 – Undo Log
Undo Log 是为了实现事务的原子性，在MySQL数据库InnoDB存储引擎中，还用Undo Log来实现多版本并发控制(简称：MVCC)。
- 事务的原子性(Atomicity)
事务中的所有 *** 作，要么全部完成，要么不做任何 *** 作，不能只做部分 *** 作。如果在执行的过程中发生了错误，要回滚(Rollback)到事务开始前的状态，就像这个事务从来没有执行过。
- 原理
Undo Log的原理很简单，为了满足事务的原子性，在 *** 作任何数据之前，首先将数据备份到一个地方（这个存储数据备份的地方称为Undo Log）。然后进行数据的修改。如果出现了错误或者用户执行了ROLLBACK语句，系统可以利用Undo Log中的备份将数据恢复到事务开始之前的状态。除了可以保证事务的原子性，Undo Log也可以用来辅助完成事务的持久化。
- 事务的持久性(Durability)
事务一旦完成，该事务对数据库所做的所有修改都会持久的保存到数据库中。不能因为错误/重启/宕机而丢失已经COMMIT的数据。为了保证持久性，数据库系统需要将修改后的数据完全的记录到持久的存储上。
- 用Undo Log实现原子性和持久化的事务的简化过程
假设有A、B两个数据，值分别为1,2。
A.事务开始.
B.记录A=1到undo log的内存buffer.
C.在内存中修改A=3.
D.记录B=2到undo log的内存buffer.
E.在内存中修改B=4.
F.将undo log的buffer写到磁盘。
G.将内存中修改后的数据写到磁盘。
H.事务提交
这里有一个前提条件：‘数据都是先读到内存中，然后修改内存中的数据，最后将数据写回磁盘’。以上过程之所以能同时保证原子性和持久化，是因为以下特点：
A. 更新数据前记录Undo log。
B. 为了保证持久性，必须将数据在事务提交前写到磁盘。只要事务成功提交，数据必然已经持久化。
C. Undo log必须先于数据持久化到磁盘。如果在G,H之间系统崩溃，undo log是完整的，可以用来回滚事务。
D. 如果在A-F之间系统崩溃,因为数据没有持久化到磁盘。所以磁盘上的数据还是保持在事务开始前的状态。
缺陷：每个事务提交前将数据和Undo Log写入磁盘，这样会导致大量的磁盘IO，因此性能很低。如果能够将数据缓存一段时间，就能减少IO提高性能。但是这样就会丧失事务的持久性。因此引入了另外一种机制来实现持久化，即Redo Log.
01 – Redo Log
- 原理
和Undo Log相反，Redo Log记录的是新数据的备份。在事务提交时，只要将Redo Log持久化即可，不需要将数据持久化。当系统崩溃时，虽然数据没有持久化，但是Redo Log已经持久化。系统可以根据Redo Log的内容，将所有数据恢复到最新的状态。
- Undo + Redo事务的简化过程
假设有A、B两个数据，值分别为1,2.
A.事务开始.
B.记录A=1到undo log的内存buffer.
C.内存中修改A=3.
D.记录A=3到redo log的内存buffer.
E.记录B=2到undo log的内存buffer.
F..内存中修改B=4.
G.记录B=4到redo log的内存buffer.
H.将redo log的内存buffer写入磁盘。
I.事务提交
- Undo + Redo事务的特点
A. 为了保证持久性，必须在事务提交时将Redo Log持久化。
B. 数据不需要在事务提交前写入磁盘，而是缓存在内存中。
C. Redo Log 保证事务的持久性。
D. Undo Log 保证事务的原子性。
E. 有一个隐含的特点，数据必须要晚于redo log写入持久存储。这是因为Recovery要依赖redo log. 如果redo log丢失了，系统需要保持事务的数据也没有被更新。
- IO性能
Undo + Redo的设计主要考虑的是提升IO性能。虽说通过缓存数据，减少了写数据的IO. 但是却引入了新的IO，即写Redo Log的IO。如果Redo Log的IO性能不好，就不能起到提高性能的目的。为了保证Redo Log能够有比较好的IO性能，InnoDB 的 Redo Log的设计有以下几个特点：
A. 尽量保持Redo Log存储在一段连续的空间上。以顺序追加的方式记录Redo Log,通过顺序IO来改善性能。因此在系统第一次启动时就会将日志文件的空间完全分配，从而保证Redo Log文件在存储上的空间有更好的连续性。
B. 批量写入日志。日志并不是直接写入文件，而是先写入redo log buffer.当需要将日志刷新到磁盘时 (如事务提交),才将许多日志一起写入磁盘，这样可以减少IO次数。
C. 并发的事务共享Redo Log的存储空间，它们的Redo Log按语句的执行顺序，依次交替的记录在一起，以减少Redo Log的IO次数。例如,Redo Log中的记录内容可能是这样的：
记录1: <trx1, insert …>
记录2: <trx2, update …>
记录3: <trx1, delete …>
记录4: <trx3, update …>
记录5: <trx2, insert …>
D. 因为C的原因,当一个事务将Redo Log写入磁盘时，也会将其他未提交的事务的日志写入磁盘。
E. Redo Log上只进行顺序追加的 *** 作，当一个事务需要回滚时，它的Redo Log记录也不会从Redo Log中删除掉。InnoDB的做法时将回滚 *** 作也记入Redo Log(具体做法看下一节).
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）