postgresql 流复制相关参数及影响

修改流复制相关的参数，测试影响

wal_level

wal日志级别，这个参数决定了有多少信息写入wal日志，默认是replica。（TDSQL-PG 默认是
logical

• minimal：除了实例crash恢复需要的记录，其他不记录，比如CREATE TABLE AS，CREATE INDEX，CLUSTER，COPY可以跳过，该模式记录的日志信息不足以支持wal归档和流复制。
• replica: 这种模式支持复制和wal归档，同时支持备库只读查询。replica：在9.6之前还有archive和
• hot_standby模式，映射到现在的replica模式。
• logic：在replica的基础上增加一些信息以支持逻辑解码，该模式会增大wal日志的数量，尤其是大量的update，delete操作的库。

日志写入量为logical>replica>minimal，主备复制配置为replica，逻辑复制配置成logical

实验：将wal_level设置为minimal，观察影响

关闭备机、主机
[pg@localhost data]$ pg_ctl -D /data/db2/ stop
waiting for server to shut down.... done
server stopped

[pg@localhost data]$ pg_ctl -D /data/db1/ stop
waiting for server to shut down.... done
server stopped

修改主机wal_level为minimal
[pg@localhost ~]$ vi /data/db1/postgresql.conf
-----------------------------------------
wal_level = minimal
-----------------------------------------

[pg@localhost ~]$ pg_ctl -D /data/db1/ -l /data/db1/server.log start
waiting for server to start.... stopped waiting
pg_ctl: could not start server
Examine the log output.

查看启动日志
[pg@localhost ~]$ less /data/db1/server.log
-----------------------------------------
2024-01-10 11:25:50.540 CST [3279] LOG:  database system is shut down
2024-01-10 11:41:17.541 CST [4304] LOG:  listening on IPv6 address "::1", port 15431
2024-01-10 11:41:17.541 CST [4304] LOG:  listening on IPv4 address "127.0.0.1", port 15431
2024-01-10 11:41:17.552 CST [4304] LOG:  listening on Unix socket "/tmp/.s.PGSQL.15431"
2024-01-10 11:41:17.562 CST [4304] LOG:  redirecting log output to logging collector process
2024-01-10 11:41:17.562 CST [4304] HINT:  Future log output will appear in directory "log".
2024-01-10 13:40:44.113 CST [10943] FATAL:  WAL streaming (max_wal_senders > 0) requires wal_level "replica" or "logical"

结论：wal_level设置为minimal不支持流复制

synchronous_standby_names

这个参数用来指定同步备机的列表，存放的是需要设置为同步备机的备机名称。synchronous_commit 不为off和local 的时候有效。

参数值有下面几种表达方式：

• synchronous_standby_names=‘s1,s2’ 代表s1或s2备机任一返回就可以提交，同ANY 1(s1,s2)。
• synchronous_standby_names=‘FIRST 2 (s1,s2,s3)’ 代表s1，s2，s3三个备机中前两个s1和s2返
  回主库就可以提交。
• synchronous_standby_names=‘ANY 2 (s1,s2,s3)’ 代表s1，s2，s3三个备机中任意两个备机返回主库就可以提交，基于quorum协议。
• synchronous_standby_names=’*’ *代表匹配任意主机，也就是任意主机返回就可以提交。

s1，s2，s3代表备机的application_name，在备机recovery.conf的primary_conninfo参数中配置：
primary_conninfo = ‘host=localhost port=15431 application_name=s1’

实验：调整 synchronous_commit 及synchronous_standby_names观察影响
初始条件：主从同步正常

设置备库1的 application_name
[pg@localhost ~]$ vi /data/db2/postgresql.conf
---------------------------------------
primary_conninfo = 'host=localhost port=15431 application_name=s1'
---------------------------------------

重截备机配置
[pg@localhost ~]$ pg_ctl -D /data/db2/ reload

修改主库配置
[pg@localhost ~]$ vi /data/db1/postgresql.conf
---------------------------------------
synchronous_commit = on
synchronous_standby_names = 's1,s2'  #添加一个不存在的备库 s2
---------------------------------------
重载主库配置
[pg@localhost ~]$ pg_ctl -D /data/db1/ reload

根据上面的操作修改数据库参数并，并在主库进行dll和dml操作得到如下结果：

参数	影响
synchronous_commit = off synchronous_standby_names = ‘s1,s2’	同步正常
synchronous_commit = local synchronous_standby_names = ‘s1,s2’	同步正常
synchronous_commit = on synchronous_standby_names = ‘s1,s2’	同步正常
synchronous_commit = on synchronous_standby_names = ‘ANY 2 (s1,s2)’	s2备库不存在，DLL,DML语句hang住。 ctrl+c 强制退出后执行成功，s1同步正常
synchronous_commit = remote_write synchronous_standby_names = ‘ANY 2 (s1,s2)’	s2备库不存在，DLL,DML语句hang住。 ctrl+c 强制退出后执行成功，s1同步正常

其他参数

没有测试条件，先记录一下。

wal_keep_segments

设置“pg_wal”目录下保留事务日志文件的最小数目用于流复制，如果备机停机时间过长导致主库
xlog被删除，那么主备关系会失败，但是如果开启了归档，备机可以从归档日志中继续恢复。

max_wal_size (integer)

在自动WAL检查点使得WAL增长到最大尺寸。
这是软限制；特殊情况下WAL大小可以超过 max_wal_size，如重负载下，错误archive_command，或者 较大wal_keep_segments的设置。缺省是1GB。 增加这个参数会延长崩溃恢复所需要的时间。
这个参数只能在postgresql.conf文件或者服务器命令行上设置。

min_wal_size (integer)

只要WAL磁盘使用率低于这个设置，旧的WAL文件总数被回收，以供将来检查点使用。
而不是删除。 这可以用来确保预留足够的WAL空间处理WAL使用中的峰值，比如当运行大批量工作时。 缺省是80MB。这个参数只能在postgresql.conf文件或者 服务器命令行上设置。