数据库的undo 和 redo的介绍

日志调度恢复逻辑的重要组成部分,数据库的 undo 和 redo 机制是事务管理和数据恢复的关键组成部分，它们在维护数据一致性和数据库的稳定性方面发挥着至关重要的作用。

undo的介绍

目的：undo 机制的主要目的是提供一种方式来撤销事务所做的更改。这在事务失败或者需要回滚（即撤销到事务开始前的状态）时非常有用 和 数据库异常恢复的重要手段(结合checkpoint + redo实现数据库异常断开(如断电,服务器crash)的唯一手段) ,还可以结合备份数据,出现天灾后，快速恢复数据库的重要手段(RTO).
工作原理：当事务对数据进行修改时，数据库系统会在 undo 日志中记录足够的信息，以便在需要时能够撤销这些更改。例如，如果一个事务更新了一行数据，undo 日志将包含这行数据的原始值。
应用场景：
事务回滚：在事务执行过程中发生错误或者用户主动要求回滚时，使用 undo 日志恢复数据到事务开始前的状态。
并发控制：在多版本并发控制（MVCC）中，undo 日志用于为旧的事务版本提供数据视图。

redo的介绍

目的：redo 机制的目的是确保即使在数据库系统发生故障（如崩溃或电源故障）后，已经提交的事务所做的更改也不会丢失。
工作原理：对数据进行修改的事务在提交前，数据库系统会在 redo 日志中记录足够的信息，以便在系统恢复后能够重新应用这些更改。redo 日志通常以日志序列号（LSN）顺序存储，确保恢复操作可以按正确的顺序执行。
应用场景：
系统恢复：在数据库崩溃后，使用 redo 日志重新应用自上次检查点（checkpoint）以来已提交的所有事务更改，保证数据的完整性和一致性。
持久性保证：事务的持久性（Durability，ACID属性之一）要求事务一旦提交，其更改就是永久的。redo 日志是实现这一要求的关键。

undo 和 redo的关系

undo 和 redo 日志一起工作，为数据库提供了强大的事务恢复和持久性保障。在事务执行过程中，undo 日志支持数据的回滚能力，而 redo 日志确保提交的事务更改在系统崩溃后不会丢失。这两种机制确保了即使在发生故障的情况下，数据库也能保持ACID属性，从而维护数据的完整性和一致性

undo的作用大部分都一样但是多多版本的维护不一样

postgresql 维护多版本的方式是基于ctid,没有通过undo日志进行数据的前滚操作
mysql,informix,oracle 维护多版本的方式是基于undo,维护了一个多版本链，最新的写,在数据也上,通过隐藏列roll_pointer 指向一个旧版本的链。
opengussdb: 俩种维护多版本的方式:一种和postgresql类似的方式(Astore引擎),另一种和mysql类似的方式(Ustore引擎).

undo 还可以支持闪回功能的实现

gbase8s(informix)基于undo的方式做了闪回功能.

undo 和 redo 都是用于数据库恢复的重要保证,俩者互相成就。