Log日志(WAL)及数据库启动时的恢复算法

PG的WAL（Write Ahead Log）日志，意为 预写式日志，特点是先记后做。

例如：假设发生一个update事务，数据库的操作步骤：

（1）将update事务转化为特定格式，形成日志条目，记录至内存中的wal buffer；

（2）从磁盘的数据文件中读取需要update的数据至内存中的buffer cache，然后进行update，得到脏块；

（3）commit这个事务（或满足其他触发条件），wal writer进程将wal buffer中日志条目记录至磁盘的wal文件中；

（4）background writer（后台写进程）将脏块写入磁盘数据文件中。

详细来说WAL（Write-Ahead Logging）是一种数据库技术，全称是“先写日志后写数据”。它的主要目的是为了保证数据库事务的原子性、一致性、隔离性和持久性（ACID特性）。在进行数据更新操作时，WAL系统会记录这些更改在日志文件中，而不是立即写入磁盘的数据文件，这样做的好处有：

 

1. 数据恢复：如果系统遇到故障，如崩溃，可以通过日志文件回滚事务，确保数据的一致性，因为日志记录了完整的操作历史。

 

2. 防止数据丢失：即使在写入数据文件的过程中发生错误或磁盘故障，也可以利用日志恢复到上一个已提交的状态，减少了数据丢失的风险。

 

3. 快速故障恢复：由于日志被顺序写入，因此恢复过程通常比直接从损坏的数据文件恢复要快。

 

4. 分区和并行写入：WAL支持分段写入，允许多个进程或服务器同时写入不同的日志条目，提高了并发性能。

 

5. 压缩和存储优化：一些WAL实现允许对日志进行压缩，减少存储空间需求。

 

WAL日志通常分为两种形式：

- **重做日志（Redo Log）**：用于记录成功的事务更新，用于恢复数据库状态。

- **检查点日志（Checkpoint Log）**：记录数据库的当前状态，以便在发生故障时快速定位。

 

而在我们的系统中，通常使用检查点日志来恢复数据库，

经典顺序，当DBMS发生某种不可预料的崩坏时，数据库会依据它的原子性，持续性保证它的恢复，而在这里便是依靠log日志来进行的。

步骤:分析数据-重做数据-撤销数据

数据库在启动时的恢复算法通常是为了确保数据的一致性和完整性，尤其是在意外宕机或系统崩溃后。以下是数据库系统中常见的恢复算法的一般过程：

 

1. **检查点（Checkpointing）**:

   - 数据库系统会周期性地生成检查点，将所有脏页（未写回磁盘的内存页）写回磁盘。

   - 生成检查点时，系统会记录当前的事务日志位置，以便在恢复过程中知道从哪里开始重放日志。

 

2. **重做日志（Redo Logs）**:

   - 在数据库崩溃后，恢复过程首先需要重放从上一个检查点之后的所有重做日志。

   - 重做日志包含所有已提交事务的操作，即使这些操作在崩溃前未完全写回磁盘也会在恢复过程中重做。

 

3. **撤销日志（Undo Logs）**:

   - 对于在崩溃时未完成的事务，需要对它们进行回滚，即撤销这些未完成的操作。

   - 撤销日志包含未提交事务的操作，确保这些操作不会影响数据库的最终状态。

 

具体步骤如下：

 

1. **分析阶段（Analysis Phase）**:

   - 读取检查点，从中识别出需要恢复的日志。

   - 确定哪些事务在系统崩溃时是活动的。

 

2. **重做阶段（Redo Phase）**:

   - 从检查点开始，重放所有日志，确保所有提交了的事务都应用到数据库中。

   - 通过重播重做日志，将数据库恢复到崩溃时的最新状态。

 

3. **撤销阶段（Undo Phase）**:

   - 标识在崩溃时未提交的事务，并通过撤销日志回滚这些事务的操作。

   - 确保未提交的事务不会对数据库的最终一致性产生影响。

 

恢复算法的具体实现可能因数据库系统的不同而有所差异，如MySQL、PostgreSQL和Oracle等数据库都有自己独特的恢复机制。但是，核心思想都是通过重做和撤销日志，结合检查点，确保数据库在崩溃后能够一致地恢复到稳定状态。