binlog，redo log，undo log区别

落后或无复制；
 
 
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
）。
4000

 
然后进行数据的修改。如果出现了错误或者用户执行了
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
写入持久存
  

下载文档到电脑，查找使用更方便

0下载券  14人已下载

下载

还剩1页未读，继续阅读

落后或无复制；
 
 
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
写入持久存
  

下载文档到电脑，查找使用更方便

0下载券  14人已下载

下载

还剩1页未读，继续阅读