我最近有一个重新启动的副本，但无法赶上足够的时间来启用流复制。WAL 归档还原和恢复花费的时间有点太长了。pgBackRest 团队提供了这些非常有用的技巧，我想与大家分享。
这三个 pgBackRest 参数在加快 WAL 存档还原和恢复时间方面起着关键作用：
- archive-async
- archive-get-queue-max
- spool-path
在恢复期间，PostgreSQL 将通过restore_command参数要求 pgBackRest 检索下一个 WAL 文件并将其放入pg_wal目录中。这是我们想要加速的过程。
archive-async
启用archive-async告诉 pgBackRest 预取 WAL 文件，以便当 PostgreSQL 请求它们时它们将在本地可用（它串行执行，仅当恢复先前的 WAL 时）。当 WAL 档案被远程存储时，这是一个巨大的胜利，尤其是在像 S3 或 Azure 这样的云中。WAL 档案被预取并存储在由 指定的位置spool-path，它将存储最多由 指定的数量（以字节为单位archive-get-queue-max）。现在让我们讨论这些。
archive-async=y
archive-get-queue-max
默认情况下，archive-get-queue-max设置为128MB，这非常小。由于一个 WAL 文件通常是 16MB，这意味着这里只能预取 8 个 WAL 文件并存储在磁盘上。我建议立即去1GB，也许更高（例如4GB），具体取决于所涉及的活动量。
请记住，此空间将在 中使用spool-path，因此请确保该卷上有足够的可用空间。说到这……
archive-get-queue-max=4GB
spool-path
最后但并非最不重要的是，我们来到spool-path. 如前所述，这是 pgBackRest 将存储预取 WAL 文件的地方。然后，当 PostgreSQL 请求下一个 WAL 时，pgBackRest 将文件从该spool-path位置移动到pg_walPostgreSQL 数据目录下的目录。这比每次请求时等待 pgBackRest 从云中获取文件要好得多，但我们仍然可以使更好。
spool-path=/var/lib/pg_wal/spool
位置
当 pgBackRest 将文件从一个目录移动到同一卷上的另一个目录时，这是一项快速mv操作。基本上是指针变化。但是，如果源位置和目标位置在不同的卷上，那么我们必须将整个文件复制到新位置。您可能已经猜到了，这里的关键是确保它spool-path与 PostgreSQLpg_wal目录位于同一卷上。这样做可以将恢复时间缩短几毫秒（在我的测试中，时间通常从约 24 毫秒减少到 2 毫秒，减少了 12 倍）。
重要的是要注意，如果您pg_wal从数据目录符号链接到单独的卷，那么spool-path应该在同一个单独的卷上。您希望成为实际 WAL 文件所在的位置，而不一定是数据目录位置。
检查您的权限
通常，spool-path如果需要，pgBackRest 将创建（如果它可以作为 postgres）。但是，如果spool-path无法创建（或以其他方式写入），那么您将archive-get在恢复时失败：
2021-05-23 21:56:52.095 UTC [21656] LOG: starting archive recovery
2021-05-23 21:56:52.102 P00 INFO: archive-get command begin 2.33: [000000010000000000000002, pg_wal/RECOVERYXLOG] --archive-async --exec-id=21660-fdd3647d --log-level-console=info --pg1-path=/var/lib/postgresql/12/main --process-max=2 --repo1-azure-account=<redacted> --repo1-azure-container=pgbackrest --repo1-azure-key=<redacted> --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/ --repo1-type=azure --spool-path=/var/lib/pg_wal/spool --stanza=postgres-foo
ERROR: [047]: unable to create path '/var/lib/pg_wal/spool': [13] Permission denied
2021-05-23 21:56:52.103 P00 INFO: archive-get command end: aborted with exception [047
需要注意的一件事：当您尝试spool-path在正在运行的实例上设置 a时，如果您无法写入路径，那么您将收到错误消息，archive-push但原因可能不会立即清楚，因为 pgBackRest（截至 2.33 ) 不会Permission denied在 PostgreSQL 日志中写入消息：
ERROR: [082]: unable to push WAL file '00000002000185E70000004B' to the archive asynchronously after 60 second(s)
2021-05-19 15:46:19.372 P00 INFO: archive-push command end: aborted with exception [082]
2021-05-19 15:46:19.374 UTC [22000] LOG: archive command failed with exit code 82
2021-05-19 15:46:19.374 UTC [22000] DETAIL: The failed archive command was: /usr/bin/pgbackrest --stanza=postgres-foo archive-push pg_wal/000000020
00185E70000004B
2021-05-19 15:46:20.386 P00 INFO: archive-push command begin 2.32: [pg_wal/00000002000185E70000004B] --archive-async --compress-type=lz4 --exec-id=22071-481bde16 --log-level-console=info --log-level-file=info --pg1-path=/var/lib/postgresql/12/main --process-max=3 --repo1-azure-account=<redacted> --repo1-azure-container=pgbackrest --repo1-azure-key=<redacted> --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-256-cbc --repo1-path=/ --repo1-type=azure --spool-path=/var/lib/pg_wal/spool --stanza=postgres-foo
但是，它确实将其写入 pgBackRest 归档推送异步日志（通常位于 /var/log/pgbackrest 下）：
-------------------PROCESS START-------------------
2021-05-19 15:46:20.399 P00 INFO: archive-push:async command begin 2.32: [/var/lib/postgresql/12/main/pg_wal] --archive-async --compress-type=lz4 --
exec-id=22071-481bde16 --log-level-console=off --log-level-file=info --log-level-stderr=off --pg1-path=/var/lib/postgresql/12/main --process-max=3 --r
epo1-azure-account=<redacted> --repo1-azure-container=pgbackrest --repo1-azure-key=<redacted> --repo1-cipher-pass=<redacted> --repo1-cipher-type=aes-2
56-cbc --repo1-path=/ --repo1-type=azure --spool-path=/var/lib/pg_wal/spool --stanza=postgres1-test
2021-05-19 15:46:20.399 P00 ERROR: [047]: unable to create path '/var/lib/pg_wal/spool': [13] Permission denied
2021-05-19 15:46:20.399 P00 INFO: archive-push:async command end: aborted with exception [047]
所以一定要检查postgres用户（或其他用户pgbackrest运行的，但通常是postgres）有权限写入（创造，如果有必要）通过指定的位置spool-path。
原文地址：https://seiler.us/2021-05-23-speeding-up-pgbackrest-recovery/
