CNDBA社区
PG的高可用方案比较多，我们这里只看原生的主从复制的相关概念。
主从复制涉及如下几个概念：
- 主库：提供读写功能数据库，称为Primary database或master database；
- 从库（warm standby server）： 在接收主数据库同步数据和应用同步数据时，不能提供只读服务，则该备份数据库称之为warm standby server；
- 从库（hot standby server）：在接收同步数据和应用同步数据时也能提供只读操作，则称该备份数据库为hot standby server。hot standby 功能是PostgreSQL9.X版本之后提供的新功能。
1 PITR 原理
PostgreSQL在数据目录的pg_wal子目录中始终维护着一个WAL日志文件。wal日志文件用于记录数据库数据文件的每次改变。主要目的是为了在数据库异常崩溃后，能够通过重放最后一次checkpoint点后的日志文件，把数据库推到一致状态。
虽然直接拷贝数据库数据文件会导致拷贝出来的文件不一致，但因为有了WAL日志，即使备份出来的数据块不一致，也可以重放备份开始后的WAL日志，把备份的内容推到一致状态。
由此可见，有了WAL日志之后，备份数据库时不再需要完美的一致性备份了，备份中任何数据的非一致性都会被重放WAL日志文件进行纠正，所以在备份数据库时可以通过简单的cp命令或tar等拷贝、备份文件来实现数据库的在线备份。
不停地重放 WAL 日志就可以把数据推到备份结束后的任意一个时间点，这就是基于时间点的备份，称为”Point-in-Time Recovery”，缩写为PITR。
使用简单的cp命令或其他命令把数据库给在线拷贝出来的备份，被称为基础备份。后续WAL日志的备份与此基础备份构成一个完整备份。把基础备份恢复到另一台机器，然后不停地从原始数据库机器上接收WAL日志，在新机器上持续重放WAL日志，这样就可以在任何时间内在另一台机器上打开这个新产生的数据库，它拥有当前数据库的最新数据状态。这个新机器上的数据库被称为Standby数据库。
当前的主数据库出现问题或主数据库的机器出现故障无法正常提供服务时，可以把Standby数据库打开提供服务，从而实现高可用。把WAL日志传送到另一台机器上的方法有两种，一种是通过WAL归档日志实现，一种是被称为流复制的方法。
2 WAL 日志归档
WAL日志归档，其实就是把在线的WAL日志备份出来。在PostgreSQL中配置归档的方法是配置参数archive command，参数的配置值可以是一个Unix命令，此命令把WAL 日志文档拷贝到其他地方，例如下面的配置：
archive mode = on
archive_command = 'cp %p /backup/pgarch/%f'
上面的命令中”archive mode = on”表示打开归档备份，参数archive command 的配置值是一Unix的cp命令，命令中的”%p”表示在线WAL日志文件的全路径名，”%f”表示不包括路径的WAL日志文件名。在实际执行时备份时，PostgreSQL会把”%p”替换成实际的在线WAL日志文件的全路径名，并把”%f”替换成不包括路径的WAL日志名。
使用操作系统命令scp就可以把WAL日志拷贝到其他机器上，从而实现对跨机器的归档日志进行备份，如下：
archive mode = on
archive_command='scp %p postgres@192.168.56.101:/backup/pgarch/%f'
使用上面拷贝WAL文件的方式来同步主、备数据库之间数据时，备库会落后主库一个WAL日志文件，具体落后多长时间取决于主库上生成一个完整的WAL文件所需要的时间。
3 流复制
流复制（Streaming Replication）是PostgreSQL从9.0开始提供的一种新的传递WAL日志的方法。
使用流复制时，只要Primary数据库一产生日志，就会马上传递到Standby数据库。
流复制传递日志的方式有两种，一种是异步方式，一种是同步方式。
- 同步方式，在Primary数据库提交事务时，一定会等到WAL日志传递到Standby后才会返回，这样可以做到Standby数据库完全与Primary数据库同步，没有一点落后，当主备库切换时使用同步方式可以做到零数据丢失。
- 异步方式，则是事务提交后不必等日志传递到Standby 就即可返回，所以Standby数据库通常也只比Primary数据库落后很少（如几秒）的时间。
4 Standby的运行原理
PostgreSQL数据库异常中止后，数据库刚重启时，会重放停机前最后一个checkpoint点之后的WAL日志，在把数据库恢复到停机的状态后，自动进入正常的状态，可以接收其他用户的查询和修改。
在PostgreSQL 9.0之前的版本中，没有流复制的功能，基本只能一个个传送WAL日志文件（除非使用第三方的软件），所以备库最少比主库落后一个WAL日志文件，当故障出现后，使用Standby数据库接管数据库服务时，丢失的数据会比较多。
PostgreSQL 9.0后，提供了流复制功能，实现了主库产生一点日志后，就会马上传送到备库上去，从而一般只丢失最多几秒的数据。
PostgreSQL 9.1中，流复制的功能得到了进一步的提升，实现了同步复制的功能，这样主备切换后，就不存在数据丢失的问题。但如果是一主一从的架构，在使用同步复制时，如果备库出现问题，会导致主库也会被hang住。对于这个问题，可以采用多个Standby数据库的方案，比如在两个Standby的情况下，其中一个Standby数据库坏掉时，主数据库不会被hang住，两个备数据库都出现问题时，才会导致主数据库不能写。
PostgreSQL9.2之后，增加了级连复制的功能，也就是一个Standby数据库后面可以再级连另一个Standby数据库，也就是说其他Standby 数据库不必都从主数据库上传递WAL日志，而是可以从Standby数据库传递WAL日志。
流复制功能不仅能传递WAL日志，也能传递其他数据，如数据文件。
两种类型的Standby区别如下：
- Hot Standby：基于热备生成的归档：当主库生成新的归档后，备库对归档进行转储、恢复。这也就表示，hot standby 中，当发生宕机后，备库可能会有一个归档日志的数据丢失。
- Stream Replication：基于 WAL Record：当主库新写了一个 Wal Record 之后，自动对该 record 进行同步，备库接收后进行自动恢复。
5 流复制和逻辑复制对比
- 流复制是物理复制，其核心原理是主库将预写日志WAL日志流发送给备库，备库接收到WAL日志流后进行重做，因此流复制是基于WAL日志文件的物理复制。逻辑复制核心原理也是基于WAL，逻辑复制会根据预先设置好的规则解析WAL日志，将WAL二进制文件解析成一定格式的逻辑变化信息，比如从WAL中解析指定表上发生的DML逻辑变化信息，之后主库将逻辑变化信息发送给备库，备库收到WAL逻辑解析信息后再应用日志。
- 流复制只能对PostgreSQL实例级进行复制，而逻辑复制能够对数据库表级进行复制。
- 流复制能对DDL操作进行复制，比如主库上新建表、给已有表加减字段时会自动同步到备库，而逻辑复制主库上的DDL操作不会复制到备库。
- 流复制主库可读写，但从库只允许查询不允许写入，而逻辑复制的从库可读写。
- 流复制要求PostgreSQL大版本必须一致，逻辑复制支持跨PostgreSQL大版本。
