数据库 redo undo log

undo log

数据库使用undo log保证事务的原子性。
数据库在一个事务中的增删改，为了保证可回滚，会先记录undo log,undo log在数据库当中会有独立的undo log表空间，数据库的mvcc也是基于undo log实现。数据库在增删改数据前会先加写锁，确保多个事务对同一个数据的修改是互斥的。数据格式形如<T,X,V>(事务标识，数据标识,原值)。如滚事务回滚，则从undo log中逆向回滚执行该事务进行的数据更改，当事务提交后会标识对应的undo log失效，有专门回收的线程定时回收过期的undo log。

redo log

数据库使用redo log保证事务的持久性。如果数据库在运行过程中宕机，保证已提交的事务相关数据修改的不丢失是数据库实现持久性的保障。如果想要保证已提交的事务修改不丢失，需要每次提交事务都把数据持久化到磁盘当中，并且为保障数据持久化到磁盘的过程中数据库宕机造成的数据不一致，需要先持久化undo log到磁盘当中，如果在持久化数据过程中数据库宕机，则表示该事务未成功提交，需要进行回滚。此时可以根据undo log回滚未完成提交的事务更新。这样数据库些磁盘io会非常高，会严重影响数据库的性能。为了解决性能问题，数据库引入了redo log,redo log是数据库每次更新数据后会在redo log中写入一条逻辑记录，数据格式形如<T,X,V>(事务标识，数据标识,新值)，在提交事务前先将redo log持久化到磁盘当中，数据就不需要马上更新到磁盘中，可以先缓存起来，通过另外的定时同步线程或缓存区满后触发更新已提交事务的数据到磁盘中，由于redo log是采用顺序追加的方式记录，持久化花费时间远低于数据格式化持久化到磁盘所花的时间，数据库些磁盘的性能得到了很大的提升。redo log也是先缓存在一个缓存区当中，当事务提交或缓存到达一行比例后再持久化到磁盘当中，为减少长时间事务提交是持久化redo log的数量，redo log也存在定时持久化的线程定时将redo log持久化到磁盘中，降低了事务提交所需时间。

redo log与undo log的关系

undo log与redo log同时存在，他们之间的记录关系需要严格控制，不然在数据库宕机后进行数据恢复重放就会出现问题。正常事务回滚的操作也需要记录，这样会让redo log，undo log的关系变得复杂，为了简化操作，数据库在进行事务回滚时也会记录redo log,相当于对数据的两次更新，回滚操作是undo记录逆向更新还原数据。同时redo log中也会记录undo log，这样可以简化两者间的持久化关系。数据格式形如<T,X,V_old,V_new>(事务标识，数据标识，旧值，新值)，undo log也会被当逻辑数据可以缓存起来，降低了undo log些磁盘的io，每次commit所需要做的事情变少，所花时间减少。

checkpoint检查点

数据库宕机后需要回放redo log与undo log进行数据恢复，如果数据量很大的话数据恢复时间会很长，为减少数据恢复的时间，数据库使用了checkpoint,checkpoint是另外定时线程来执行，checkpoit事件触发时会触发未持久化到磁盘的缓冲区数据都持久化到磁盘中，并记录已持久化到磁盘的数据与对应的最大事务编号并记录到数据文件一个区域当中。检查点保证之前的事务数据更新都已持久化到磁盘当中，数据库宕机进行数据恢复时不需要对检查点之前的数据进行回房重做，只需要对最后一个检查点之后的数据进行回访重做即可，减少了数据库宕机后数据恢复的时间。

数据库宕机数据恢复回放策略。

A.只重做已提交的事务。回滚未提交的事务。
B.先重做所有redo操作，再回滚未提交的事务的undo.
数据库一般选择B方案，操作简单，数据恢复线程在扫描检查点后的redo log时只需要记录未提交的redo log,顺序执行完redo log后在逆向执行未提交事务的undo log即可。