PostgreSQL实战之物理复制和逻辑复制（八）

8 级联复制

8.1 级联复制物理架构

8.2 级联复制部署

PostgreSQL实战之物理复制和逻辑复制（八）

8 级联复制

实际上PostgreSQL支持备库既可接收主库发送的将WAL，也支持WAL发送给其他备库，这一特性称为级联复制(Cascading Replication)，本章介绍级联复制的物理架构和部署。

8.1 级联复制物理架构

介绍级联复制物理架构之前，先看下一主两备流复制物理架构，如图所示。

上图中 Master为主库，两个备库分别为Save1、Slave2，Save1和 Slave2都通过流复制直连Master，三个数据库主机都位于机房A。
级联复制物理架构图如下所示。

第二张图的级联复制架构与第一张图中架构的主要区别在于Slave2备库不是直连Master主库，而是连接到Slave1备库，Slave1备库一方面接收来自Master发送的WAL日志，另一方面将WAL日志发送给Slave2备库，将既接收WAL同时又发送WAL的备库称为级联备库( cascading standby)，这里Slave1就是级联备库，另外，将直连到主库的备库称为上游节点，连接到上游节点的其他备库称为下游节点。

级联复制主要作用在于:

小幅降低主库CPU压力。
减少主库带宽压力。
异地建立多个备库时，由于只需要一个备库进行跨机房流复制部署，其他备库可连接到这个级联备库，这种部署方案将大幅降低跨机房网络流量。

级联复制一个典型应用场景为一主两备，其中一个备库和主库同机房部署以实现本地高可用，另一备库跨机房部署以实现异地容灾，如下图所示。

上图中 Slave1和Master为同机房，之间通过流复制实现本地高可用，Slave2为异地机房，通过级联复制实现异地容灾。

8.2 级联复制部署

这一节将演示级联复制的部署

物理部署图详见下图

计划部署Slave1为级联复制节点，Slave2为备节点并上联到Slave1o
首先部署Slavel，使用异步流复制方式，Slave1的recovery.conf配置如下所示：

recovery_target_timeline = 'latest'
standby_mode = on
primary_conninfo = 'host=192.168.28.74 port=1921 user=repuser application_name=slavel'

Slave1部署完成后，检查流复制状态，如果一切正常接着部署Slave2，重做Slave2备库，如下所示：

[postgres@pghost3 pg10]$ pg_basebackup -D /database/pg10/pg_root -Fp -Xs -v -p -h
192.168.28.74 -p 1921 -U repuser
pg_basebackup: initiating base backup，waiting for checkpoint to complete
pg_basebackup: checkpoint completed
pg_basebackup: write-ahead log start point: 4/4E000028 on timeline 7
pg_basebackup: starting background wAL receiver
9424317/9424317 kB (100%), 3/3 tablespaces
pg_basebackup: write-ahead log end point: 4/4E004AA8
pg_basebackup: waiting for background process to finish streaming ...
pg_basebackup: base backup completed

配置Slave2的recovery.conf配置文件，如下所示：

recovery_target_timeline = 'latest '
standby_mode = on
primary_conninfo = 'host=192.168.28.75 port=1921 user-repuser application_name=slave2'

之后启动Slave2，如下所示：
检查Slave2日志，如果有报错则根据错误信息排错，以上是级联复制部署的所有步骤。在Master查询pg_stat_replication视图，如下所示：

postgres=#SBLECT pid, usename, application_name,client_addr, state,sync_state,sync_priority
FROM pg_stat_replication ;
pid    |  usename  | application_name |  client_addr  |    state   | sync_ state  | 
-------------------+------------------+--—------------+-----------------------------
25041  |  repuser  |       slave1     | 192.168.28.75 |  streaming |    async     |


sync priority
-------------
     0 

(1 row)

以上显示了一条记录，为Master到 Slave1的 WAL发送进程。在Slave1查询pg_stat_replication视图，如下所示：

postgres=# SELECT pid,usename, application_name,client_addr,state,sync_state, sync priority
FROM pg_stat_replication;
pid   |  usename  | application_name | client_addr |   state  | sync_state | sync_priority
------+-----------+------------------+-------------+----------+------------+---------------
5002  |  repuser  | slave2           |192.168.28.76| streaming|   async    |      0

(1 row)

以上显示了Slave1到Slave2的WAL发送进程，可见Slave1上也有了WAL发送进程。接着做个数据测试，在 Master 上创建一张表，并插入数据，如下所示：

[postgrespghost1 ~]$ psql postgres postgres
postgres=# CREATE table t_sr6(id int4);
CREATE TABLE

postgres=# INSERT INTO t_sr6 VALUES (1);
INSERT 0 1

在Slave1上验证数据，如下所示:

[postgres@pghost2 pg_root]$ psql postgres postgres
postgres=# SELECT * FROM t_sr6;
id
----
1
(1 row)

Slave1上有了表t_sr6，在 Slave2上验证数据，如下所示：

[postgres@pghost3 pg_root]$ psql postgres postgres
postgres=# SELECT * FROM t_sr6;
id
-----
1
(1 row)

Slave2上也有了数据。