赞
踩
1.使用流复制,配置复制槽
2.只有一个备库时不配置同步,多个备库时ANY
3.测试切换
postgresql.conf
# WAL参数 # wal_level=replica # 默认replica # synchronous_commit=on # 默认为on。只要不配置synchronous_standby_names,这里不配置off结果都一样。 # full_page_writes=on # 默认为on,必须为on wal_compression=on #默认为off,开启wal压缩 # wal_writer_delay wal_writer_flush_after 这两参数就用默认值,如果写磁盘过于频繁增加该值 # checkpoint参数 checkpoint_timeout # 默认5min,增加能提高性能但要崩溃后恢复的时间更长。checkpoint对数据库的影响还是挺大的。 checkpoint_completion_target=0.8 # 用上面0.8倍的时间进行checkpoint,平滑I/O # 归档参数 archive_mode=always # 默认为off。主备环境要开启,万一WAL没了还能用归档拿。设置为always切换后也不用再设置归档。 archive_command='test ! -f /home/postgres/pg_arch/%f && cp %p /home/postgres/pg_arch/%f' # 改成实际路径 # archive_timeout 默认不切换,流复制不需要发送wal文件不需要切换 # archive_cleanup_command 主库不会自动清除,备库会自动清除 # restore_command # 在备库上配置时是通过log方式复制,流复制不需要。主库上配置时仅在recovery时有效果。 archive_cleanup_command ='pg_archivecleanup /home/postgres/pg_arch %r' # send 配置 # max_wal_senders # 默认10,够用 # max_replication_slots # 默认10,够用 wal_keep_segments=64 # 保留1G应该够了吧 track_commit_timestamp=on # 开启保留时间戳功能 # 主库设置 # synchronous_standby_names 不配置,不设置同步,除非有明确需求 # vacuum_defer_cleanup_age 默认为0,立即删除。
pg_hba.conf
host replication standby 192.168.0.38 md5
create database test;
\c test;
create user replicat_user replication password 'bfd@dev24';
SELECT * FROM pg_create_physical_replication_slot('slot_01');
SELECT slot_name, slot_type, active FROM pg_replication_slots;
create table t1(id int);
insert into t1 values(1),(2),(3);
在备库执行,需要有superuser或者replication的权限才行.
用pg_basebackup导过来之后,整个数据目录都导过来了,包括数据文件,因此只需要修改配置文件就行了
pg_basebackup -h abc07 -U replicat_user -D pg_data -X s
postgres.conf
Primary_conninfo = 'host=abc07 port=5432 user=replicat_user password=bfd@dev24 '
primary_slot_name = 'slot_01'
pg_hba.conf
host replication standby 192.168.0.37 md5
数据目录下:
touch standby.signal
一定要用启动数据库的用户创建
略
同步后replication_user用户也被同步到备库,不需要再创建。
SELECT * FROM pg_create_physical_replication_slot('slot_01');
SELECT slot_name, slot_type, active FROM pg_replication_slots;
select * from t1;
2023-04-28 09:24:02.312 CST [26908] LOG: started streaming WAL from primary at 0/7000000 on timeline 1
关闭主库后
2023-04-28 09:55:11.791 CST [26908] LOG: replication terminated by primary server
2023-04-28 09:55:11.791 CST [26908] DETAIL: End of WAL reached on timeline 1 at 0/80000A0.
2023-04-28 09:55:11.791 CST [26908] FATAL: could not send end-of-streaming message to primary: no COPY in progress
2023-04-28 09:55:11.791 CST [26903] LOG: invalid record length at 0/80000A0: wanted 24, got 0
2023-04-28 09:55:11.807 CST [32659] FATAL: could not connect to the primary server: server closed the connection un
expectedly
This probably means the server terminated abnormally
before or while processing the request.
2023-04-28 09:55:16.798 CST [32669] FATAL: could not connect to the primary server: could not connect to server: Co
nnection refused
Is the server running on host "abc07" (192.168.0.37) and accepting
TCP/IP connections on port 5432?
https://blog.csdn.net/pg_hgdb/article/details/125264019
不设置promote_trigger_file,使用pg_ctl promote或者pg_promote来提升备库为主库。任务有执行该函数权限的用户都可以执行。
pg_promote(wait boolean DEFAULT true, wait_seconds integer DEFAULT 60)。 当wait为true时直到提升成功或者达到wait_seconds的时间才返回true,当wait为false时,直接返回true。
可以使用以下两种方式:
$ pg_ctl promote [-D DATADIR] [-W] [-t SECS] [-s]
或者:
postgres=# select pg_promote(true,60);
pg_promote
------------
t
(1 row)
提升后日志显示:
2023-04-28 10:05:35.761 CST [26903] LOG: received promote request
2023-04-28 10:05:35.761 CST [26903] LOG: redo done at 0/8000028
2023-04-28 10:05:35.762 CST [26903] LOG: selected new timeline ID: 2
2023-04-28 10:05:35.882 CST [26903] LOG: archive recovery complete
2023-04-28 10:05:35.891 CST [26899] LOG: database system is ready to accept connections
此时数据目录中standby.signal
没有了。
修改备库配置文件,或者在命令行修改。
Primary_conninfo = 'host=abc07 port=5432 user=replicat_user password=bfd@dev24 application_name=s38'
修改主库配置文件,或者在命令行修改。
synchronous_commit=on
synchronous_standby_names='1 (s38)'
测试关闭备库,然后看主库提交等待情况:
一直卡住不提交。
从这点看,如果没有监控备库的状态就用同步,会对主库造成致命问题。
所以,要用ANY的策略,ANY能保证至少X个备库同步完成就行,并且尝试同步所有备库。
当仅有一个备库时,不做同步复制,太危险了
主库上的pg_stat_replication
记录了复制信息:
https://www.postgresql.org/docs/12/monitoring-stats.html
postgres=# \x Expanded display is on. postgres=# select * from pg_stat_replication; -[ RECORD 1 ]----+------------------------------ pid | 19189 usesysid | 16386 usename | replicat_user application_name | s38 client_addr | 192.168.0.38 client_hostname | client_port | 12214 backend_start | 2023-04-28 14:42:16.180019+08 backend_xmin | state | streaming sent_lsn | 0/B0004B8 write_lsn | 0/B0004B8 flush_lsn | 0/B0004B8 replay_lsn | 0/B0004B8 write_lag | flush_lag | replay_lag | sync_priority | 1 sync_state | sync reply_time | 2023-04-28 15:43:23.142803+08
sent_lsn:发送的WAL日志位置
write_lsn:standby写入到磁盘的WAL的位置。(写到缓冲)
flush_lsn:standby flush到磁盘的WAL的位置。(写到磁盘上)
replay_lsn:已经Apply的WAL的位置
write_lag:主库WAL本地化与standby romote_write(写到缓冲)之间的lag。(同步复制时才有)
flush_lag:主库WAL本地化与standby 写到磁盘之间的lag。(同步复制时才有)
replay_lag: 主库WAL本地化与standby apply之间的lag。(同步复制时才有)
sync_state:
备库的状态,如下:
async:该standy异步复制。不在synchronous_standby_names中的都是异步。
potential:该standy现在是异步复制,但是在同步的standby down的时候有可能成为同步的
sync:该standy同步复制
quorum:备选的standbys。意义不明
reply_time:上次发送的apply的时间
主备的pg_current_wal_lsn()记录了当前的WAL位置。
postgres=# select pg_current_wal_lsn();
pg_current_wal_lsn
--------------------
0/B0004B8
(1 row)
备库的pg_last_wal_receive_lsn()记录了接收位置 :
postgres=# select pg_last_wal_receive_lsn();
pg_last_wal_receive_lsn
-------------------------
0/B0004B8
(1 row)
备库的pg_stat_wal_receiver
显示复制信息:
postgres=# \x Expanded display is on. postgres=# select * from pg_stat_wal_receiver; -[ RECORD 1 ]---------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- pid | 21791 status | streaming receive_start_lsn | 0/B000000 receive_start_tli | 1 received_lsn | 0/B0004B8 received_tli | 1 last_msg_send_time | 2023-04-28 17:23:04.078542+08 last_msg_receipt_time | 2023-04-28 17:23:04.111514+08 latest_end_lsn | 0/B0004B8 latest_end_time | 2023-04-28 14:42:16.182656+08 slot_name | slot_01 sender_host | abc07 sender_port | 5432 conninfo | user=replicat_user password=******** dbname=replication host=abc07 port=5432 application_name=s38 fallback_application_name=walreceiver sslmode=disable sslcompression=0 gssencmode=disable krbsrvname=postgres target_session_attrs=any
通过主备的视图能比较准确的判断复制的延迟:
https://www.postgresql.org/docs/12/runtime-config-wal.html#GUC-FULL-PAGE-WRITES
select pid,usename,client_addr,state,
pg_wal_lsn_diff(pg_current_wal_lsn(),write_lsn) write_delay,
pg_wal_lsn_diff(pg_current_wal_lsn(),flush_lsn) flush_delay,
pg_wal_lsn_diff(pg_current_wal_lsn(),replay_lsn) replay_dely
from pg_stat_replication;
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。