作者：瀚高PG实验室（Highgo PG Lab）-天蝎座

PostgreSQL复制方式有两种：物理复制和逻辑复制。

早在PG9.0版本开始支持物理复制，也可以叫流复制（Streaming Replication下文中流复制一般指物理流复制）。PG10版本开始支持逻辑复制。

流复制技术可以在实例级别复制出一个与主库一模一样的从库（备库）。通过流复制，备库不断的从主库同步相应的数据，并在备库apply每个WAL record，这里的流复制每次传输单位是WAL日志的record。而PostgreSQL9.0之前提供的方法是主库写完一个WAL日志文件后，才把WAL日志文件传送到备库，这样的方式导致主备延迟比较大，大概是一个WAL日志文件的大小。PostgreSQL9.0之后还提供了Hot Standby功能，备库在应用WAL record的同时也能够提供只读服务，自此PostgreSQL可以支持读写分离。

逻辑复制通常也称之为选择性复制，他可以做到基于表级别的复制，选择需要逻辑复制的表。

流复制和逻辑复制的区别：

1.流复制支持DDL，逻辑复制不支持DDL
2.流复制备库只读，逻辑复制备库可读写
3.流复制要求大版本一致，逻辑复制支持跨越大版本。
4.流复制只能针对PG实例级进行复制，逻辑复制能够针对数据库表级进行复制。
5.流复制为物理复制，核心原理是主库将WAL流式发送给备库，备库接收到WAL日志后进行重做

逻辑复制核心原理虽然也基于WAL但稍有不同。逻辑复制会根据预先设置好的规则解析WAL日志，将WAL二进制文件解析成一定格式的逻辑变化信息，主库将逻辑变化信息发送给备库，备库接收到WAL逻辑解析信息后再应用。

对于流复制和逻辑复制而言，两者可应用于不同的场景

本系列文章将主要分为以下7个章节介绍：

1. 流复制部署（异步、同步）

2. 流复制监控

3. 流复制主备切换

4. 延迟备库

5. 同步复制优选提交

6. 级联复制

7. 流复制维护生产案例

流复制部署

实验环境：

部署过程如下，主备节点都需要进行操作：
创建用户：
#   groupadd postgres                --创建用户组
#   useradd postgres -g postgres     --创建用户
#   passwd postgres                 --设置postgres用户的密码

创建目录并赋予权限

# mkdir -p /data/postgres/11/
# chown -R postgres:postgres /data/postgres/11/

解压软件并安装：

#   tar -zxvf postgresql-11.1.tar.gz
#   cd postgresql-11.1
#   ./configure –prefix=/data/postgres/11/

安装依赖包：

#   yum install zlib readline
#   gmake world
#   gmake install-world

初始化数据库：

# su – postgres

备库不需要初始化数据库数据目录，以下参数的修改均在主库执行：
$ initdb -D /data/postgres/11/data -E UTF8 –locale=C -U postgres
-- 指定数据库数据目录， -E 指定字符集 -locale 指定区域偏好

数据库安装完成后，需要配置如下所示数据库参数：

wal_level = replica
该参数控制WAL日志信息的输出级别，有minimal，replica，logical三种模式，修改该参数需要重启。
minimal记录的日志最少，只记录数据库异常关闭需要恢复时的WAL信息。
replica记录的WAL信息比minimal信息多些，会记录支持WAL归档、复制和备库中启用只读查询等操作所需的WAL信息。
logical记录的日志最多，包含了支持逻辑解析所需的WAL。
开启流复制至少需要设置为replica级别。
archive_mode = on
该参数控制是否启用归档。On表示启用归档并使用archive_command参数的配置命令将WAL日志归档，修改该参数需要重启数据库。
archive_command = ‘cp %p /data/archivedir/%f’
该参数设置WAL归档命令，可以将WAL归档到本机或者归档到其他主机。流复制并不一定需要配置该参数。你可以声明一个shell命令来拷贝一个完整的WAL文件到它需要去的地方。该命令可以简单的就是一个cp，或者它可以调用一个复杂的shell脚本。
max_wal_senders = 10
该参数控制主库上的最大WAL发送进程。pg_basebackup命令做基准备份时也会消耗WAL进程，此参数不能比max_connections参数高，默认为10.一个流复制备库通常消耗流复制主库一个WAL发送进程。
wal_keep_segments = 512
该参数设置主库pg_wal（10版本以前是pg_xlog）目录保留的最小WAL日志文件数，以便备库落后主库时可以通过主库保留的WAL进行追回。默认情况下每个WAL文件为16MB(编译时可通过--with-wal-segsize设置WAL文件大小)
hot_standby = on
该参数控制数据库恢复过程中是否启用读操作，这个参数通常用在流复制备库，开启参数后流复制备库支持只读SQL，不支持写。

以上为流复制配置过程中主要的参数，除此以外配置主库的pg_hba.conf：
#replication privilege
hots replication repuser 192.168.80.126/32 md5
hots replication repuser 192.168.80.127/32 md5

启动pghost1上的数据库：
$ pg_ctl start
使用超级用户postgres登录到数据库创建流复制用户repuser，流复制用户需要有replication和login权限，该部分建议新建流复制专用用户而不是使用超级用户：
create user replica replication login connection limit 5 encrypted password 'replica';
在pghost2以pg_basebackup命令部署流复制：
$ pg_basebackup -D /data/postgres/11 -Fp -Xs -v -P -h 192.168.80.126 -p 5432 -U repuser
pg_basebackup命令执行的操作为将主库的数据目录同步到备节点，保证主备数据目录保持一致。

进入数据库数据目录下，新建recovery.conf文件并配置以下参数：

recovery_target_timeline = 'latest'
standby_mode = on
primary_conninfo = 'host=192.168.80.126 port=5432 user=repuser'
recovery_target_timeline

设置恢复的时间线，latest表示从备份中恢复到最近的时间线
standby_mode
设置是否启用数据库为备库，如果设置为on，备库会不停的从主库上获取WAL日志流，直到获取主库上最新的WAL日志流。

primary_conninfo
参数设置主库的连接信息，设置了主库IP、端口、用户名信息，但没有配置明文密码，在连接串中给出数据库密码不是好习惯，建议将密码配置在隐藏文件~/.pgpass 中。

$ touch ~/.pgpass
$ chmod 0600 ~/.pgpass

.pgpass文件内容分为五部分，分别为：
IP:端口号:数据库名:用户名:密码
192.168.80.126:5432:replication:repuser:repuser
192.168.80.127:5432:replication:repuser:repuser

流复制部署完成后，可通过pg_stat_replication试图的sync_state字段查看流复制状态：

sync_state字段的可选项包括：

async：表示备库为异步同步模式
sync：当前备库为同步模式
potential：表示备库当前为异步同步模式，如果当前的同步备库宕机后，异步备库可升级成为同步备库。
quorum：表示备库为quorum standbys的候选，后面会介绍这个特性。

同步流复制

前面我们搭建的环境为异步流复制，异步流复制指主库上提交事务时不需要等待备库接收并写入WAL日志就返回成功，如果主库异常宕机，主库上提交的事务可能还没来得及发送给备库，就会造成备库数据丢失。

同步流复制在主库上提交事务时需要等待备库接收并写入WAL日志，当主库至少收到一个备库发回的确认信息时便返回成功，同步流复制确保了至少一个备库收到了主库发送的WAL日志，一方面保障了数据的完整性，另一方面增加了事务响应时间。

介绍同步流复制前先介绍一下参数synchronous_commit，理解它的含义能更好的理解同步流复制。

单实例环境：

on: 当数据库提交事务时，WAL先写入WAL BUFFER再写入WAL日志文件，设置成on表示提交事务时需等待本地WAL写入WAL日志后才返回成功，设置成on非常安全，但数据库性能有损耗。
off: 设置成off时也不会带来风险，但是当数据库宕机时最新提交的事务可能会丢失。
local: local的含义和on类似，表示提交事务时需等待本地WAL写入后才返回成功。

流复制环境：

remote_write: 当流复制提交事务时，需等待备库接收到主库发送的WAL日志流写入备节点操作系统缓存中之后返回成功。备库宕机不会导致事务丢失，但是如果备库操作系统宕机存在事务丢失的风险。本地WAL落盘，备库WAL还在备库操作系统缓存中，只有一份持久化的WAL。
on: 设置成on表示流复制主库提交事务时，需等待备库接收主库发送的WAL日志流写入WAL文件才返回成功。本地WAL落盘，备库的WAL也已经落盘，有两份持久化的WAL。但此时备库还未完成apply。
remote_apply: 表示流复制主库提交事务时，需等待备库接收主库发送的WAL并写入WAL文件，同时备库已经完成重做后才返回成功。本地和备库的WAL都已经落盘，有两份持久化的WAL，同时备库也完成了apply。

备库的recovery.conf配置文件设置如下：

primary_conninfo = 'host=192.168.80.126' port=5432 user=repuser application_name=node2'

primary_conninfo参数添加application_name选项，application_name选项指定备节点的别名，主库postgresql.conf的synchronous_standby_names可引用备库application_name选项设置的值，设置成node2。

主库上postgresql.conf配置文件设置为以下参数，其他参数与异步流复制配置一致。

synchronous_commit = on或者remote_apply

synchronous_standby_names = 'node2'

主库查看复制状态，如下所示：

postgres=# select usename,application_name,client_addr,sync_state from pg_stat_replication;usename  | application_name |  client_addr       | sync_state---------+------------------+--------------------+------------repuser  |     node2        | 192.168.80.127     | sync(1 row)

同步流复制“陷阱”：
在同步流复制中由于主库提交事务时需等待至少一个备库接收WAL并返回确认信息后主库才返回成功。基于以上前提，若备库宕机，则主库所有
写操作将被阻塞。所以若生产环境为一主一备，不应使用同步流复制。一主多从的情况下可以选择一主多从。

流复制浅析 —— 物理流复制部署

流复制部署

更多相关文章

随机推荐