修改流复制相关的参数,测试影响
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文件或者 服务器命令行上设置。