POSTGRES 15 流复制搭建主备_postgres15 流同步配置

基于流的异步复制（备库崩溃不影响主库使用）

基于pg_basebackup的主备库搭建，pg_basebackup命令的使用方法如下：

pg_basebackup [option...]
1

此命令后可以跟多个选项，各选项的具体说明如下。

• -D directory或–pgdata=directory：指定备份的目标目录，即备份到哪儿。如果这个目录或目录路径中的各级父目录不存在，pg_basebackup就会自动创建该目录。如果目录存在，但不为空，则会导致pg_basebackup执行失败。如果备份的输出是tar结果（指定-F tar ，后面会介绍此选项），而-D参后的目录名写成“-”（中划线），则备份会输出到标准输出，此项功能是为了方便通过管道与其他工具配合使用。
• -F format或–format=format：指定输出的格式。目前支持两种格式，第一种格式是原样输出，即把主数据库中的各个数据文件、配置文件、目录结构都完全一样地写到备份目录中，这种情况下“format”指定为“p”或“plain”；第二种格式是tar格式，相当于把输出的备份文件打包到一个tar文件中，这种情况下“format”应为“t”或“tar”。
• -r，–max-rate=RATE：限速参数，热备份会在主库产生较多的I/O和网络开销，可以用该参数限制速率。速率的默认单位是“kB/s”，当然也可以指定单位“k”或“M”。
• -R，–write-recovery-conf：是否生成recovery.conf文件。
• -x或–xlog：备份时会把备份中主库产生的WAL文件也自动备份出来，这样在恢复数据库时，做出的备份才能应用这些WAL文件把数据库推到一个一致点，然后才能打开备份的数据库。该选项与下面的选项“-X fetch”是完全一样的。使用该选项需要设置wal_keep_segments参数，以保证在备份过程中需要的WAL日志文件不会被覆盖。注意，该参数在PostgreSQL 10版本之后废弃，请用“-X fetch”替代。
• -X method或–xlog-method=method：method可以取的值为“f”“fetch”“s”“stream”，“f” 与“fetch”相同，其含义与“-x”参数是一样的。“s”与“stream”表示的含义相同，均表示备份开始后，启动另一个流复制连接从主库接收WAL日志。这种方式避免了使用“-X f”时，主库上的WAL日志有可能被覆盖而导致失败的问题。但这种方式需要与主库建两个连接，因此使用这种方式时，主库的max_wal_senders参数要设置为大于或等于2的值。
• -z或–gzip：仅能与tar输出模式配合使用，表明输出的tar备份包是经过gzip压缩的，相当于生成了一个*.tar.gz的备份包。
• -Z level或–compress=level：指定gzip的压缩级别，可以选1~9的数字，与gzip命令中的压缩级别的含义是一样的，9表示最高压缩率，但也最耗CPU。
• -c fast|spread或–checkpoint=fast|spread：设置Checkpoint的模式是fast还是spread。
• -l label或–label=label：指定备份的一个标识，备份的标识是一个任意字符串，便于今后维护人员识别该备份，该标识就是手动做基础备份时运行“select pg_start_backup(‘lable’)”传递给pg_start_backup函数的参数。在备份集中有一个文件叫“backup_label”，这里面除了记录开始备份时起始的WAL日志的开始位置、Checkpoint的WAL日志位置、备份的开始时间，也记录了该标识串的信息。
• -P或–progress：允许在备份过程中实时地打印备份的进度。当然，所打印的进度不是百分之百精确的，因为在备份过程中，数据库的数据还会发生变化，还会不断产生一些WAL日志。
• -v或–verbose：详细模式，如当使用了-P参数时，还会打印出正在备份哪个具体文件的信息。
• -V或–version：打印pg_basebackup的版本后退出。
• -?或–help：显示帮助信息后退出。下面是控制连接数据库的参数的说明。
• -h host或–host=host：指定连接的数据库的主机名或IP地址。
• -p port或–port=port：指定连接的端口。
• -s interval或–status-interval=interval：指定向服务器端周期反馈状态的秒数，如果服务器上配置了流复制的超时，当使用–xlog=stream选项时需要设置该参数，默认值为10秒
  。如果设置为“0”，表示不向服务器反馈状态。
• -U username或–username=username：指定连接的用户名。
• -w或–no-password：指定从来不提示输入密码。
• -W或–password：强制让pg_basebackup出现输入密码的提示。

主库

修改pg_hba.conf

su - postgres
vi pg_hba.conf

host    replication     all             0.0.0.0/0               md5
1
2
3
4

修改postgresql.conf

# 必须打开
full_page_writes = on
archive_mode = on

listen_addresses = '*'

# 必须设置为非零值，且比备库数量多
max_wal_senders = 10
# 参数设置为“replica”或“logical”。
wal_level = replica
# 默认值太小，备库容易失效，增大该值
min_wal_size = 2GB
1
2
3
4
5
6
7
8
9
10
11
12

重新加载配置文件

创建流复制用户，避免超级用户权限

create user replicator replication login connection limit 5 password 'replicator';
1

备库

备份数据

pg_basebackup -h 10.10.100.54 -U replicator -F p -P -X stream -R -D /app/postgresql/data -l backup20221117
1

修改配置文件

hot_standby = on
1

启动备库

/app/postgresql/bin/pg_ctl -D /app/postgresql/data -l /app/postgresql/log/logfile start
1

注意事项

由于我是编译安装修改了数据库的块大小，所以必须保证两个库的编译参数完全一样，否则无法启动备库

./configure --prefix=/app/postgresql --with-perl --with-python --with-blocksize=32 --with-wal-blocksize=32 --with-segsize=10
1

主备切换

1. 先停主库，再停备库

2. 然后将原来备库参数加入主库配置文件

3. 在主库创建文件standby.signal

4. 并修改

    primary_conninfo = 'user=replicator password=replicator channel_binding=disable host=10.10.100.62 port=5432 sslmode=disable sslcompression=0 sslsni=1 ssl_min_protocol_version=TLSv1.2 gssencmode=disable krbsrvname=postgres target_session_attrs=any'
   1

5. 删除备库standby.signal

6. 先起备库再起主库

故障切换

1. 修改配置文件

   修改配置文件postgresql.conf

    wal_log_hints = on
   1

   或者初始化数据库时加入-k参数

2. 原备库执行命令

    pg_ctl promote
   1

3. 原主库执行

    pg_rewind -D /app/postgresql/data --source-server='host=10.10.100.54  port=5432 user=postgres password=postgres'
   1

4. 原主库创建文件

   touch /app/postgresql/data/standby.signal

5. 启动备库

同步流复制的Standby数据库

PostgreSQL异步流复制的缺点是当主库损坏的时候，激活备库后会丢失一些数据，这对于一些不允许丢失数据的应用来说是不可接受的，所以PostgreSQL从9.1版本开始提供同步流复制的功能，解决了主备库切换时丢失数据的问题。同步复制要求WAL日志写入Standby数据库后commit才能返回，所以Standby库出现问题时，会导致主库被hang住。解决这个问题的方法是启动两个Standby数据库，这两个Standby数据库只要有一个是正常运行的就不会让主库hang住。所以在实际应用中，同步流复制，总是有一个主库和两个以上的Standby备库。

即使是同步复制，如果因主库发生临时故障激活了其中一个备库，要想把原主库转换成新主库的备库，仍然需要用pg_rewind处理一下才行，这是因为虽然是同步复制，但并不是把主库的WAL日志完全同步地传输到备库，同步只是到事务提交时才保证其已经传输到了备库，一些未提交事务的WAL日志可能还没有传输到备库，因此激活备库时，还是会丢失一些WAL日志。当然对于用户来说，未提交事务的WAL日志丢失，并不会导致用户数据的丢失。

同步复制的配置

同步复制的配置主要是在主库上配置参数“synchronous_standby_names”，该参数指定多个Standby的名称，各个名称用逗号分隔，而Standby名称是在Standby连接到主库时由连接参数“application_name”指定的。

主库

主库修改配置文件postgresql.conf

# 表示有任意一台备库进行同步之后即可返回，可根据需要修改，我只有一个备库所以这么写
synchronous_standby_names = 'ANY 1 (postgresql2)'
wal_level = hot_standby
synchronous_commit = on
# 最大有几个备库
max_wal_senders = 10
hot_standby_feedback = true	
1
2
3
4
5
6
7

synchronous_standby_names：

• FIRST语法下，同步的节点值为sync，异步的节点值为asyn；被匹配为同步的节点，但是被个数限制的值为 potential
• Any语法下，值为quorum，表现上没有同步和异步一说，一个写事务主节点收到指定数量的standy节点的反馈，接着就会给客户端返回事务执行成功。

synchronous_commit：

• remote_apply：WAL日志被传到备库并被apply，事务commit才返回。
• on：WAL日志被传到备库并被持久化（不必等其被apply），事务commit才返回。
• remote_write：WAL日志被传到备库的内存中（不必等其被持久化），事务commit才返回。
• local：WAL日志被本地持久化后（不用管远程）事务commit就可以返回。
• off：不必等WAL日志被本地持久化，也不管是否传到远程，事务commit都可以立即返回。

由上面说明即可联想到同步复制，synchronous_commit的可选值为“on”“remote_apply”“remote_write”

备库修改

修改配置文件postgresql.auto.conf

primary_conninfo = 'application_name=postgresql2 user=replicator password=replicator channel_binding=disable host=10.10.100.54 port=5432 sslmode=disable sslcompression=0 sslsni=1 ssl_min_protocol_version=TLSv1.2 gssencmode=disable krbsrvname=postgres target_session_attrs=any'

primary_conninfo = 'application_name=postgresql2 user=replicator password=replicator host=10.10.100.54 port=5432 sslmode=disable sslcompression=1'
1
2
3

查询所有备库状态

select application_name,client_addr,state, sync_priority, sync_state from pg_stat_replication;
1

注意

由于我写的是’ANY 1 (postgresql2)'，所以查询状态显示不准确

检查状态

主库

select application_name,client_addr,state, sync_priority, sync_state from pg_stat_replication;
1

备库

select * from pg_stat_wal_receiver;
1