问PostgreSQL的恢复策略到底是如何工作的？

EN

我正在测试并试图找出PostgreSQL 11中的备份和恢复策略是如何工作的，但它并不像预期的那样工作。当我恢复备份时，我没有得到正确的状态。在给定的时间戳之后，我得到任何状态。详细情况：

我在数据库中有这样的设置：

wal_level = replica 
max_wal_senders = 10
archive_mode = on

我执行了以下命令：

postgres=# select pg_create_physical_replication_slot('slot1');
pg_basebackup -D /media/extern/postgresql_basebackup/
pg_receivewal -D /media/extern/postgresql_archive -S slot1 -v

pg_receivewal正在编写postgresql_archive，这似乎是可行的。

• 然后我把一些东西插入到数据库中，比方说16:21。
• 我等了几分钟，比方说到16:27，删除所有插入的内容。

然后我想通过做.

service postgresql stop

(我也需要阻止pg_receivewal吗)？

# mv main main.before_recovery
# cp -rp /media/extern/postgresql_basebackup main

nano /var/lib/postgresql/11/main/recovery.conf

我添加以下内容

restore_command = 'cp -r /media/extern/postgresql_archive/%f %p'
recovery_target_time='2018-01-06 16:22:00'

然后我执行

# chown postgres:postgres recovery.conf 
# chmod 700 recovery.conf 

service postgresql start

启动后，文件将更改为recovery.done，但数据库中的状态是错误的。它没有恢复数据。数据库仍然是空的，所以PITR没有工作，为什么？

如果一切恢复顺利，我该怎么办？我对这些问题不太确定：

• 通过执行slot2 (‘slot2’)创建一个新的slot2；并通过pg_receivewal -D /media/extern/postgresql_归档-S slot2 -v从这个插槽流？
• 再次执行pg_receivewal -D /media/extern/postgresql_archive -S slot1 -v吗？
• 在postgresql_archive中有任何数据时，是否必须删除任何数据？(->可能不会)
• 我什么时候必须创建另一个基本备份？
• 在这个恢复概念中，何时以及为什么执行select pg_switch_wal()？
• 恢复后如何处理新的“时间表”？我理解时间线的概念，但是我不确定在恢复之后我应该如何去做。

更新

杰恩斯指出，日期是错误的。我更正了它，但恢复后仍然得到一个空数据库。在恢复数据库(现在为空)之后，我尝试了以下步骤：

2019-01-08，18:50:从这个空数据库创建一个新的基本备份，以便有一个良好的起点。创建slot1 pg_receivewal -D /media/extern/postgresql_ slot1 -v 2019-01-08，18:57插入2019-01-08，19:38删除

服务postgresql停止

# mv main main.before_recovery
# cp -rp /media/extern/postgresql_basebackup main
# chmod 700 main

# nano /var/lib/postgresql/11/main/recovery.conf

restore_command = 'cp -r /media/extern/postgresql_archive/%f %p'
recovery_target_time='2019-01-08 19:20:00'

# chown postgres:postgres recovery.conf 
# chmod 700 recovery.conf 

# service postgresql start

(顺便说一句，我看到它在复苏后就开始了新的时刻表。)

更新

我在postgresql.conf中激活

checkpoint_flush_after = 256kB 
checkpoint_timeout = 30s

我尝试使用前面的方法恢复数据库，但没有使用recovery_target_time，也没有任何DELETE语句。我只想看看现在的完全状态是否可以重建。此外，在停止数据库和恢复数据之前，我将当前wal文件00000007000000000000002D.partial重命名为0000000700000000002D。

目前我还不确定这些东西中哪一种有效，但至少，非PITR恢复似乎有效，因为我能够通过安装(空的)基本备份和wal文件来恢复最新的数据。至少向正确的方向迈出了一步，但只有当您不错过任何附带的wal文件时，这才有效。在这里，问题2开始发挥作用:处理“下一次交付迭代”的正确工作流是什么。首先，如果不删除外部文件夹中的附带WALs，就无法再次启动pg_receivewal -D /media/extern/postgresql_archive -S slot1 -v。否则，它将不会开始传送日志，并且会因连接错误而中止。这意味着您可以丢弃旧的基本备份，因为当您再次尝试使用旧的基本备份进行恢复时，您将错过基础备份和最后一个恢复点之间的所有wal日志(因为您删除了它们)。这也意味着您必须立即从恢复点状态创建一个新的基本备份。当您再次开始日志传送时，在新的基本备份和wal文件之间没有“空白”。

更新

我让PITR以同样的方式运行，所以我现在能够“撤销”一个删除。恢复和service postgresql start之后，数据库保持只读模式。我不得不执行select pg_wal_replay_resume();使它再次RW。如前所述，我不能再装船了。当我不修改归档文件夹并尝试重新启动WAL以便在同一个文件夹中装载时，我会得到以下异常：

pg_receivewal:无法发送复制命令"START_REPLICATION"：错误:请求在时间轴11上的起始点0/34000000不在此服务器的历史详细信息中:此服务器的历史记录在34000000/3310ADA8处从时间线11分叉。

当然，我可以将日志传送到一个新的归档文件夹或其他什么地方，但我想这不是专业的方法。恢复后恢复日志传送的常用策略是什么？