5、恢复
此节介绍常用的恢复命令。
5.1 delta恢复
在快速启动中恢复数据库，需要在还原数据库之前首先清空数据库实例的数据文件。Delta选项允许PgBackRest自动确定数据库集群目录中的哪些文件可以被保存，哪些文件需要从备份中恢复——它还移除了那些备份清单中没有的文件，因此它将处理不同的变化。这是通过计算数据库集群目录中的每个文件的SHA-1加密散列来实现的。如果文件的SHA-1散列与备份中存储的散列不匹配，则该文件将被还原。这个过程结合process-max选项使用是非常有效的。由于在恢复期间，服务器被关闭，所以恢复过程中可以使用的进程数量比运行服务器时备份可使用的进程数量要更多。db-master ⇒ 停止演示数据库，进行delta恢复。
$ sudo pg_ctlcluster 9.4 demo stop $ sudo -u postgres pgbackrest --stanza=demo --delta --log-level-console=detail restore [filtered 692 lines of output] P01 DETAIL: restore file var/lib/postgresql/9.4/demo/base/12134/PG_VERSION - exists and matches backup (4B, 99%) checksum 8dbabb96e032b8d9f1993c0e4b9141e71ade01a1 P01 DETAIL: restore file var/lib/postgresql/9.4/demo/base/1/PG_VERSION - exists and matches backup (4B, 99%) checksum 8dbabb96e032b8d9f1993c0e4b9141e71ade01a1 P01 DETAIL: restore file var/lib/postgresql/9.4/demo/PG_VERSION - exists and matches backup (4B, 100%) checksum 8dbabb96e032b8d9f1993c0e4b9141e71ade01a1 P01 DETAIL: restore file var/lib/postgresql/9.4/demo/global/12086 - exists and is zero size (0B, 100%) P01 DETAIL: restore file var/lib/postgresql/9.4/demo/global/12038 - exists and is zero size (0B, 100%) [filtered 83 lines of output] P01 DETAIL: restore file var/lib/postgresql/9.4/demo/base/1/11885 - exists and is zero size (0B, 100%) P00 INFO: write var/lib/postgresql/9.4/demo/recovery.conf P00 INFO: restore global/pg_control (performed last to ensure aborted restores cannot be started) P00 INFO: restore command end: completed successfully复制
db-master ⇒ 重启PostgreSQL实例
$ sudo pg_ctlcluster 9.4 demo start复制
5.2 恢复指定的数据库
在某些情况下，有选择地从集群备份还原特定数据库是可能发生的。可能的原因如出于性能的考虑或者要将选定的数据库移动到一个没有足够磁盘空间存储整个数据库备份的机器。为了演示这一特性，我们创建了两个数据库：test1和test2。运行一个新的备份让pgBackRest获取最新的实例结构。
db-master ⇒ 创建两个测试库并且执行备份操作
$ sudo -u postgres psql -c "create database test1;" CREATE DATABASE $ sudo -u postgres psql -c "create database test2;" CREATE DATABASE $ sudo -u postgres pgbackrest --stanza=demo --type=incr backup复制
每一个测试数据库都会被创建表并且向表中插入数据，以证明恢复过程中恢复了指定的数据库。
db-master ⇒ 在每一个测试数据库中间一个测试表。
$ sudo -u postgres psql -c "create table test1_table (id int); \ insert into test1_table (id) values (1);" test1 INSERT 0 1 $ sudo -u postgres psql -c "create table test1_table (id int); \ insert into test1_table (id) values (1);" test2 INSERT 0 1复制
选择性还原数据库的主要原因之一是节省空间。这里显示了test1数据库的大小，因此可以在恢复后与磁盘利用率进行比较。db-master ⇒ 显示数据库test1的空间使用
$ sudo -u postgres du -sh var/lib/postgresql/9.4/demo/base/16384 6.4M /var/lib/postgresql/9.4/demo/base/16384复制
停止数据库实例进程并且只恢复test2数据库。另外，内置的模板数据库template0、template1和Postgres总是会被恢复的。db-master ⇒ 从上次备份中只恢复test2数据库。
$ sudo pg_ctlcluster 9.4 demo stop $ sudo -u postgres pgbackrest --stanza=demo --delta --db-include=test2 restore $ sudo pg_ctlcluster 9.4 demo start复制
一旦恢复完成，在数据库将包含test2所有以前创建的表和数据。db-master ⇒证明是数据库已被恢复。
$ sudo -u postgres psql -c "select * from test2_table;" test2 id ---- 2 (1 row)复制
尽管test1数据库也被恢复了，但是他无法被访问。这是因为整个数据库被还原为稀疏的、锁定的文件。PostgreSQL可以成功地将WAL文件应用到目标集中的文件中，但是由于关键文件不包含数据，所以整个数据库将无效。这个为了防止意外使用包含重放期间的数据的WAL文件。db-master ⇒ 尝试连接数据库test1会产生错误
$ sudo -u postgres psql -c "select * from test1_table;" test1 psql: FATAL: relation mapping file "base/16384/pg_filenode.map" contains invalid data复制
由于在数据库test1是用稀疏的、锁定的文件恢复的，因此它只需要与在恢复期间写入的WAL中的的数量一样多的空间。虽然在备份期间生成并在恢复期间应用的WAL文件数量很大，但它通常只占数据库总数的一小部分，尤其是对于大型数据库，在这些数据库中，该特性最有可能是有用的。很显然，恢复指定的test1数据库所用的磁盘空间远小于恢复整个数据库实例。db-master ⇒显示恢复后的数据库test1使用的空间
$ sudo -u postgres du -sh var/lib/postgresql/9.4/demo/base/16384 152K /var/lib/postgresql/9.4/demo/base/16384复制
此时能够对test1数据库有效的操作就是drop database，pgBackRest不会自动删除数据库，因为在恢复完成和群集可访问之前，无法执行删库操作。
db-master ⇒ 删除test1数据库
$ sudo -u postgres psql -c "drop database test1;" DROP DATABASE复制
现在，已经删除了无效的test1数据库，只有在和内置数据库仍然存在。db-master ⇒ 列出剩余的数据库列表
$ sudo -u postgres psql -c "select oid, datname from pg_database order by oid;" oid | datname -------+----------- 1 | template1 12134 | template0 12139 | postgres 16385 | test2 (4 rows)复制
5.3 基于时间点恢复
在快速启动中恢复数据库执行默认恢复，这将一直执行到WAL流的尾部。在硬件故障的情况下，这通常是最好的选择，但是对于数据误删除等场景，PITR是更合适的方法。基于时间点恢复数据库（PITR）允许WAL从上次备份中回放到指定的时间、事务id或恢复点。对于常见的恢复方案来说，基于时间的恢复是最有用的。典型的恢复场景是还原意外删除的表或意外删除的数据。恢复一个已删除的表是更有代表性的，所以这是这里给出这样的例子，删除数据的恢复将以完全相同的操作进行。db-master ⇒ 备份演示数据库后创建一张存放重要数据的表
$ sudo -u postgres pgbackrest --stanza=demo --type=diff backup $ sudo -u postgres psql -c "begin; \ create table important_table (message text); \ insert into important_table values ('Important Data'); \ commit; \ select * from important_table;" message ---------------- Important Data (1 row)复制
查看由PostgreSQL计算的时间（包括时区偏移）是非常重要的一个步骤，这主要是为了减少由于时区差异而到导致的恢复结果意外的现象。db-master ⇒ 从数据库中获取时间
$ sudo -u postgres psql -Atc "select current_timestamp" 2017-09-03 21:36:03.665349+00复制
现在已经记录了时间，表可以被删除了。在实际生产中，找出表被删除的确切时间可能要比在这个示例中要困难得多。但是通过一些取证，可以让这个时间更加接近确切的时间。db-master ⇒ 删除表
$ sudo -u postgres psql -c "begin; \ drop table important_table; \ commit; \ select * from important_table;" ERROR: relation "important_table" does not exist LINE 1: ...le important_table; commit; select * from important_...复制
现在可以使用PITR的方式去恢复缺少的表。db-master ⇒ 停止数据库实例，恢复测试库到2017-09-03 21:36:03.665349+00时间点，查看recovery.conf文件。
$ sudo pg_ctlcluster 9.4 demo stop $ sudo -u postgres pgbackrest --stanza=demo --delta \ --type=time "--target=2017-09-03 21:36:03.665349+00" restore $ sudo -u postgres cat var/lib/postgresql/9.4/demo/recovery.conf restore_command = '/usr/bin/pgbackrest --stanza=demo archive-get %f "%p"' recovery_target_time = '2017-09-03 21:36:03.665349+00'复制
recovery.conf文件是由pgBackRest自动生成的，因此可以立即启动PostgreSQL。一旦PostgreSQL完成恢复，该表将再次存在，并且可以被查询。db-master ⇒ 启动数据库检查包含重要数据的表是否存在。
$ sudo pg_ctlcluster 9.4 demo start $ sudo -u postgres psql -c "select * from important_table" message ---------------- Important Data (1 row)复制
在日志还包含有价值的信息。它将指出恢复停止的时间和事务，并给出最后一个事务被应用的时间。db-master ⇒ 解释PostgreSQL日志输出
$ sudo -u postgres cat var/log/postgresql/postgresql-9.4-demo.log LOG: database system was interrupted; last known up at 2017-09-03 21:35:58 UTC LOG: starting point-in-time recovery to 2017-09-03 21:36:03.665349+00 LOG: restored log file "00000004.history" from archive LOG: restored log file "000000040000000000000017" from archive [filtered 2 lines of output] LOG: incomplete startup packet LOG: restored log file "000000040000000000000018" from archive LOG: recovery stopping before commit of transaction 686, time 2017-09-03 21:36:03.82082+00 LOG: redo done at 0/180157F0 LOG: last completed transaction was at log time 2017-09-03 21:36:03.503484+00 LOG: selected new timeline ID: 5 LOG: restored log file "00000004.history" from archive [filtered 4 lines of output]复制
这个示例得到了理想的结果，但是如果选择了在所需时间之后的备份，那么，PostgreSQL将无法恢复丢失的表。PostgreSQL只能前进，而不是后退。为了证明这一点，必须删除重要的表(再次)。
db-master ⇒ 再次删除重要的表
$ sudo -u postgres psql -c "begin; \ drop table important_table; \ commit; \ select * from important_table;" ERROR: relation "important_table" does not exist LINE 1: ...le important_table; commit; select * from important_...复制
现在做一次备份，然后尝试从备份中恢复
$ sudo -u postgres pgbackrest --stanza=demo --type=incr backup $ sudo pg_ctlcluster 9.4 demo stop $ sudo -u postgres pgbackrest --stanza=demo --delta \ --type=time "--target=2017-09-03 21:36:03.665349+00" restore $ sudo pg_ctlcluster 9.4 demo start $ sudo -u postgres psql -c "select * from important_table" ERROR: relation "important_table" does not exist LINE 1: select * from important_table复制
查看日志输出，表是否恢复是不明显的。关键是在日志中查找” recovery stopping before…”和“last completed transaction…”日志信息。如果它们不存在，则表明恢复到指定的时间点是不成功的。db-master ⇒ 查看日志输出确认恢复是否成功
$ sudo -u postgres cat var/log/postgresql/postgresql-9.4-demo.log LOG: database system was interrupted; last known up at 2017-09-03 21:36:12 UTC LOG: starting point-in-time recovery to 2017-09-03 21:36:03.665349+00 LOG: restored log file "00000005.history" from archive LOG: restored log file "000000050000000000000019" from archive LOG: redo starts at 0/19000028 LOG: consistent recovery state reached at 0/190000F0 LOG: redo done at 0/190000F0 LOG: incomplete startup packet [filtered 10 lines of output]复制
使用一个更早的备份允许PostgreSQL向前恢复到正确的时间。Info命令可以用来查找下一个备份。db-master ⇒ 获取演示实例的备份信息
$ sudo -u postgres pgbackrest info stanza: demo status: ok db (current) wal archive min/max (9.4-1): 00000002000000000000000A 000000050000000000000019 full backup: 20170903-213504F timestamp start/stop: 2017-09-03 21:35:04 2017-09-03 21:35:09 wal start/stop: 00000002000000000000000A 00000002000000000000000A database size: 19.3MB, backup size: 19.3MB repository size: 2.2MB, repository backup size: 2.2MB full backup: 20170903-213510F timestamp start/stop: 2017-09-03 21:35:10 2017-09-03 21:35:15 wal start/stop: 00000002000000000000000B 00000002000000000000000B database size: 19.3MB, backup size: 19.3MB repository size: 2.2MB, repository backup size: 2.2MB diff backup: 20170903-213510F_20170903-213530D timestamp start/stop: 2017-09-03 21:35:30 2017-09-03 21:35:33 wal start/stop: 000000020000000000000012 000000020000000000000012 database size: 19.3MB, backup size: 8.2KB repository size: 2.2MB, repository backup size: 347B backup reference list: 20170903-213510F incr backup: 20170903-213510F_20170903-213542I timestamp start/stop: 2017-09-03 21:35:42 2017-09-03 21:35:47 wal start/stop: 000000030000000000000014 000000030000000000000014 database size: 31.8MB, backup size: 12.7MB repository size: 3.7MB, repository backup size: 1.5MB backup reference list: 20170903-213510F diff backup: 20170903-213510F_20170903-213557D timestamp start/stop: 2017-09-03 21:35:57 2017-09-03 21:36:02 wal start/stop: 000000040000000000000017 000000040000000000000017 database size: 25.7MB, backup size: 6.5MB repository size: 3MB, repository backup size: 793.5KB backup reference list: 20170903-213510F incr backup: 20170903-213510F_20170903-213611I timestamp start/stop: 2017-09-03 21:36:11 2017-09-03 21:36:14 wal start/stop: 000000050000000000000019 000000050000000000000019 database size: 25.6MB, backup size: 1.9MB repository size: 3MB, repository backup size: 215.3KB backup reference list: 20170903-213510F, 20170903-213510F_20170903-213557D复制
恢复的默认行为是使用最后一个备份，但可以使用-set选项指定较早的备份。db-master ⇒ 停用PostgreSQL，从选定的备份恢复数据，启动数据库
$ sudo pg_ctlcluster 9.4 demo stop $ sudo -u postgres pgbackrest --stanza=demo --delta \ --type=time "--target=2017-09-03 21:36:03.665349+00" \ --set=20170903-213510F_20170903-213557D restore $ sudo pg_ctlcluster 9.4 demo start $ sudo -u postgres psql -c "select * from important_table" message ---------------- Important Data (1 row)复制
现在，日志输出将包含” recovery stopping before”和” last completed transaction”信息显示恢复成功。db-master ⇒ 查看日志输出，查找恢复成功信息
$ sudo -u postgres cat var/log/postgresql/postgresql-9.4-demo.log LOG: database system was interrupted; last known up at 2017-09-03 21:35:58 UTC LOG: starting point-in-time recovery to 2017-09-03 21:36:03.665349+00 LOG: restored log file "00000004.history" from archive LOG: restored log file "000000040000000000000017" from archive [filtered 2 lines of output] LOG: incomplete startup packet LOG: restored log file "000000040000000000000018" from archive LOG: recovery stopping before commit of transaction 686, time 2017-09-03 21:36:03.82082+00 LOG: redo done at 0/180157F0 LOG: last completed transaction was at log time 2017-09-03 21:36:03.503484+00 LOG: restored log file "00000005.history" from archive LOG: restored log file "00000006.history" from archive [filtered 7 lines of output]复制
5.4 对S3的支持
pgBackRest支持存储在S3中。db-primary:/etc/pgbackrest.conf ⇒ 配置S3
[demo] db-path=/var/lib/postgresql/9.4/demo [global] process-max=4 repo-path=/ repo-s3-bucket=demo-bucket repo-s3-endpoint=s3.amazonaws.com repo-s3-key=accessKey1 repo-s3-key-secret=verySecretKey1 repo-s3-region=us-east-1 repo-type=s3 retention-diff=2 retention-full=2 start-fast=y stop-auto=y复制
存储文件存储在S3上和存储在本地一样，命令都可以正常运行db-primary ⇒ 创建stanza
$ sudo -u postgres pgbackrest --stanza=demo --log-level-console=info stanza-create P00 INFO: stanza-create command begin 1.23: --db1-path=/var/lib/postgresql/9.4/demo --log-level-console=info --no-log-timestamp --repo-path=/ --repo-s3-bucket=demo-bucket --repo-s3-endpoint=s3.amazonaws.com --repo-s3-region=us-east-1 --no-repo-s3-verify-ssl --repo-type=s3 --stanza=demo P00 INFO: stanza-create command end: completed successfully复制
在S3上创建文件相对时间较慢，因此可以增加参数process-max并行创建文件来增加创建文件速度。db-primary ⇒ 备份演示实例
$ sudo -u postgres pgbackrest --stanza=demo \ --log-level-console=info backup P00 INFO: backup command begin 1.23: --db1-path=/var/lib/postgresql/9.4/demo --log-level-console=info --log-level-stderr=off --no-log-timestamp --process-max=4 --repo-path=/ --repo-s3-bucket=demo-bucket --repo-s3-endpoint=s3.amazonaws.com --repo-s3-region=us-east-1 --no-repo-s3-verify-ssl --repo-type=s3 --retention-diff=2 --retention-full=2 --stanza=demo --start-fast --stop-auto P00 WARN: no prior backup exists, incr backup has been changed to full P00 INFO: execute exclusive pg_start_backup() with label "pgBackRest backup started at 2017-09-13 11:50:24": backup begins after the requested immediate checkpoint completes P00 INFO: backup start archive = 000000070000000000000019, lsn = 0/19000028 [filtered 995 lines of output] P02 INFO: backup file var/lib/postgresql/9.4/demo/base/1/11895 (0B, 100%) P01 INFO: backup file /var/lib/postgresql/9.4/demo/base/1/11885 (0B, 100%) P00 INFO: full backup size = 25.5MB P00 INFO: execute exclusive pg_stop_backup() and wait for all WAL segments to archive P00 INFO: backup stop archive = 000000070000000000000019, lsn = 0/19000128 [filtered 4 lines of output]复制
6、专用备份主机
在快速启动章节中描述的配置适合于简单的安装，但是对于企业级的配置，更常用的是拥有一个专用备份主机。这种方案将备份和WAL归档的服务器和数据库的服务器分隔开，因此数据库主机故障对备份集产生的影响更小。然而，使用传统的备份软件备份backup主机仍然是个好主意。
6.1 安装
创建了一个名为backup的新主机来存储集群备份。
创建backrest存储库的拥有者backrest用户。任何用户都可以拥有该backrest存储库，但最好不要使用Postgres(如果存在)，以避免混乱。
backup ⇒ 创建backrest存储库
$ sudo adduser --disabled-password --gecos "" backrest复制
1)安装依赖包（root用户）:
yum install perl-Time-HiRes –y yum install perl-Digest* -y yum install perl-JSON -y yum install perl-parent* -y yum install perl-DBD-Pg –y复制
2)解压:
unzip pgbackrest-release-1-integration.zip复制
3)移除pgBackRest工具先前安装的版本(root用户):
rm -f /usr/bin/pgbackrest rm -f /usr/bin/pg_backrest rm -rf /usr/lib/perl5/BackRest rm -rf /usr/share/perl5/BackRest rm -rf /usr/lib/perl5/pgBackRest rm -rf /usr/share/perl5/pgBackRest复制
4)安装pgBackRest(root用户):
cp -r /home/postgres/pgbackrest-release-1-integration/lib/pgBackRest /usr/share/perl5 find /usr/share/perl5/pgBackRest -type f -exec chmod 644 {} + find /usr/share/perl5/pgBackRest -type d -exec chmod 755 {} + cp /home/postgres/pgbackrest-release-1-integration/bin/pgbackrest /usr/bin/pgbackrest chmod 755 /usr/bin/pgbackrest mkdir -m 770 /var/log/pgbackrest chown postgres:postgres /var/log/pgbackrest touch /etc/pgbackrest.conf chmod 640 /etc/pgbackrest.conf chown postgres:postgres /etc/pgbackrest.conf复制
5)确保工具安装生效:
[postgres@db4 pgbackrest-release-1-integration]$ pgbackrest pgBackRest 1.27 - General helpUsage: pgbackrest [options] [command] Commands: archive-get Get a WAL segment from the archive. archive-push Push a WAL segment to the archive. backup Backup a database cluster. check Check the configuration. expire Expire backups that exceed retention. help Get help. info Retrieve information about backups. restore Restore a database cluster. stanza-create Create the required stanza data. stanza-upgrade Upgrade a stanza. start Allow pgBackRest processes to run. stop Stop pgBackRest processes from running. version Get version. Use 'pgbackrest help [command]' for more information.复制
6.2 安装受信任的ssh工具
pgBackRest需要可信(无密码)的ssh来启用主机之间的通信。
backup ⇒ 创建backup主机的密钥
$ sudo -u backrest mkdir -m 750 /home/backrest/.ssh $ sudo -u backrest ssh-keygen -f /home/backrest/.ssh/id_rsa -t rsa -b 4096 -N ""复制
db-primary ⇒ 创建db-primary 主机的密钥
$ sudo -u postgres mkdir -m 750 -p /home/postgres/.ssh $ sudo -u postgres ssh-keygen -f /home/postgres/.ssh/id_rsa -t rsa -b 4096 -N ""复制
在backup和db-primary主机之间交换密码对
backup ⇒ 拷贝db-primary主机的公钥到backup主机
$ sudo ssh root@db-primary cat /home/postgres/.ssh/id_rsa.pub | \ sudo -u backrest tee -a /home/backrest/.ssh/authorized_keys复制
db-primary ⇒ 拷贝backup主机的公钥到db- primary主机
$ sudo ssh root@backup cat /home/backrest/.ssh/id_rsa.pub | \ sudo -u postgres tee -a /home/postgres/.ssh/authorized_keys复制
测试是否可以通过db-primary连接到backup以及是否可以通过backup连接到db-primary。
backup⇒测试从backup主机是否可以连接到db-primary
$ sudo -u backrest ssh postgres@db-primary复制
db-primary ⇒ 测试从db-primary主机是否可以连接到backup
$ sudo -u postgres ssh backrest@backup复制
6.3 配置
Backup主机必须要配置db-primary主机名、用户以及数据库路径。数据库将被配置成db1以便备份机添加。
backup:/etc/pgbackrest.conf ⇒ 配置db1-host/db1-user和db1-path
[demo] db1-host=db-primary db1-path=/var/lib/postgresql/9.4/demo db1-user=postgres [global] repo-path=/var/lib/pgbackrest retention-full=2 start-fast=y复制
数据库主机必须配置备份主机和备份用户。默认backup-user配置为backrest。如果postgres用户没有在backup主机上进行还原，那么最好也不要使用postgres用户进行备份。如果postgres用户和backrest用户在同一个用户组，那么他有读权限。
db-primary:/etc/pgbackrest.conf ⇒ 配置backup-host/backup-user
[demo] db-path=/var/lib/postgresql/9.4/demo [global] backup-host=backup backup-user=backrest log-level-file=detail复制
存储库目录也将从数据库主机中删除。因为他不会再被使用，所以保留它会让人迷惑。
db-primary ⇒从数据库主机中移除存储库，因为他将存在于backup主机上
$ sudo find /var/lib/pgbackrest -delete复制
命令的运行方式与单一主机配置相同，只是有些命令(如backup和expire)是从备份主机而不是数据库主机运行的。
创建一个新的存储目录
backup ⇒ 创建stanza
$ sudo -u backrest pgbackrest --stanza=demo stanza-create复制
检查数据库和备份主机上的配置是否正确。更多检查配置的命令在章节检查配置中查找
db-primary ⇒ 检查配置
$ sudo -u postgres pgbackrest --stanza=demo check复制
backup ⇒ 检查配置
$ sudo -u backrest pgbackrest --stanza=demo check复制
6.4 执行备份
若要执行对群集的备份，请使用backup主机上的backup命令运行pgBackRest。
backup ⇒ 备份演示用实例
$ sudo -u backrest pgbackrest --stanza=demo backup P00 WARN: no prior backup exists, incr backup has been changed to full复制
由于在backup主机上创建了一个新的存储库，因此发出了关于增量备份更改为完全备份的警告。
6.5 恢复备份
若要执行对在群集的还原，请使用database主机上的restore命令运行pgBackRest。
db-primary ⇒ 停止演示用实例，恢复，重启数据库实例
$ sudo pg_ctlcluster 9.4 demo stop $ sudo -u postgres pgbackrest --stanza=demo --delta restore $ sudo pg_ctlcluster 9.4 demo start复制
由于时间线切换，必须执行新的备份。
backup ⇒ 备份演示集群
$ sudo -u backrest pgbackrest --stanza=demo backup复制
6.6 异步归档
archive-async选项卸载WAL归档进程到单独的一个进程或多个进程，用以提高吞吐量。它的工作原理是通过向前看哪些WAL段已经准备好归档，而不是通过PostgreSQL的archive_command配置项。WAL段文件会被直接从pg_xlog/pg_wal目录转移到归档目录，只有在WAL段成功存储到归档目录后才会返回成功。
创建spool目录保存当前WAL归档的状态。写入在spool目录中的状态文件通常是零长度的，应该消耗最少的空间(最多只需要几个MB)，并且很少使用IO。此目录中的所有信息都可以重新创建，因此如果集群移到新的硬件上，不必保留在目录。
注意：在原始的异步归档实现中，在压缩和传输之前就将wal文件复制到spool目录。新方式从pg_xlog目录复制WAL文件。如果在v1.12或之前版本执行异步归档。在升级之前请仔细阅读v1.13发行说明。
db-primary ⇒ 创建spool目录
$ sudo mkdir -m 750 /var/spool/pgbackrest $ sudo chown postgres:postgres /var/spool/pgbackrest复制
在配置文件中必须说明spool目录的路径并且打开异步归档开关。异步归档通过减少对备份服务器的ssh连接数量自动提供一些好处，但是设置增大process-max可以极大地提升性能。但是需要确保不要将进程数设置太大以免影响正常的数据库操作。
db-primary:/etc/pgbackrest.conf ⇒ 配置异步备份和spool文件路径
[demo] db-path=/var/lib/postgresql/9.4/demo [global] archive-async=y backup-host=backup backup-user=backrest log-level-file=detail spool-path=/var/spool/pgbackrest [global:archive-push] process-max=2复制
archive-async.log文件能够被用来监控活跃的异步归档进程。验证这个的最好方式是产生一些WAL段。
db-primary ⇒ 测试并行异步备份
$ sudo -u postgres psql -c " \ select pg_create_restore_point('test async push'); select pg_switch_xlog(); \ select pg_create_restore_point('test async push'); select pg_switch_xlog(); \ select pg_create_restore_point('test async push'); select pg_switch_xlog(); \ select pg_create_restore_point('test async push'); select pg_switch_xlog(); \ select pg_create_restore_point('test async push'); select pg_switch_xlog();" $ sudo -u postgres pgbackrest --stanza=demo --log-level-console=info check P00 INFO: check command begin 1.23: --backup-host=backup --backup-user=backrest --db1-path=/var/lib/postgresql/9.4/demo --log-level-console=info --log-level-file=detail --log-level-stderr=off --no-log-timestamp --stanza=demo P00 INFO: WAL segment 000000080000000000000025 successfully stored in the archive at '/var/lib/pgbackrest/archive/demo/9.4-1/0000000800000000/000000080000000000000025-00344bcabf5ed6a9f171634d7876184bb0da2cef.gz' P00 INFO: check command end: completed successfully复制
现在，日志文件中将会包含并行、异步备份的信息。
db-primary ⇒ 检查日志结果
$ sudo -u postgres cat /var/log/pgbackrest/demo-archive-async.log -------------------PROCESS START------------------- P00 INFO: archive-push command begin 1.23: --archive-async --backup-host=backup --backup-user=backrest --db1-path=/var/lib/postgresql/9.4/demo --log-level-file=detail --log-level-stderr=off --no-log-timestamp --process-max=2 --spool-path=/var/spool/pgbackrest --stanza=demo P00 INFO: push 3 WAL file(s) to archive: 000000080000000000000020...000000080000000000000022 P02 DETAIL: pushed WAL file 000000080000000000000021 to archive P01 DETAIL: pushed WAL file 000000080000000000000020 to archive P02 DETAIL: pushed WAL file 000000080000000000000022 to archive P00 INFO: archive-push command end: completed successfully -------------------PROCESS START------------------- P00 INFO: archive-push command begin 1.23: --archive-async --backup-host=backup --backup-user=backrest --db1-path=/var/lib/postgresql/9.4/demo --log-level-file=detail --log-level-stderr=off --no-log-timestamp --process-max=2 --spool-path=/var/spool/pgbackrest --stanza=demo P00 INFO: push 3 WAL file(s) to archive: 000000080000000000000023...000000080000000000000025 P02 DETAIL: pushed WAL file 000000080000000000000024 to archive P01 DETAIL: pushed WAL file 000000080000000000000023 to archive P02 DETAIL: pushed WAL file 000000080000000000000025 to archive P00 INFO: archive-push command end: completed successfully复制
扫码关注了解更多
