# 26.3.连续归档和时间点恢复(PITR)

26.3.1. 设置WAL归档

26.3.2. 做基地备份

26.3.3. 使用低级API进行基本备份

26.3.4. 使用连续存档备份进行恢复

26.3.5. 时间表

26.3.6. 提示和示例

26.3.7. 警告

PostgreSQL始终保持提前写日志(沃尔)在普格沃尔/集群数据目录的子目录。日志记录对数据库数据文件所做的每一次更改。此日志主要用于崩溃安全目的:如果系统崩溃,可以通过“重放”自上次检查点以来创建的日志条目,将数据库恢复到一致性。然而,日志的存在使得使用第三种策略备份数据库成为可能:我们可以将文件系统级备份与WAL文件的备份结合起来。如果需要恢复,我们将恢复文件系统备份,然后从备份的WAL文件中重播,使系统恢复到当前状态。与之前的两种方法相比,这种方法的管理更加复杂,但它有一些显著的好处:

  • 我们不需要一个完全一致的文件系统备份作为起点。备份中的任何内部不一致性都将通过日志重播进行纠正(这与崩溃恢复期间发生的情况没有明显区别)。因此,我们不需要文件系统快照功能,只需要tar或类似的归档工具。

  • 由于我们可以将无限长的WAL文件序列组合起来进行重播,因此只需继续归档WAL文件,就可以实现连续备份。这对于大型数据库尤其有用,因为在这些数据库中,经常进行完整备份可能并不方便。

  • 不必一直重播WAL条目到最后。我们可以在任何时候停止重播,并获得数据库当时的一致快照。因此,这种技术支持时间点恢复:自进行基本备份后,可以随时将数据库恢复到其状态。

  • 如果我们连续地将一系列WAL文件馈送到另一台加载了相同基本备份文件的机器,我们就有了一个热备用系统:在任何时候,我们都可以启动第二台机器,它将拥有数据库的一个几乎最新的副本。

# 笔记

pg_转储和pg_dumpall不生成文件系统级备份,不能作为连续存档解决方案的一部分使用。这样的垃圾场必然的并且没有包含足够的信息供WAL replay使用。

与普通文件系统备份技术一样,这种方法只能支持整个数据库集群的恢复,而不能支持子集的恢复。此外,它还需要大量的存档存储:基本备份可能非常庞大,繁忙的系统将产生大量必须存档的WAL流量。尽管如此,在许多需要高可靠性的情况下,它仍然是首选的备份技术。

要使用连续存档(许多数据库供应商也称为“在线备份”)成功恢复,您需要一系列连续的存档WAL文件,这些文件至少可以追溯到备份的开始时间。因此,要开始,您应该设置并测试归档WAL文件的过程之前你做了第一次基地备份。因此,我们首先讨论归档WAL文件的机制。

# 26.3.1.设置WAL归档

从抽象意义上讲,运行的PostgreSQL系统会产生无限长的WAL记录序列。系统在物理上将该序列划分为WAL段文件,每个通常为16MB(尽管在initdb期间可以更改段大小)。段文件的数字名称反映了它们在抽象序列中的位置。当不使用WAL归档时,系统通常只创建几个段文件,然后通过将不再需要的段文件重命名为更高的段号来“回收”它们。假设内容位于最后一个检查点之前的段文件不再受关注,可以循环使用。

在归档WAL数据时,我们需要在每个段文件被填充后捕获其内容,并在段文件被循环使用之前将该数据保存在某个位置。根据应用程序和可用硬件的不同,可能有许多不同的“将数据保存到某处”的方法:我们可以将段文件复制到另一台机器上的NFS挂载目录,将其写入磁带驱动器(确保您有办法识别每个文件的原始名称),或者将其批处理并刻录到CD或其他完全不同的地方。为了给数据库管理员提供灵活性,PostgreSQL尽量不对归档方式进行任何假设。相反,PostgreSQL允许管理员指定要执行的shell命令,以将完成的段文件复制到需要的任何位置。命令可以简单到内容提供商,或者它可以调用一个复杂的shell脚本——这完全取决于您。

要启用WAL存档,请设置沃尔_数量配置参数为复制品或者更高,档案文件_模式在…上,并指定要在中使用的shell命令档案文件_命令配置参数。实际上,这些设置将始终放置在postgresql。形态文件在里面档案室命令, %p替换为要存档的文件的路径名,而%f只替换为文件名。(路径名相对于当前工作目录,即集群的数据目录。)使用%%如果你需要嵌入一个实际的%命令中的字符。最简单有用的命令如下:

archive_command = 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'  # Unix
archive_command = 'copy "%p" "C:\\server\\archivedir\\%f"'  # Windows

将可归档的WAL段复制到目录中/mnt/server/archivedir(这只是一个例子,不是一个建议,可能不适用于所有平台。)之后%p%f参数已被替换,实际执行的命令可能如下所示:

test ! -f /mnt/server/archivedir/00000001000000A900000065 && cp pg_wal/00000001000000A900000065 /mnt/server/archivedir/00000001000000A900000065

将为每个要存档的新文件生成类似的命令。

存档命令将在运行PostgreSQL server的同一用户的所有权下执行。由于归档的一系列WAL文件有效地包含了数据库中的所有内容,因此您需要确保归档的数据不受窥探;例如,归档到一个没有组或全局读取权限的目录中。

当且仅当存档命令成功时,它才返回零退出状态,这一点很重要。得到零结果后,PostgreSQL将假定该文件已成功存档,并将删除或回收该文件。然而,非零状态告诉PostgreSQL该文件未存档;它将定期重试,直到成功。

当存档命令因信号(不是作为服务器关闭的一部分使用的SIGTERM)或外壳程序的错误(退出状态大于125)而终止时(例如找不到命令),存档进程将中止,并由邮局主管重新启动。在这种情况下,故障不会在报告中报告pg_斯达_阿奇弗.

“存档”命令通常应设计为拒绝覆盖任何预先存在的存档文件。这是一项重要的安全功能,可以在管理员出错(例如将两台不同服务器的输出发送到同一个存档目录)时保护存档的完整性。

建议测试建议的存档命令,以确保它确实不会覆盖现有文件,在这种情况下,它返回非零状态.上面针对Unix的示例命令通过包含一个单独的测验步在一些Unix平台上,内容提供商有开关,例如-我这可以用来做同样的事情,但你不应该在没有验证返回正确退出状态的情况下依赖它们。(尤其是GNU)内容提供商-我已使用,且目标文件已存在,即期望的行为。)

在设计存档设置时,考虑如果存档命令重复失败会发生什么,因为某些方面需要操作员干预或存档耗尽空间。例如,如果在没有自动转换器的情况下写入磁带,可能会发生这种情况;当磁带填满时,在交换磁带之前,不能再存档任何内容。您应确保向人工操作员报告任何错误情况或请求,以便能够合理快速地解决问题。这个普格沃尔/目录将继续填充WAL段文件,直到问题得到解决。(如果文件系统包含普格沃尔/填充后,PostgreSQL将紧急关闭。提交的事务不会丢失,但数据库将保持脱机状态,直到您释放一些空间。)

存档命令的速度并不重要,只要它能跟上服务器生成WAL数据的平均速度。即使归档过程稍微落后,正常操作仍将继续。如果归档严重滞后,这将增加灾难发生时丢失的数据量。这也意味着普格沃尔/该目录将包含大量尚未归档的段文件,这些文件最终可能会超过可用磁盘空间。建议您监控归档过程,以确保其按预期工作。

在编写存档命令时,应假定要存档的文件名最长可达64个字符,并且可以包含ASCII字母、数字和点的任意组合。没有必要保留原始相对路径(%p)但有必要保留文件名(%f).

请注意,尽管WAL存档将允许您恢复对PostgreSQL数据库中的数据所做的任何修改,但它不会恢复对配置文件所做的更改(即,postgresql。形态, pg_hba。形态pg_ident。形态),因为它们是手动编辑的,而不是通过SQL操作。您可能希望将配置文件保存在将由常规文件系统备份过程备份的位置。看见第20.2节了解如何重新定位配置文件。

archive命令仅在已完成的WAL段上调用。因此,如果您的服务器只生成很少的WAL通信量(或者在产生WAL通信量时有空闲时间),那么从事务完成到在归档存储中安全记录之间可能会有很长的延迟。要限制未归档数据的保存时间,可以设置档案文件_暂停强制服务器至少频繁地切换到新的WAL段文件。请注意,由于强制切换而提前归档的归档文件的长度仍然与完全完整的文件相同。因此,设定一个非常短的时间是不明智的存档超时-它会使你的档案存储空间膨胀。存档超时一分钟左右的设置通常是合理的。

此外,还可以使用手动强制进行分段切换pg_开关_墙如果您希望确保尽快归档刚刚完成的事务。与WAL管理相关的其他公用设施功能如所示表9.87.

什么时候瓦卢层最小的一些SQL命令经过优化以避免WAL日志记录,如中所述第14.4.7节。如果在执行其中一条语句时打开了存档或流式复制,WAL将无法包含足够的信息进行存档恢复。(碰撞恢复不受影响。)因此,瓦卢层只能在服务器启动时更改。然而档案室命令可以通过重新加载配置文件进行更改。如果希望暂时停止归档,一种方法是设置档案室命令到空字符串('')。这将导致WAL文件在普格沃尔/直到工作结束档案室命令重新建立。

# 26.3.2.做基地备份

执行基本备份的最简单方法是使用pg_基本备份工具它可以作为常规文件或tar存档创建基本备份。如果比pg_基本备份如果需要can提供,还可以使用低级API进行基本备份(请参阅第26.3.3节).

无需担心进行基本备份所需的时间。但是,如果您通常使用整页禁用后,在备份运行时,您可能会注意到性能下降整页在备份模式下有效地强制打开。

要使用备份,您需要保留文件系统备份期间和之后生成的所有WAL段文件。为了帮助您做到这一点,基本备份过程会创建备份历史文件这些信息会立即存储到WAL档案区。该文件以文件系统备份所需的第一个WAL段文件命名。例如,如果起始WAL文件是0000000 10000134000055CD备份历史文件的名称如下0000000 10000134000055CD。007C9330.备份(文件名的第二部分代表WAL文件中的确切位置,通常可以忽略。)一旦安全地归档了文件系统备份和备份过程中使用的WAL段文件(如备份历史文件中所指定),则恢复文件系统备份时不再需要所有名称数字较少的已归档WAL段,并且可以将其删除。但是,您应该考虑保持多个备份集绝对可以恢复数据。

备份历史文件只是一个小文本文件。它包含您提供给的标签字符串pg_基本备份,以及备份的开始和结束时间以及WAL段。如果使用标签标识关联的转储文件,则存档的历史文件足以告诉您要恢复哪个转储文件。

由于您必须将所有存档的WAL文件保留到上一次基本备份,因此基本备份之间的间隔通常应根据您希望在存档的WAL文件上花费的存储量来选择。你也应该考虑你准备花多长时间来恢复,如果需要恢复的话,系统将不得不重放所有的WAL段,这可能需要一段时间,如果它已经很长一段时间以来的最后一个基础备份。

# 26.3.3.使用低级API进行基本备份

使用低级API进行基本备份的过程比pg_基本备份方法,但相对简单。按顺序执行这些步骤非常重要,并且在继续下一步之前验证步骤是否成功。

低级基本备份可以以非独占或独占的方式进行。建议使用非独占方法,独占方法不推荐使用,最终将被删除。

# 26.3.3.1.进行非独占的低级别备份

非独占低级别备份是指允许运行其他并发备份的备份(使用相同备份API启动的备份和使用相同备份API启动的备份)pg_基本备份).

  1. 确保WAL存档已启用并正常工作。

  2. 以有权运行pg的用户身份连接到服务器(无论是哪个数据库)_开始_备份(超级用户或已被授权执行该函数的用户)并发出以下命令:

    SELECT pg_start_backup('label', false, false);
    

    哪里标签要用于唯一标识此备份操作的任何字符串。连接呼叫pg_启动_备份必须保留到备份结束,否则备份将自动中止。

    默认情况下,pg_启动_备份可能需要很长时间才能完成。这是因为它执行一个检查点,检查点所需的I/O将在相当长的一段时间内分散,默认情况下是检查点间隔的一半(请参阅配置参数)检查站_完成_目标)。这通常是您想要的,因为它将对查询处理的影响降至最低。如果要尽快启动备份,请将第二个参数更改为符合事实的,它将使用尽可能多的I/O立即发出检查点。

    第三个参数是错误的说明pg_启动_备份启动非独占的基本备份。

  3. 使用任何方便的文件系统备份工具(如tar或cpio,而不是pg)执行备份_转储或pg_dumpall)。在执行此操作时,既没有必要也不希望停止数据库的正常操作。看见第26.3.3.3节在备份期间要考虑的事项。

  4. 在与前面相同的连接中,发出以下命令:

    SELECT * FROM pg_stop_backup(false, true);
    

    这将终止备份模式。在主站上,它还会自动切换到下一个WAL段。在待机状态下,无法自动切换WAL段,因此您可能希望运行pg_开关_墙在主开关上执行手动开关。切换的原因是安排在备份间隔期间写入的最后一个WAL段文件准备归档。

    这个pg_停止_备份将返回包含三个值的一行。第二个字段应写入名为备份标签在备份的根目录中。第三个字段应写入名为表空间映射除非场地是空的。这些文件对备份工作至关重要,必须逐字节写入,无需修改,这可能需要以二进制模式打开文件。

  5. 备份过程中活动的WAL段文件归档后,即可完成备份。由pg_停止_备份的第一个返回值是形成完整备份文件集所需的最后一个段。如果是初选的话存档模式已启用,并且等待存档参数为符合事实的, pg_停止_备份直到最后一段存档后才返回。待命,存档模式必须是总是为了pg_停止_备份等待。这些文件的存档会自动进行,因为您已经配置了档案室命令。在大多数情况下,这种情况发生得很快,但建议您监控归档系统,以确保不会出现延迟。如果存档过程因存档命令失败而落后,它将继续重试,直到存档成功并完成备份。如果你想对执行pg_停止_备份,设定适当的语句超时值,但请注意,如果pg_停止_备份因此终止您的备份可能无效。

    如果备份过程监控并确保成功归档备份所需的所有WA段文件,则等待存档参数(默认为true)可以设置为false以pg_停止_备份将停止备份记录写入WAL后立即返回。默认情况下,pg_停止_备份将等待所有WAL归档,这可能需要一些时间。必须谨慎使用此选项:如果WAL存档未得到正确监控,则备份可能不包括所有WAL文件,因此将不完整,无法恢复。

# 26.3.3.2.进行独家低级别备份

# 笔记

独占备份方法已被弃用,应避免使用。在PostgreSQL 9.6之前,这是唯一可用的低级方法,但现在建议所有用户升级脚本以使用非独占备份。

独占备份的过程与非独占备份的过程基本相同,但在几个关键步骤上有所不同。这种类型的备份只能在主服务器上进行,不允许并发备份。此外,由于它会创建一个备份标签文件(如下所述),因此会在崩溃后阻止主服务器的自动重启。另一方面,从备份或备用文件中错误删除此文件是常见的错误,这可能会导致严重的数据损坏。如果需要使用这种方法,可以使用以下步骤。

  1. 确保WAL存档已启用并正常工作。

  2. 以有权运行pg的用户身份连接到服务器(无论是哪个数据库)_开始_备份(超级用户或已被授权执行该函数的用户)并发出以下命令:

    SELECT pg_start_backup('label');
    

    哪里标签要用于唯一标识此备份操作的任何字符串。pg_启动_备份创造一个备份标签文件,叫备份标签,以及有关备份的信息,包括开始时间和标签字符串。该函数还创建一个表空间映射文件,叫表空间映射,在集群目录中,提供有关表空间符号链接的信息pg_tblspc/如果存在一个或多个此类链接。如果需要从备份中恢复,这两个文件对备份的完整性都至关重要。

    默认情况下,pg_启动_备份可能需要很长时间才能完成。这是因为它执行一个检查点,检查点所需的I/O将在相当长的一段时间内分散,默认情况下是检查点间隔的一半(请参阅配置参数)检查站_完成_目标)。这通常是您想要的,因为它将对查询处理的影响降至最低。如果要尽快启动备份,请使用:

    SELECT pg_start_backup('label', true);
    

    这迫使检查点尽快完成。

  3. 使用任何方便的文件系统备份工具(如tar或cpio,而不是pg)执行备份_转储或pg_dumpall)。在执行此操作时,既没有必要也不希望停止数据库的正常操作。看见第26.3.3.3节在备份期间要考虑的事项。

    如上所述,如果服务器在备份过程中崩溃,则可能无法重新启动,直到备份标签文件已从中手动删除PGDATA目录请注意,永远不要移除备份标签在恢复备份时使用该文件,因为这将导致损坏。在使用此方法时,混淆何时删除此文件是导致数据损坏的常见原因;请务必确保仅在现有主设备上删除文件,而在构建备用设备或恢复备份时,永远不要删除该文件,即使您正在构建一个将随后升级到新主设备的备用设备。

  4. 再次以有权运行pg的用户身份连接到数据库_停止_备份(超级用户,或已被授权在函数上执行的用户),并发出以下命令:

    SELECT pg_stop_backup();
    

    此功能终止备份模式,并自动切换到下一个WAL段。切换的原因是安排在备份间隔期间写入的最后一个WAL段准备归档。

  5. 备份过程中活动的WAL段文件归档后,即可完成备份。由pg_停止_备份的结果是形成完整备份文件集所需的最后一段。如果存档模式已启用,pg_停止_备份直到最后一段存档后才返回。这些文件的存档会自动进行,因为您已经配置了档案室命令。在大多数情况下,这种情况发生得很快,但建议您监控归档系统,以确保不会出现延迟。如果存档过程因存档命令失败而落后,它将继续重试,直到存档成功并完成备份。

    使用独占备份模式时,必须确保pg_停止_备份在备份结束时成功完成。即使备份本身失败,例如由于磁盘空间不足,也无法调用pg_停止_备份将使服务器无限期处于备份模式,导致未来的备份失败,并增加在备份期间重启失败的风险备份标签存在。

# 26.3.3.3.备份数据目录

如果某些文件系统备份工具试图复制的文件在复制过程中发生更改,则会发出警告或错误。对活动数据库进行基本备份时,这种情况是正常的,不是错误。但是,您需要确保能够区分此类投诉和真正的错误。例如,某些版本的rsync会为“消失的源文件”返回一个单独的退出代码,您可以编写一个驱动程序脚本,将此退出代码作为非错误情况接受。此外,如果文件在tar复制时被截断,那么某些版本的GNU-tar会返回一个与致命错误无法区分的错误代码。幸运的是,GNU tar 1.16及更高版本在备份过程中如果文件发生更改,将以1退出,其他错误将以2退出。对于GNU tar 1.23及更高版本,您可以使用警告选项--警告=未更改任何文件--警告=未删除任何文件隐藏相关的警告消息。

确保备份包括数据库群集目录下的所有文件(例如。,/usr/local/pgsql/data)。如果使用的表空间不在此目录下,请小心将它们也包括在内(并确保备份将符号链接存档为链接,否则还原将损坏表空间)。

但是,您应该从备份中省略集群的普格沃尔/子目录。这种轻微的调整是值得的,因为它降低了恢复时出错的风险。这很容易安排,如果普格沃尔/是指向群集目录之外某个位置的符号链接,出于性能原因,这是一种常见的设置。您可能还想排除邮政局长。pid邮政局长。选择,它记录有关正在运行的邮局主管的信息,而不是有关最终将使用此备份的邮局主管的信息。(这些文件可能会让人困惑。)_ctl.)

通常,在备份中省略集群服务器中的文件也是一个好主意pg_插槽/目录,以便主服务器上存在的复制插槽不会成为备份的一部分。否则,随后使用备份创建备份可能会导致WAL文件无限期保留在备份上,如果启用了热备份反馈,则可能会导致主备份上的WAL文件膨胀,因为使用这些复制插槽的客户端仍将连接并更新主备份上的插槽,而不是备份上的插槽。即使备份仅用于创建新的主服务器,复制复制插槽也不会特别有用,因为在新的主服务器上线时,这些插槽的内容可能会严重过时。

目录的内容pg_dynshmem/, pg_通知/, pg_系列/, pg_快照/, pg_stat_tmp/pg_子传输/(但不是目录本身)可以从备份中省略,因为它们将在postmaster启动时初始化。如果统计数据_临时雇员_目录设置并位于数据目录下,则该目录的内容也可以省略。

任何以开头的文件或目录pgsql_tmp可以从备份中省略。这些文件在postmaster启动时被删除,目录将根据需要重新创建。

pg_内部。初始化只要找到具有该名称的文件,就可以从备份中省略文件。这些文件包含恢复时始终重建的关系缓存数据。

备份标签文件包含您提供给的标签字符串pg_启动_备份,以及pg_启动_备份已运行,以及启动WAL文件的名称。因此,在出现混淆的情况下,可以查看备份文件内部,并确定转储文件来自哪个备份会话。表空间映射文件包含存在于目录中的符号链接名pg_tblspc/以及每个符号链接的完整路径。这些文件不仅仅是供你参考的;它们的存在和内容对于系统恢复过程的正常运行至关重要。

也可以在服务器停止时进行备份。在这种情况下,显然不能使用pg_启动_备份pg_停止_备份,因此,您将由自己的设备来跟踪哪个备份是哪个备份以及相关WAL文件的备份时间。一般来说,遵循上面的连续归档过程会更好。

# 26.3.4.使用连续存档备份进行恢复

好吧,最坏的情况已经发生了,你需要从备份中恢复。以下是程序:

  1. 如果服务器正在运行,请停止服务器。

  2. 如果您有空间这样做,请将整个集群数据目录和任何表空间复制到一个临时位置,以备以后需要。请注意,这一预防措施要求系统上有足够的可用空间来保存现有数据库的两个副本。如果没有足够的空间,至少应该保存集群的普格沃尔子目录,因为它可能包含系统关闭前未存档的日志。

  3. 删除集群数据目录下以及正在使用的任何表空间的根目录下的所有现有文件和子目录。

  4. 从文件系统备份还原数据库文件。确保它们以正确的所有权(数据库系统用户,而不是!) 并且拥有正确的权限。如果您使用的是表空间,那么应该验证pg_tblspc/都得到了正确的恢复。

  5. 删除中存在的所有文件普格沃尔/; 它们来自文件系统备份,因此可能已经过时,而不是最新版本。如果你没有存档普格沃尔/无论如何,然后用适当的权限重新创建它,如果之前已经以这种方式设置了它,请小心确保将其重新建立为一个符号链接。

  6. 如果在步骤2中保存了未归档的WAL段文件,请将其复制到普格沃尔/(最好是复制它们,而不是移动它们,因此如果出现问题,您仍然可以使用未修改的文件,并且必须重新开始。)

  7. 在中设置恢复配置设置postgresql。形态(见第20.5.4节)并创建一个文件恢复信号在集群数据目录中。您可能还需要临时修改pg_hba。形态阻止普通用户连接,直到您确定恢复成功。

  8. 启动服务器。服务器将进入恢复模式,并继续读取所需的存档WAL文件。如果由于外部错误而终止恢复,则只需重新启动服务器,即可继续恢复。恢复过程完成后,服务器将删除恢复信号(以防止以后意外重新进入恢复模式),然后开始正常的数据库操作。

  9. 检查数据库内容,确保已恢复到所需状态。如果没有,请返回步骤1.如果一切正常,请允许用户通过恢复连接pg_hba。形态恢复正常。

    所有这些的关键部分是设置一个恢复配置,该配置描述了您希望恢复的方式以及恢复应该运行的距离。你必须明确的一点是恢复命令,它告诉PostgreSQL如何检索归档的WAL文件段。就像档案室命令,这是一个shell命令字符串。它可以容纳%f,替换为所需日志文件的名称,以及%p,替换为要将日志文件复制到的路径名。(路径名相对于当前工作目录,即集群的数据目录。)写%%如果你需要嵌入一个实际的%命令中的字符。最简单有用的命令如下:

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

它将从目录中复制以前存档的WAL段/mnt/server/archivedir.当然,你可以使用更复杂的东西,甚至可能是一个shell脚本,要求操作员挂载适当的磁带。

重要的是,命令在失败时返回非零退出状态。命令被称为请求档案中不存在的文件;当被询问时,它必须返回非零。这不是错误情况。例外情况是,如果命令是由一个信号(SIGTERM除外,它被用作数据库服务器关闭的一部分)或shell的一个错误(例如找不到命令)终止的,则恢复将中止,服务器将不会启动。

并非所有请求的文件都是WAL段文件;您还应该期待对后缀为的文件的请求历史。还要注意的是%p路径将不同于%f; 不要期望它们可以互换。

在档案中找不到的WAL片段将在普格沃尔/; 这允许使用最近未归档的片段。但是,存档中可用的段将优先于中的文件使用普格沃尔/.

通常情况下,恢复将通过所有可用的WAL段进行,从而将数据库恢复到当前时间点(或在给定可用WAL段的情况下尽可能接近)。因此,正常恢复将以“未找到文件”消息结束,错误消息的确切文本取决于您的选择恢复命令。您可能还会在恢复开始时看到名为00000001.历史。这也是正常现象,并不表明在简单的恢复情况下存在问题;看见第26.3.5节供讨论。

如果您想恢复到以前的某个时间点(例如,就在初级DBA删除主事务表之前),只需指定所需的停车点. 您可以指定停止点,即“恢复目标”,可以按日期/时间、命名还原点或完成特定事务ID。在编写此操作时,只有日期/时间和命名还原点选项非常可用,因为没有工具可帮助您确定要使用哪个事务ID的准确性。

#

停止点必须在基本备份结束时间之后,即,结束时间pg停止\u备份. 您不能使用基本备份恢复到正在进行备份的时间。(要恢复到这样的时间,必须返回以前的基本备份并从中向前滚动。)

如果恢复发现WAL数据损坏,则此时恢复将停止,服务器将不会启动。在这种情况下,恢复过程可以从一开始重新运行,在腐败点之前指定一个“恢复目标”,以便恢复能够正常完成。如果由于外部原因(例如系统崩溃或WAL存档无法访问)而导致恢复失败,则恢复可以简单地重新启动,并且几乎从失败的地方重新启动。恢复重启的工作与正常操作中的检查点非常类似:服务器定期强制其所有状态到磁盘,然后更新pg炣控制文件表明不必再次扫描已处理的WAL数据。

# 26.3.5.时间安排

将数据库恢复到以前的时间点的能力,会产生一些复杂的情况,类似于科幻小说中关于时间旅行和平行宇宙的故事。例如,在数据库的原始历史中,假设您在周二晚上5:15掉了一张关键的桌子,但直到周三中午才意识到你的错误。不受影响,你拿出备份,恢复到星期二晚上5:14的时间点,然后开始运行。在数据库的历史,你从来没有掉过表。但是假设你后来意识到这不是一个好主意,并且想回到最初历史上的星期三上午。如果在数据库启动和运行时,它会覆盖一些WAL段文件,直到你现在希望你能够回到的时候,你就无法做到。因此,为了避免这种情况,您需要将在完成时间点恢复后生成的一系列WAL记录与原始数据库历史中生成的记录进行区分。

为了解决这个问题,PostgreSQL有一个概念时间线. 每当归档恢复完成时,就会创建一个新的时间线,以标识在恢复后生成的一系列WAL记录。时间线ID号是WAL段文件名的一部分,因此新的时间线不会覆盖以前时间线生成的WAL数据。事实上,可以归档许多不同的时间线。虽然这看起来是一个无用的功能,但它通常是救命稻草。考虑一下你不太确定恢复到什么时间点的情况,所以必须通过尝试和错误来做几个时间点恢复,直到你找到了最好的地方从旧历史中分离出来。如果没有时间安排,这个过程很快就会产生一个无法管理的混乱。使用时间线,您可以恢复到任何先前状态,包括您先前放弃的时间轴分支中的状态。

每次创建新的时间线时,PostgreSQL都会创建一个“时间线历史记录”文件,显示它从哪个时间线分支以及何时分支。在从包含多个时间线的存档中恢复时,这些历史文件是必要的,以允许系统选择正确的WAL段文件。因此,它们被归档到WAL归档区域,就像WAL段文件一样。历史文件只是小的文本文件,所以无限期地保存它们既便宜又合适(不同于大的段文件)。如果愿意,您可以在历史文件中添加注释,以记录有关创建此特定时间线的方式和原因的注释。当你有一大堆不同的时间线作为实验的结果时,这样的评论尤其有价值。

恢复的默认行为是恢复到存档中找到的最新时间线。如果希望恢复到进行基本备份时的当前时间线,或恢复到特定的子时间线(即,希望恢复到恢复尝试后生成的某个状态),则需要指定现在的或中的目标时间线ID恢复_目标_时间线。您无法恢复到早于基本备份的时间线。

# 26.3.6.提示和示例

这里给出了配置连续存档的一些技巧。

# 26.3.6.1.独立热备份

可以使用PostgreSQL的备份功能生成独立的热备份。这些备份不能用于时间点恢复,但通常比pg更快地进行备份和恢复_倒垃圾。(它们也比pg大得多。)_转储转储,因此在某些情况下,速度优势可能会被抵消。)

与基本备份一样,生成独立热备份的最简单方法是使用pg_基本备份工具如果包括-X参数调用时,使用备份所需的所有预写日志将自动包含在备份中,无需执行任何特殊操作即可恢复备份。

如果需要更灵活地复制备份文件,也可以将较低级别的过程用于独立热备份。要准备低级别的独立热备份,请确保瓦卢层即将复制品或者更高,存档模式在…上,并设立档案室命令仅当开关文件存在。例如:

archive_command = 'test ! -f /var/lib/pgsql/backup_in_progress || (test ! -f /var/lib/pgsql/archive/%f && cp %p /var/lib/pgsql/archive/%f)'

此命令将在以下情况下执行存档:/var/lib/pgsql/backup\u正在进行中存在,否则静默返回零退出状态(允许PostgreSQL回收不需要的WAL文件)。

通过这种准备,可以使用如下脚本进行备份:

touch /var/lib/pgsql/backup_in_progress
psql -c "select pg_start_backup('hot_backup');"
tar -cf /var/lib/pgsql/backup.tar /var/lib/pgsql/data/
psql -c "select pg_stop_backup();"
rm /var/lib/pgsql/backup_in_progress
tar -rf /var/lib/pgsql/backup.tar /var/lib/pgsql/archive/

切换文件/var/lib/pgsql/backup\u正在进行中首先创建,以便能够归档已完成的WAL文件。备份后,将删除开关文件。然后将归档的WAL文件添加到备份中,以便基本备份和所有必需的WAL文件都属于同一个tar文件。请记住在备份脚本中添加错误处理。

# 26.3.6.2.压缩归档日志

如果需要考虑归档存储大小,可以使用gzip压缩归档文件:

archive_command = 'gzip < %p > /mnt/server/archivedir/%f.gz'

然后,您需要在恢复过程中使用gunzip:

restore_command = 'gunzip < /mnt/server/archivedir/%f.gz > %p'

# 26.3.6.3. 档案室命令剧本

许多人选择使用脚本来定义他们的档案室命令,以便postgresql。形态入口看起来很简单:

archive_command = 'local_backup_script.sh "%p" "%f"'

在存档过程中,如果您想使用多个命令,建议使用单独的脚本文件。这允许在脚本中管理所有复杂性,脚本可以用流行的脚本语言(如bash或perl)编写。

可以在脚本中解决的需求示例包括:

  • 复制数据以保护非现场数据存储

  • 成批处理WAL文件,以便每三小时传输一次,而不是一次传输一次

  • 与其他备份和恢复软件的接口

  • 与监控软件接口以报告错误

# 提示

当使用档案室命令脚本,最好启用登录中_收藏家。然后,从脚本写入stderr的任何消息都将出现在数据库服务器日志中,这样,如果复杂配置失败,就可以轻松诊断它们。

# 26.3.7.警告

在本文中,连续存档技术有几个局限性。这些问题可能会在未来的版本中得到修复:

  • 如果创建数据库在进行基本备份时执行命令,然后执行创建数据库如果在基本备份仍在进行时修改了“复制”,则恢复可能会导致这些修改也传播到创建的数据库中。这当然是不可取的。为了避免这种风险,在进行基本备份时,最好不要修改任何模板数据库。

  • 创建表空间命令以文字绝对路径记录,因此将以相同绝对路径的表空间创建进行重放。如果日志正在另一台机器上重放,这可能是不可取的。即使在同一台计算机上重放日志,但将其放在新的数据目录中,这也可能是危险的:重放仍将覆盖原始表空间的内容。为了避免这种潜在的问题,最好的做法是在创建或删除表空间后进行新的基本备份。

    还应注意,默认WAL格式相当庞大,因为它包含许多磁盘页快照。这些页面快照旨在支持崩溃恢复,因为我们可能需要修复部分写入的磁盘页面。根据系统硬件和软件的不同,部分写入的风险可能很小,可以忽略,在这种情况下,可以通过使用满的_页_写参数(请阅读中的注释和警告。)第30章在你这么做之前。)关闭页面快照不会阻止将日志用于PITR操作。未来发展的一个领域是通过删除不必要的页面副本来压缩归档的WAL数据,即使在整页正在播放。同时,管理员可能希望通过尽可能增加检查点间隔参数来减少WAL中包含的页面快照的数量。