进阶数据库系列（十五）：PostgreSQL 主从同步原理与实践

前面介绍了 PostgreSQL 常用函数、锁操作、执行计划、视图与触发器、存储过程、索引、分区分表、事务与并发控制相关的知识点，今天我将详细的为大家介绍 PostgreSQL 主从同步复制原理与实践相关知识，希望大家能够从中收获多多！如有帮助，请点在看、转发支持一波！！！

在正式介绍 PostgreSQL 主从同步复制 之前，我们先了解一下 PostgreSQL 的预写日志机制（WAL）。

PostgreSQL 预写日志机制（WAL）

关于持久性

持久性是指，事务提交后，对系统的影响必须是永久的，即使系统意外宕机，也必须确保事务提交时的修改已真正永久写入到永久存储中。

最简单的实现方法，当然是在事务提交后立即刷新事务修改后的数据到磁盘。但是磁盘和内存之间的IO操作是最影响数据库系统影响时间的，一有事务提交就去刷新磁盘，会对数据库性能产生不好影响。

WAL机制的引入，即保证了事务持久性和数据完整性，又尽量地避免了频繁IO对性能的影响。

WAL过程分析

Write-Ahead Logging，前写日志。

在MVCC的部分中，我们已经分析了PostgreSQL的存储结构：元组-文件页-物理段-表；
以及写数据的步骤：先写到缓冲区Buffer-再刷新到磁盘Disk。

WAL机制实际是在这个写数据的过程中加入了对应的写wal log的过程，步骤一样是先到Buffer，再刷新到Disk。

• Change发生时：

• 先将变更后内容记入WAL Buffer

• 再将更新后的数据写入Data Buffer

• Commit发生时：

• WAL Buffer刷新到Disk

• Data Buffer写磁盘推迟

• Checkpoint发生时：

• 将所有Data Buffer刷新到磁盘

数据发生变动时

commit 和 checkpoint

更多关于 PostgreSQL 系列的学习文章，请参阅：PostgreSQL 数据库，本系列持续更新中。

WAL的好处

通过上面的分析，可以看到：

当宕机发生时，

• Data Buffer的内容还没有全部写入到永久存储中，数据丢失；

• 但是WAL Buffer的内容已写入磁盘，根据WAL日志的内容，可以恢复库丢失的内容。

在提交时，仅把WAL刷新到了磁盘，而不是Data刷新：

• 从IO次数来说，WAL刷新是少量IO，Data刷新是大量IO，WAL刷新次数少得多；

• 从IO花销来说，WAL刷新是连续IO，Data刷新是随机IO，WAL刷新花销小得多。

因此WAL机制在保证事务持久性和数据完整性的同时，成功地提升了系统性能。

主从复制