Recovery 流复制

早在 PostgreSQL 9.1 推出的 pg_basebackup 工具，用来搭建流复制的备库。

主备环境：

PG SQL 版本：9.3
主库 IP： 192.168.1.36
备库 IP： 192.168.1.35

主库上操作

创建复制用户。

CREATE USER repuserREPLICATIONLOGINCONNECTION LIMIT 2ENCRYPTED PASSWORD 'rep123us345er';

设置 pg_hba.conf，添加以下：

host  replication   repuser     192.168.1.35/32     md5

设置主库 postgresql.conf

checkpoint_segments = 16
archive_mode = on
archive_command = '/bin/date'
max_wal_senders = 3
wal_keep_segments = 16
max_wal_senders = 3

重载配置文件

$ pg_ctl reload -D $PGDATA

postgres=# \dbList of tablespacesName   | Owner  |       Location
---------------+----------+-------------------------------------
pg_default  | postgres |
pg_global   | postgres |
tbs_francs  | postgres | /database/pg93/pg_tbs/tbs_francs
tbs_source_db | postgres | /database/pg93/pg_tbs/tbs_source_db
(4 rows)

$ echo $PGDATA
/database/pg93/pg_root

注：表空间目录和数据目录，因为这些目录需要在备库主机上手工创建。

备库上操作

$ mkdir -p /database/pg93/pg_tbs/tbs_francs
$ mkdir -p /database/pg93/pg_tbs/tbs_source_db
[root@redhat6 pgsql9.3beta1]# mkdir -p /database/pg93/pg_root$ chown -R pg93:pg93 /database/pg93/pg_tbs/tbs_francs
$ chown -R pg93:pg93 /database/pg93/pg_tbs/tbs_source_db
$ chown -R pg93:pg93 /database/pg93/pg_root
$ chmod 0700 /database/pg93/pg_root

创建 .pgpass

$ cat .pgpass
192.168.1.36:1925:replication:repuser:rep123us345er$ chmod 0600 .pgpass

使用 pg_basebackup 生成备库

$ pg_basebackup -D /database/pg93/pg_root -Fp -Xs -v -P -h 192.168.1.36 -p 1925 -U repusertransaction log start point: 1/1B000024 on timeline 1
pg_basebackup: starting background WAL receiver
651493/651493 kB (100%), 3/3 tablespaces
transaction log end point: 1/1B0000DC
pg_basebackup: waiting for background process to finish streaming ...
pg_basebackup: base backup completed

这时表空间目录，数据（$PGDATA）目录都复制过来了，这里使用了 -X 参数，在备份完成之后，会到主库上收集 pg_basebackup 执行期间产生的 WAL 日志，在 9.2 版本之后支持 -Xs 即 stream（流）形式，这种模式不需要收集主库的 WAL 文件，而能以 stream 复制方式直接同步主库。

设置备库 postgresql.conf

hot_standby = on

设置从库 recovery.conf

$ cp /opt/pgsql9.3beta1/share/recovery.conf.sample recovery.conf# vi recovery.conf
standby_mode = on
primary_conninfo = 'host=192.168.1.36 port=1925 user=repuser'
trigger_file = '/database/pg93/pg_root/postgresql.trigger.1925'

启动服务

$ pg_ctl start -D $PGDATA
server starting

查看备库进程

$ ps -ef | grep pg93
pg93   31398   1 0 21:09 pts/0  00:00:00 /opt/pgsql9.3beta1/bin/postgres -D /database/pg93/pg_root
pg93   31399 31398 0 21:09 ?    00:00:00 postgres: logger process
pg93   31400 31398 0 21:09 ?    00:00:00 postgres: startup process  waiting for 00000001000000010000001A
pg93   31401 31398 0 21:09 ?    00:00:00 postgres: checkpointer process
pg93   31402 31398 0 21:09 ?    00:00:00 postgres: writer process
pg93   31403 31398 0 21:09 ?    00:00:00 postgres: stats collector process
pg93   31404 31398 0 21:09 ?    00:00:00 postgres: wal receiver process

查看主库进程

$ ps -ef | grep pg93
pg93   2504   1 0 Jun28 ?    00:00:26 /opt/pgsql9.3beta1/bin/postgres -D /database/pg93/pg_root
pg93   2505 2504 0 Jun28 ?    00:00:00 postgres: logger process
pg93   2507 2504 0 Jun28 ?    00:00:08 postgres: checkpointer process
pg93   2508 2504 0 Jun28 ?    00:00:28 postgres: writer process
pg93   2509 2504 0 Jun28 ?    00:00:08 postgres: wal writer process
pg93   2510 2504 0 Jun28 ?    00:00:19 postgres: autovacuum launcher process
pg93   2511 2504 0 Jun28 ?    00:00:00 postgres: archiver process  last was 000000010000000100000019.00000024.backup
pg93   2512 2504 0 Jun28 ?    00:00:44 postgres: stats collector process
pg93   31898 2504 0 21:09 ?    00:00:00 postgres: wal sender process repuser 192.168.1.35(39545) idle

功能测试

主库

$ psql
psql (9.3beta1)
Type "help" for help.postgres=# create table test_1 (id int4,create_time timestamp(0) without time zone);
CREATE TABLEpostgres=# insert into test_1 values (1,now());
INSERT 0 1postgres=# select * from test_1;
id |   create_time
----+---------------------1 | 2013-07-01 21:15:34
(1 row)

备库

$ psql
psql (9.3beta1)
Type "help" for help.postgres=# select * from test_1 ;
id |   create_time
----+---------------------1 | 2013-07-01 21:15:34
(1 row)

相关配置参数

归档恢复

restore_command (string)：获取 WAL 文件的一个已归档段的 Shell 指令。这个参数是归档恢复所必需的，但是对于流复制是可选的。

restore_command = 'cp /mnt/server/archivedir/%f "%p"'

archive_cleanup_command (string)：清除不再被备份服务器需要的旧的已归档 WAL 文件。%r 会被替换为包含最后一个可用重启点的文件的名称。因此比 %r 更早的所有文件可以被安全地移除。

archive_cleanup_command = 'pg_archivecleanup /mnt/server/archivedir %r'

recovery_end_command (string)：归档恢复结束后执行的指令。目的是为复制或恢复之后的清除提供一种机制。与 archive_cleanup_command 相似，任何 %r 会被替换为包含最后一个可用重启点的文件的名称。

恢复目标

默认情况下，恢复会一直恢复到 WAL 日志的末尾。在 recovery_target、recovery_target_lsn、recovery_target_name、recovery_target_time 和 recovery_target_xid 中，最多只能使用一个，如果在配置文件中使用了多个，将使用最后一个。

recovery_target = ‘immediate’：指定恢复应该在达到一致状态后尽快结束。在从一个在线备份中恢复时，这意味着备份结束的那个点。
recovery_target_name (string)：指定 pg_create_restore_point() 所创建的已命名的恢复点，进行恢复。
recovery_target_time (timestamp)：指定按时间戳恢复。
recovery_target_xid (string)：指定按事务 ID 进行恢复。
recovery_target_lsn (pg_lsn)：指定按继续进行的预写日志位置的 LSN 进行恢复。
recovery_target_inclusive (boolean)：指定是否仅在指定的恢复目标之后停止（true），或者仅在恢复目标之前停止（false）。适用于 recovery_target_lsn、recovery_target_time 或者 recovery_target_xid被指定的情况。这个设置分别控制事务是否有准确的目标 WAL 位置（LAN）、提交时间或事务 ID 将被包括在该恢复中。默认值为 true。
recovery_target_timeline (string)：指定恢复到一个特定的时间线中。默认值是沿着基础备份建立时的当前时间线恢复。将这个参数设置为 latest 会恢复到该归档中能找到的最新的时间线。
recovery_target_action (enum)：指定在达到恢复目标时服务器应该立刻采取的动作，包括 pause（暂停）、promote（接受连接）、shutdown（停止服务器），其中 pause 为默认动作。

备份服务器

standby_mode (boolean)：on 表示作为一个备库，否则作为主库。为 on 时，当到达已归档 WAL 末尾时该服务器将不会停止恢复，但是将通过使用r estore_command 获得新的 WAL 段以及/或者通过使用 primary_conninfo 设置连接到主服务器来尝试继续恢复。
primary_conninfo (string)：指定备库用来连接主库的连接字符串。
primary_slot_name (string)：有选择地指定通过流复制连接到主库时，使用一个现有的复制槽来控制上游节点上的资源移除。如果没有设置 primary_conninfo 则这个设置无效。
promote_trigger_file (string)：指定一个触发器文件，如果该文件存在，则会结束备库中的恢复，即升级备库为一个独立的主库。即使这个值没有被设置，你也可以通过 pg_ctl promote 来提升备库。如果 standby_mode 为 off，那么这个设置没有效果。
recovery_min_apply_delay (integer)：允许你将恢复延迟一段固定的时间，如果没有指定单位则以毫秒为单位。例如，如果你设置这个参数为 5min，对于一个事务提交，只有当备库上的系统时钟超过主库报告的提交时间至少 5 分钟时，备库才会重放该事务。

注意：当 synchronous_commit 被设置为 remote_apply 时，同步复制会受到这个设置的影响，每一个 COMMIT 都需要等待被应用。

PostgreSQL 12 的 Recovery

PostgreSQL 12 的一个重要变化就是将 Recovery.conf 文件参数合并到了 postgresql.conf。之前版本 PostgreSQL 的流复制备库是通过在 $PGDATA 目录中创建 recovery.conf 文件来标识的，这是流复制部署的重要文件，若 $PGDATA 目录下不存在此文件，数据库无法以流复制备库角色启动。PostgreSQL 12 之后 recovery.conf 不再使用，若 recovery.conf 文件存在，数据库将无法启动。

此外，还：

新增 recovery.signal 标识文件，表示数据库处于 recovery 模式。
新增加 standby.signal 标识文件，表示数据库处于 standby 模式。
trigger_file 参数更名为 promote_trigger_file。
standby_mode 参数不再支持。

pg_basebackup 命令差异

12 版本pg_basebackup 命令的 -R 参数的效果和之前不同，主要体现在:

命令执行后在 $PGDATA 目录创建 standby.signal 标识文件，文件内容为空。
命令执行后在 $PGDATA 目录的 postgresql.auto.conf 文件中添加 primary_conninfo 参数信息。

PostgreSQL — 基于 Recovery 流复制的数据备份相关推荐

基于TCP流协议的数据包通讯
Fanxiushu 2016-02-04,引用或转载请注明原始作者. TCP通讯是流协议,它不像UDP那样基于包为边界的通讯方式, TCP流式协议,举个简单例子,一端用send 分别发送 100, ...
PostgreSQL命令恢复dmp类型的数据备份
1.用管理员身份打开cmd黑窗,并进入到PostgreSQL的bin目录下 2.输入 pg_restore.恢复数据库的命令 pg_restore.exe --host "localhost ...
postgresql双机热备份之流复制
PostgreSQL日志传送的方法有两种,一种是基于文件(base-file)的传送方式,一种是流复制(streamingreplication)的方式. 基于文件(base-file)的传送方式,这 ...
pitr 原理_PostgreSQL热备原理研究及流复制运用
付莎摘要:高可用性(HA-High Availability)是所有商用数据库系统必须具备的一项基本功能.该文阐述了PostgreSQL数据库的高可用性的实现原理及方法,并对PostgreSQL数据 ...
PostgreSQL13主从同步异步流复制
PostgreSQL13主从同步异步流复制介绍 PostgreSQL早在9.0版本开始支持物理复制,也可称为流复制( Streaming Replication,通过流复制技术,可以从实例级复制出一 ...
数据库周刊28│开发者最喜爱的数据库是什么？阿里云脱口秀聊程序员转型；MySQL update误操作；PG流复制踩坑；PG异机归档；MySQL架构选型；Oracle技能表……
文章来源:墨天轮社区 https://www.modb.pro/db/26343 摘要:墨天轮数据库周刊第28期发布啦,每周1次推送本周数据库相关热门资讯.精选文章.干货文档.本周分享开发者最喜爱的 ...
pgpool mysql_PGPool-II+PG流复制实现HA主备切换
基于PG的流复制能实现热备切换,但是是要手动建立触发文件实现,对于一些HA场景来说,需要当主机down了后,备机自动切换,经查询资料知道pgpool-II可以实现这种功能.本文基于PG流复制基础上 , ...
PGPool-II+PG流复制实现HA主备切换
基于PG的流复制能实现热备切换,但是是要手动建立触发文件实现,对于一些HA场景来说,需要当主机down了后,备机自动切换,经查询资料知道pgpool-II可以实现这种功能.本文基于PG流复制基础上 , ...
postgresql主从备份_基于PG12.2实现主从异步流复制及主从切换教程（下）
概述今天主要介绍如何搭建PG主从流复制及主从切换,仅供参考. PS:上篇的地址在文末链接. PostgreSQL数据库主从异步流复制搭建环境说明: 1.安装PG数据库(主从库进行) 用脚本进行,略 ...

PostgreSQL — 基于 Recovery 流复制的数据备份

目录

文章目录