持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第9天，点击查看活动详情
WAL 提升性能的核心机制，也就是尽量减少随机读写。
基于预写日志（WAL）传输
通常，每个写操作都是追加写方式写入日志：
- 日志结构存储引擎，日志是主要存储方式。日志段在后台压缩并支持 GC
- 对采用覆写磁盘的B树结构，每次修改会先预写日志（Write Ahead Log，WAL），若系统崩溃，通过索引更新的方式可迅速恢复到此前的一致状态
不管哪种情况，所有对数据库写入的字节序列都被记入日志。因此，可使用完全相同的日志在另一个节点上构建副本：除了将日志写盘，主节点还能通过网络将其发给从节点。
从节点收到日志进行处理，建立和主节点内容完全相同的数据副本。
PostgreSQL和Oracle等使用这种复制方案。
主要缺点
日志记录的数据非常底层：一个WAL包含哪些磁盘块中的哪些字节发生更改。这使得复制方案和存储引擎紧耦合。若DB存储格式改为新版本，则系统通常无法支持主节点和从节点运行不同版本的数据库软件。
看上去这可能只是个微小实现细节，但对运维产生巨大影响：
- 若复制协议允许从节点使用比主节点更新的软件版本，则可实现先升级从节点，然后执行主节点切换，使升级后的节点成为新主，从而实现数据库软件的不停机升级
- 若复制协议不允许版本不匹配（传输WAL经常出现这种情况），则此类升级需要停机
