落后或无复制；
N=2,0
或
2,m(0<m<100)
—
适合数据安全性有要求，允许丢失一点事务日志，
复制架构的延迟也能接受；
N=0,0
—
磁盘
IO
写能力有限，
无复制或允许复制延迟稍微长点能接受，
例如：
日志性登记业务；
Undo Log
Undo
Log
是为了实现事务的原子性，在
MySQL
数据库
InnoDB
存储引擎中，还用
UndoLog
来实现多版本并发控制
(
简称：
MVCC)
。
-
事务的原子性
(Atomicity)
事务中的所有操作，要么全部完成，要么不做任何操作，不能只做部分操作。如
果在执行的过程中发了错误，
要回滚
(Rollback)
到事务开始前的状态，
就像这个
事务从来没有执行过。
-
原理
Undo Log
的原理很简单，为了满足事务的原子性，在操作任何数据之前，首先
将数据备份到一个地方（这个存储数据备份的地方称为
UndoLo
）。
然后进行数据的修改。如果出现了错误或者用户执行了
ROLLBACK
语句，系统可
以利用
UndoLog
中的备份将数据恢复到事务开始之前的状态。
除了可以保证事务的原子性，
Undo Log
也可以用来辅助完成事务的持久化。
-
事务的持久性
(Durability)
事务一旦完成，
该事务对数据库所做的所有修改都会持久的保存到数据库中。
为
了保证持久性，数据库系统会将修改后的数据完全的记录到持久的存储上。
-
用
Undo Log
实现原子性和持久化的事务的简化过程
假设有
A
、
B
两个数据，值分别为
1,2
。
A.
事务开始
.
B.
记录
A=1
到
undolog.
C.
修改
A=3.
D.
记录
B=2
到
undolog.
E.
修改
B=4.
F.
将
undolog
写到磁盘。
G.
将数据写到磁盘。
H.
事务提交
这里有一个隐含的前提条件：
‘数据都是先读到内存中，
然后修改内存中的数据，
最后将数据写回磁盘’。
之所以能同时保证原子性和持久化，是因为以下特点：
A.
更新数据前记录
Undo log
。
B.
为了保证持久性，
必须将数据在事务提交前写到磁盘。
只要事务成功提交，
数
据必然已经持久化。
C.Undo log
必须先于数据持久化到磁盘。如果在
G,H
之间系统崩溃，
undo log
是完整的，
可以用来回滚事务。
D.
如果在
A-F
之间系统崩溃
,
因为数据没有持久化到磁盘。所以磁盘上的数据还
是保持在事务开始前的状态。
缺陷：
每个事务提交前将数据和
Undo
Log
写入磁盘，
这样会导致大量的磁盘
IO
，
因此性能很低。
如果能够将数据缓存一段时间，就能减少
IO
提高性能。但是这样就会丧失事务
的持久性。因此引入了另外一种机制来实现持久化，即
Redo log
记录的是新数据的备份。在事务提交前，只要将
Redo Log
持久化即可，不需要
将数据持久化。当系统崩溃时，虽然数据没有持久化，
但是
RedoLog
已经持久化。
系统可以根据
RedoLog
的内容，
将所有数据恢复到最
新的状态。
-Undo+Redo
事务的简化过程
假设有
A
、
B
两个数据，值分别为
1,2.
A.
事务开始
.
B.
记录
A=1
到
undolog.
C.
修改
A=3.
D.
记录
A=3
到
redolog.
E.
记录
B=2
到
undolog.
F.
修改
B=4.
G.
记录
B=4
到
redolog.
H.
将
redolog
写入磁盘。
I.
事务提交
-Undo+Redo
事务的特点
A.
为了保证持久性，必须在事务提交前将
RedoLog
持久化。
B.
数据不需要在事务提交前写入磁盘，而是缓存在内存中。
C.RedoLog
保证事务的持久性。
D.UndoLog
保证事务的原子性。
E.
有一个隐含的特点，数据必须要晚于
redolog
写入持久存
落后或无复制；
N=2,0
或
2,m(0<m<100)
—
适合数据安全性有要求，允许丢失一点事务日志，
复制架构的延迟也能接受；
N=0,0
—
磁盘
IO
写能力有限，
无复制或允许复制延迟稍微长点能接受，
例如：
日志性登记业务；
Undo Log
Undo
Log
是为了实现事务的原子性，在
MySQL
数据库
InnoDB
存储引擎中，还用
UndoLog
来实现多版本并发控制
(
简称：
MVCC)
。
-
事务的原子性
(Atomicity)
事务中的所有操作，要么全部完成，要么不做任何操作，不能只做部分操作。如
果在执行的过程中发了错误，
要回滚
(Rollback)
到事务开始前的状态，
就像这个
事务从来没有执行过。
-
原理
Undo Log
的原理很简单，为了满足事务的原子性，在操作任何数据之前，首先
将数据备份到一个地方（这个存储数据备份的地方称为
UndoLo
）。
然后进行数据的修改。如果出现了错误或者用户执行了
ROLLBACK
语句，系统可
以利用
UndoLog
中的备份将数据恢复到事务开始之前的状态。
除了可以保证事务的原子性，
Undo Log
也可以用来辅助完成事务的持久化。
-
事务的持久性
(Durability)
事务一旦完成，
该事务对数据库所做的所有修改都会持久的保存到数据库中。
为
了保证持久性，数据库系统会将修改后的数据完全的记录到持久的存储上。
-
用
Undo Log
实现原子性和持久化的事务的简化过程
假设有
A
、
B
两个数据，值分别为
1,2
。
A.
事务开始
.
B.
记录
A=1
到
undolog.
C.
修改
A=3.
D.
记录
B=2
到
undolog.
E.
修改
B=4.
F.
将
undolog
写到磁盘。
G.
将数据写到磁盘。
H.
事务提交
这里有一个隐含的前提条件：
‘数据都是先读到内存中，
然后修改内存中的数据，
最后将数据写回磁盘’。
之所以能同时保证原子性和持久化，是因为以下特点：
A.
更新数据前记录
Undo log
。
B.
为了保证持久性，
必须将数据在事务提交前写到磁盘。
只要事务成功提交，
数
据必然已经持久化。
C.Undo log
必须先于数据持久化到磁盘。如果在
G,H
之间系统崩溃，
undo log
是完整的，
可以用来回滚事务。
D.
如果在
A-F
之间系统崩溃
,
因为数据没有持久化到磁盘。所以磁盘上的数据还
是保持在事务开始前的状态。
缺陷：
每个事务提交前将数据和
Undo
Log
写入磁盘，
这样会导致大量的磁盘
IO
，
因此性能很低。
如果能够将数据缓存一段时间，就能减少
IO
提高性能。但是这样就会丧失事务
的持久性。因此引入了另外一种机制来实现持久化，即
Redo log
记录的是新数据的备份。在事务提交前，只要将
Redo Log
持久化即可，不需要
将数据持久化。当系统崩溃时，虽然数据没有持久化，
但是
RedoLog
已经持久化。
系统可以根据
RedoLog
的内容，
将所有数据恢复到最
新的状态。
-Undo+Redo
事务的简化过程
假设有
A
、
B
两个数据，值分别为
1,2.
A.
事务开始
.
B.
记录
A=1
到
undolog.
C.
修改
A=3.
D.
记录
A=3
到
redolog.
E.
记录
B=2
到
undolog.
F.
修改
B=4.
G.
记录
B=4
到
redolog.
H.
将
redolog
写入磁盘。
I.
事务提交
-Undo+Redo
事务的特点
A.
为了保证持久性，必须在事务提交前将
RedoLog
持久化。
B.
数据不需要在事务提交前写入磁盘，而是缓存在内存中。
C.RedoLog
保证事务的持久性。
D.UndoLog
保证事务的原子性。
E.
有一个隐含的特点，数据必须要晚于
redolog
写入持久存
扫一扫
989
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
