[译文] 在 PostgreSQL 13 中设置流复制和流复制内部

在迁移到 PostgreSQL 时，一些用户可能对 PostgreSQL 提供的复制类型感到好奇。有些人可能想知道他们是否必须支付任何额外的企业许可证才能达到此要求。这是因为，一些商业数据库需要客户获取企业许可证才能设置复制。但是，PostgreSQL 与高级开源数据库一样，自动提供了多种内置的复制方法。这意味着，在使用 PostgreSQL 时，我们永远不必考虑采用任何额外的许可证或企业解决方案，并避免供应商锁定。在本文中，我们将讨论流复制的内部结构，并了解在 PostgreSQL 13 中设置流复制所涉及的详细步骤。

PostgreSQL 支持两种类型的复制。

• 流式复制（同步和异步）
• 逻辑复制（同步和异步）

流式复制

流式复制也可以称为物理复制。人们通常会在 postgres 中听到 master 和 standby 这两个术语。主服务器是接受写入并将更改流式传输到备用服务器的服务器。在某些数据库技术中，它可以与主数据库进行比较。而备用数据库从主数据库复制更改并仅接受读取。在某些数据库技术中，它可能被称为副本。

流复制的内部结构

要了解流复制如何工作的内部原理，我们需要从 ACID 属性开始。ACID 中的字母 D 表示耐用性。当关系数据库确保提交的事务永远不会丢失时，持久性就被认为是实现了，即使在崩溃时也是如此。通常，内存（或 RAM）中的任何内容都可能在崩溃时丢失，但磁盘上的任何内容都不会丢失。

考虑到这一事实，PostgreSQL 中存在一个称为 WAL Writer 的后台实用程序进程，它不断地将 WAL 记录从内存写入磁盘上的 WAL（Write-Ahead 日志）段。后端还可以将 WAL 缓冲区刷新到 WAL 段。这意味着只有在将事务写入磁盘上的 WAL 段时才说事务成功。当然，这个默认行为总是可以改变的。

在下面的流式复制架构图中，我们看到了一些块/缓冲区如何由于 UPDATE 语句而变成脏块的示例。脏缓冲区或脏块是由于该块中元组（或记录）的更改而被修改的缓冲区。

如上面的流式复制架构图所示，WAL 段包含 WAL 记录，这些记录包括对数据块所做的更改（以 DML 或 DDL 的形式）。

当我们设置流式复制时，会在主服务器上启动一个名为 WAL 发送器的新后台进程。此进程接受来自备用数据库的请求，并将 WAL 记录连续流式传输到其备用数据库。类似地，一个名为 WAL 接收器的后台进程在备用服务器上启动，它接收并应用这些更改。可以在此处查看有关流式复制协议的更多内部信息。

现在让我们看看设置流式复制所涉及的详细步骤。

在 PostgreSQL 中设置流式复制的步骤

第 1 步：创建具有复制角色的复制用户。
（要在master上执行的步骤）

$ psql -p 5432 -c "CREATE USER replicator WITH REPLICATION ENCRYPTED PASSWORD 'secret'"

第 2 步：允许备用数据库的复制用户连接到主数据库。有关pg_hba.conf 的更多详细信息，请参阅此文档。
（要在master上执行的步骤）

$ vi /var/lib/pgsql/13/data/pg_hba.conf

>>> Add entry

host  replication          replicator         192.169.12.1/32         md5

将 192.169.12.1 替换为应该允许与主服务器建立复制连接的备用服务器的 IP 地址。

第 3 步：执行重新加载以使更改生效。
（要在master上执行的步骤）

$ psql -c "select pg_reload_conf()"

第 4 步：以下是使我们能够为生产数据库执行稳健复制设置的配置参数列表。
（要在master上执行的步骤）

请注意：其中一些参数对于流式复制不是必需的，但仅适用于良好的设置。

• max_wal_senders ：可以在主服务器上启动的 WAL 发送器进程数。每个副本一个。pg_basebackup 可以使用一个或两个 Wal 发送器，稍后将在单独的博客文章中讨论。max_wal_senders 在所有发行版上通常默认为 10。所以，这个参数不需要修改，除非我们给一个master设置了超过5个standby。

 ALTER SYSTEM SET max_wal_senders TO '10';

• listen_addresses ：此参数确定允许连接的 IP 接口。它默认为本地主机。它可以设置为公共或私有 IP 接口或通过使用 (*) 的所有内容。

ALTER SYSTEM SET listen_addresses TO '*';

• archive_mode ：此参数必须设置为“ON”才能启用存档。启用存档后，WAL 段会在回收之前复制到存档位置。（archive_mode 不是强制性参数，但建议用于生产数据库）

ALTER SYSTEM SET archive_mode TO 'ON';

• archive_command ：归档程序应使用的 shell 命令或脚本来执行完整 WAL 段的归档。以下是在 linux中使用cp命令的示例设置。 例如，

ALTER SYSTEM SET archive_command TO 'cp %p /archives/%f';

%p被 postgres 替换为实际 WAL 段的路径。
%f 被 postgres 替换为 WAL 文件名。

（archive_command 不是强制性参数，但建议用于生产数据库）。除非archive_mode 设置为“always”，否则此参数对待机没有影响。

• restore_command ：shell 命令或脚本，当 WAL 段对主服务器不可用时（当 WAL 段在其保留在主服务器上时被回收时），备用服务器使用该脚本从存档位置复制 WAL 段。该参数对主站没有影响。这仅在备用或使用完整备份和存档执行时间点恢复时才需要。例如，

ALTER SYSTEM SET restore_command TO 'cp /archives/%f %p';

• wal_keep_size ：在回收之前至少要保留在 pg_wal 目录中的 WAL 段的数量。

ALTER SYSTEM SET wal_keep_size TO '1GB';

• wal_compression ：这不是强制性参数，但当它设置为“ON”时，在写入 WAL 段之前的每个整页都将被压缩。这减少了 WAL 写入并在磁盘上节省了一些 IOPS。

ALTER SYSTEM SET wal_compression TO 'ON';

第 5 步：根据需要重新加载或重新启动，当参数发生变化时。
（在master上执行的步骤）

$ psql -p 5432 -c "select pg_reload_conf()"

$ psql -p 5432 -c "select name, setting, pending_restart from pg_settings where pending_restart IS true"

必要时重新启动。PGD​​ATA 是数据目录的环境变量。

$ pg_ctl -D $PGDATA restart -mf

第 6 步：对 master 进行完整备份，以在备用上创建数据目录的副本。如果适用，将 IP 地址替换为 master 的 IP 或主机名。
（在备用服务器上执行的步骤，如果主服务器的备份是从备用服务器远程进行的）

$ pg_basebackup -h 192.169.12.1 -p 5432 -U 复制器 -D /var/lib/pgsql/13/data -Fp -R -Xs -P

• Fp ：所有子目录及其内容（数据文件等）的普通副本。
• R ：在 postgresql.auto.conf 文件中自动配置复制特定设置。
• Xs ：使用单独的通道/进程，将正在进行的更改（WAL 记录）从主服务器流式传输到备用服务器，同时进行备份。
• P ：显示备份进度。
• c fast ：此标志可用于执行快速检查点并避免等待延迟检查点完成。

步骤 7：验证是否设置了以下参数。否则，在备用设备上适当地设置它们。
（要在备用机上执行验证）

primary_conninfo ：当使用 -R 标志进行备份时，如步骤 6 所示，primary_conninfo 参数会自动添加到数据目录中的 postgresql.auto.conf 文件中（见以下日志）。postgres 通过 postgresql.conf 或其他配置文件将这个文件中设置的参数视为 include_dir 的一部分。

$ cd $PGDATA

$ grep primary_conninfo postgresql.auto.conf 
primary_conninfo = 'user=replicator password=secret channel_binding=prefer host=192.169.12.1 port=5432 sslmode=prefer sslcompression=0 ssl_min_protocol_version=TLSv1.2 gssencmode=prefer krbsrvname=postgres targetany_session'

此参数帮助备用设备了解其主设备的连接详细信息。Standby 使用添加到此配置参数的用户、主机、端口和其他详细信息，通过流式复制协议从其主服务器开始流式传输 WAL 记录。

restore_command ：当所需的 WAL 段对其主服务器不可用时，这是备用服务器用来从档案中恢复 WAL 段的命令。这通常发生在 WAL 段尚未由备用服务器流式传输但 WAL 段已被主服务器回收时。我们还可以使用物理复制槽来避免主服务器回收 WAL 段，除非它被确认被备用服务器接收。我们需要使用 shell 命令或指定给 restore_command 的脚本来确保备用数据库可以访问存档目录或服务器。

ALTER SYSTEM SET restore_command TO 'cp /archives/%f %p';

我们可以在本文档中有关postgres 流复制的配置参数的文档中看到有关上述参数的更多详细信息。

步骤 8：创建一个信号文件来说明该服务器是备用服务器。Standby.signal 文件必须在备用数据库的数据目录中创建。
（要在待机上执行的步骤）

$ touch /var/lib/pgsql/13/data/standby.signal

第 9 步：启动备用数据库以启用复制。
（要在待机上执行的步骤）

$ pg_ctl -D /var/lib/pgsql/13/data start

步骤 10：在主服务器上使用以下命令验证主服务器和备用服务器之间的复制。
（要在 master 上执行验证）

$ psql -x -c "select * from pg_stat_replication"

输出如下所示 -

$ psql -x -c "select * from pg_stat_replication"
-[ RECORD 1 ]----+------------------------------
pid | 28435
usesysid | 16384
usename | replicator
application_name | walreceiver
client_addr | 192.169.12.1
client_hostname | 
client_port | 49806
backend_start | 2021-03-31 12:39:22.876997+00
backend_xmin | 
state | streaming
sent_lsn | 0/3000148
write_lsn | 0/3000148
flush_lsn | 0/3000148
replay_lsn | 0/3000148
write_lag | 00:00:00.126533
flush_lag | 00:00:00.127325
replay_lag | 00:00:00.127386
sync_priority | 0
sync_state | async
reply_time | 2021-03-31 12:39:23.021395+00

到目前为止，我们已经看到了在 PostgreSQL 13 中设置流式复制所涉及的步骤。