1.概述
postgresql 12被认为是一个大的更新，包括对性能的重大改进，包括分区增强，索引改进，优化的计划程序逻辑等。主要变化之一是删除recovery.conf了备用集群。因此，设置流复制群集的过程已更改，在本博客中，我将演示如何在pg12中正确设置流复制设置。
流复制设置需要一个主群集和一个或多个从群集，这些群集将通过流传输由主生成的已归档wal文件来复制插入到主数据库中的数据。主服务器和从服务器可以驻留在通过网络连接的不同计算机上，但是在本博客中，我们将使用一个主服务器和一个从服务器设置，并且两者都将在具有不同端口号的同一台计算机上运行。
本博客中说明的过程基于postgres版本12，该版本是从在ubuntu 18.04上运行的源构建的
2.主数据库群集设置
使用initdb工具创建一个主数据库集群：
$ initdb /home/caryh/streaming-replication/db-master
$ cd /home/caryh/streaming-replication
/home/caryh/streaming-replication是我们将在此blog中创建的所有数据库集群的根文件夹，将在此处创建db-master目录。让我们修改默认的postgreql.conf并启用以下几个重要的配置选项，以进行流复制设置。
############# db-master/postgresql.conf #############
wal_level = replica
archive_mode = on
max_wal_senders = 10
wal_keep_segments = 10
hot_standby = on
archive_command = 'test ! -f /home/caryh/streaming-replication/archivedir/%f && cp %p /home/caryh/streaming-replication/archivedir/%f'
port = 5432
wal_log_hints = on
上面的配置使postgres在完成写入完整的wal文件块时或发出pg_basebackup命令时，可以将wal文件归档在目录/home/caryh/streaming-replication/archivedir/中，其中％f将替换为目标wal文件的文件名，而％p将替换为目标wal文件的路径。
进行设置archive_command以确保将wal文件归档到从属群集可以访问的位置时，这一点非常重要。
另外，wal_log_hints必须启用pg_rewind工具才能使其正常工作。我们将在下一篇博客文章中讨论有关pg_rewind的更多信息。
检查客户端身份验证文件db-master/pg_hba.conf，并确保主群集允许从从群集远程复制连接。就我而言，我的主服务器和从服务器都将在同一主机上运行，因此我将保留loopback ip地址。如果您的从属群集位于另一台计算机上，请确保将正确的loopback 地址替换为正确的地址。
############# db-master/pg_hba.conf #############
# allow replication connections from 127.0.0.1, by a user with the replication privilege.
# type database user address method
host replication all 127.0.0.1/32 trust
使用上述配置文件启动master数据库集群，创建具有复制权限的超级用户，以及一个名为clusterdb的数据库。
$ pg_ctl -d db-master start $ createuser cary -s --replication $ createdb clusterdb
将一些测试数据插入主群集。为简单起见，我们将向插入100个整数test_table。
$ psql -d clusterdb -u cary -c "create table test_table(x integer)"
create table
$ psql -d clusterdb -u cary -c "insert into test_table(x) select y from generate_series(1, 100) a(y)"
insert 0 100
$ psql -d clusterdb -u cary -c "select count(*) from test_table"
count
-------
100
(1 row)
3.从数据库群集设置
设置从属群集的目的是对当前主服务器进行备份并将其设置为备用服务器，这意味着它将从主服务器流式传输wal文件更新并执行数据复制。
postgres提供了几种工具和方法来执行物理数据库备份。诸如pg_start_backup(‘label’)和的独占方法pg_stop_backup()在较早的postgres版本中很常见。在此博客中，我们将使用更新且更简单的非排他性pg_basebackupfronend工具执行备份
$ pg_basebackup -h 127.0.0.1 -u cary -p 5432 -d db-slave -p -xs -r 31373/31373 kb (100%), 1/1 tablespace
其中：
-h是主群集的ip
-u是允许进行复制的用户名
-p是正在运行的主群集的端口号
-d是我们要在其中设置从数据库群集的目录
-p显示进度
-xs选择wal流方法
-r编写一个recovery.conf文件。
此步骤与以前的pg版本有所不同。-r命令将不再在db-slave目录中输出recovery.conf文件。
$ ls db-slave backup_label pg_dynshmem pg_multixact pg_snapshots pg_tblspc pg_xact base pg_hba.conf pg_notify pg_stat pg_twophase postgresql.auto.conf global pg_ident.conf pg_replslot pg_stat_tmp pg_version postgresql.conf pg_commit_ts pg_logical pg_serial pg_subtrans pg_wal standby.signal
旧的recovery.conf文件的内容将移至postgresql.conf和postgresql.auto.conf。
先检查一下db-slave/postgresql.auto.conf，我们将看到pg_basebackup已经primary_conninfo为我们创建了。该行以前位于recovery.conf其中，它告诉从群集应从何处以及如何从主群集中流式传输。确保postgresql.auto.conf中存在此行。
############# db-slave/postgresql.auto.conf #############
# do not edit this file manually!
# it will be overwritten by the alter system command.
primary_conninfo = 'user=cary passfile=''/home/caryh/.pgpass'' host=127.0.0.1 port=5432 sslmode=prefer sslcompression=0 gssencmode=disable target_session_attrs=any'
让我们检查db-slave/postgresql.conf并更新一些参数。
############# db-slave/postgresql.conf #############
wal_level = replica
archive_mode = on
max_wal_senders = 10
wal_keep_segments = 10
hot_standby = on
archive_command = 'test ! -f /home/caryh/streaming-replication/archivedir/%f && cp %p /home/caryh/streaming-replication/archivedir/%f'
wal_log_hints = on
port = 5433
restore_command = 'cp /home/caryh/streaming-replication/archivedir/%f %p'
archive_cleanup_command = 'pg_archivecleanup /home/caryh/streaming-replication/archivedir %r'
由于db-slave/postgresql.conf是通过pg_basebackup从主群集直接复制的，因此我们需要将其更改为port与主端口不同的端口（在本例中为5433），因为两者都在同一台计算机上运行。我们将需要填充restore_command和，archive_cleanup_command因此从属群集知道如何获取已归档的wal文件以进行流传输。这两个参数曾经在pg12中定义recovery.conf并移至其中postgresql.conf。
请注意，在db-slave目录中，standby.signal将自动创建一个新文件，pg_basebackup以指示该从集群将以standby模式运行。该standby.signal文件是pg12中的新增功能，用以替代standby_mode = 'on’以前在中定义的文件recovery.conf。如果此文件不存在，请确保通过以下方式创建它：
$ touch db-slave/standby.signal
现在，让我们启动从集群：
$ pg_ctl -d db-slave start
4.验证流复制设置
一旦主集群和从集群都已设置并运行，我们应该从ps -ef命令中看到一些后端进程已启动以实现复制，即walsender和walreceiver。
$ ps -ef | grep postgres
caryh 12782 2921 0 16:12 ? 00:00:00 /usr/local/pgsql/bin/postgres -d db-master
caryh 12784 12782 0 16:12 ? 00:00:00 postgres: checkpointer
caryh 12785 12782 0 16:12 ? 00:00:00 postgres: background writer
caryh 12786 12782 0 16:12 ? 00:00:00 postgres: walwriter
caryh 12787 12782 0 16:12 ? 00:00:00 postgres: autovacuum launcher
caryh 12788 12782 0 16:12 ? 00:00:00 postgres: archiver last was 000000010000000000000002.00000028.backup
caryh 12789 12782 0 16:12 ? 00:00:00 postgres: stats collector
caryh 12790 12782 0 16:12 ? 00:00:00 postgres: logical replication launcher
caryh 15702 2921 0 17:06 ? 00:00:00 /usr/local/pgsql/bin/postgres -d db-slave
caryh 15703 15702 0 17:06 ? 00:00:00 postgres: startup recovering 000000010000000000000003
caryh 15708 15702 0 17:06 ? 00:00:00 postgres: checkpointer
caryh 15709 15702 0 17:06 ? 00:00:00 postgres: background writer
caryh 15711 15702 0 17:06 ? 00:00:00 postgres: stats collector
caryh 15713 15702 0 17:06 ? 00:00:00 postgres: walreceiver streaming 0/3000148
caryh 15714 12782 0 17:06 ? 00:00:00 postgres: walsender cary 127.0.0.1(59088) streaming 0/3000148
caryh 15728 10962 0 17:06 pts/5 00:00:00 grep --color=auto post
我们还可以通过向主集群发出查询来详细检查复制状态：
$ psql -d clusterdb -u cary -c "select * from pg_stat_replication;" -x -p 5432
-[ record 1 ]---- ------------------------------
pid | 15714
usesysid | 16384
usename | cary
application_name | walreceiver
client_addr | 127.0.0.1
client_hostname |
client_port | 59088
backend_start | 2019-10-29 17:06:49.072082-07
backend_xmin |
state | streaming
sent_lsn | 0/3000148
write_lsn | 0/3000148
flush_lsn | 0/3000148
replay_lsn | 0/3000148
write_lag |
flush_lag |
replay_lag |
sync_priority | 0
sync_state | async
reply_time | 2019-10-29 17:10:09.515563-07
最后，我们可以将其他数据插入主群集，并验证从属群集是否也更新了数据。
# query slave cluster
$ psql -d clusterdb -u cary -c "select count(*) from test_table" -p 5433
count
-------
100
(1 row)
# query master cluster
$ psql -d clusterdb -u cary -c "select count(*) from test_table" -p 5432
count
-------
100
(1 row)
# insert more data to master cluster
$ psql -d clusterdb -u cary -c "insert into test_table(x) select y from generate_series(1, 100) a(y)" -p 5432
insert 0 100
# query slave cluster again
psql -d clusterdb -u cary -c "select count(*) from test_table" -p 5433
count
-------
200
(1 row)
现在，主群集和从群集都已同步。
5.设置复制插槽
前面的步骤说明了如何正确设置主群集和从群集之间的流复制。但是，在某些情况下，由于某些原因，从属服务器可能会断开连接，从而导致时间延长，并且当某些未复制的wal文件被回收或从wal_keep_segments参数控制的主群集中删除时，可能无法与主服务器进行复制。
复制插槽确保主服务器可以为所有从服务器保留足够的wal段以接收它们，并防止主服务器删除可能导致从服务器上发生恢复冲突的行。
让我们在主集群上创建一个复制插槽slave：
$ psql -d clusterdb -u cary -c "select * from pg_create_physical_replication_slot('slave')" -p 5432
slot_name | lsn
----------- -----
slave |
(1 row)
$ psql -d clusterdb -u cary -c "select * from pg_replication_slots" -x -p 5432
-[ record 1 ]------- ---------
slot_name | slave
plugin |
slot_type | physical
datoid |
database |
temporary | f
active | f
active_pid |
xmin |
catalog_xmin |
restart_lsn |
confirmed_flush_lsn |
我们刚刚在master上创建了复制插槽slave，该复制插槽当前未处于活动状态（active = f）。
让我们修改从属服务器postgresql.conf并使其连接到主服务器的复制插槽
############# db-slave/postgresql.conf #############
primary_slot_name = 'slave'
请注意，这个参数primary_slot_name我们也曾经在pg12中定义recovery.conf并移至postgresql.confpg12中。更改后，我们需要重新启动从站。
$ pg_ctl -d db-slave stop $ pg_ctl -d db-slave start
如果一切正常，则检查主服务器上的复制插槽的插槽状态应为活动状态。
$ psql -d clusterdb -u cary -c "select * from pg_replication_slots" -x -p 5432
-[ record 1 ]------- ----------
slot_name | slave
plugin |
slot_type | physical
datoid |
database |
temporary | f
active | t
active_pid | 16652
xmin |
catalog_xmin |
restart_lsn | 0/3003b98
confirmed_flush_lsn |
6.总结
在此博客中，我们讨论了在pg12中设置流复制群集，其中从旧版本更改了几个步骤，尤其是删除了recovery.conf。
这是与复制设置相关的更改的简短列表，这些更改已从 recovery.conf
restore_command =>移至 postgresql.conf
recovery_target_timeline =>已移至 postgresql.conf
standby_mode =>替换为 standby.signal
primary_conninfo =>移至postgresql.conf或postgresql.auto.conf
archive_cleanup_command =>移至 postgresql.conf
primary_slot_name =>移至 postgresql.conf