第?4?章?连续归档和时间点恢复(PITR)

目录

4.1. 建立WAL归档
4.2. 使用ux_basebackup制作基础备份
4.3. 使用低级API制作基础备份
4.3.1. 制作一个非排他低级备份
4.3.2. 制作一个排他低级备份
4.3.3. 备份数据目录
4.4. 连续归档备份恢复
4.5. 时间线
4.6. 单机热备份

在任何时间,UXDB在数据集群目录的ux_wal/子目录下都有一个预写式日志(WAL)。这个日志存在的目的是为了保证系统崩溃后的安全:如果系统崩溃,可以“重放”从最后一次检查点以来的日志项来恢复数据库的一致性。该日志的存在使第三种备份数据库的策略变得可能:将文件系统级别的备份和WAL文件的备份结合起来。当需要恢复时,首先恢复文件系统备份,然后从备份的WAL文件中重放来把系统带到一个当前状态。这种方法比之前的方法管理起来要更复杂,但是有其显著的优点:

  1. 不需要一个完全一致的文件系统备份作为开始点。备份中的任何内部不一致性将通过日志重放(这和崩溃恢复期间发生的并无显著不同)来修正。因此不需要文件系统快照功能,只需要tar或一个类似的归档工具。

  2. 由于可以结合一个无穷长的WAL文件序列用于重放,可以通过简单地归档WAL文件来达到连续备份。这对于大型数据库特别有用,因为在其中不方便频繁地进行完全备份。

  3. 并不需要一直重放WAL一直到最后。WAL重放可以在任何点停止重放,得到数据库在当时的一致快照。这样,该技术支持时间点恢复:在得到你的基础备份以后,可以将数据库恢复到它在其后任何时间的状态。

  4. 如果连续地将一系列WAL文件输送给另一台已经载入了相同基础备份文件的机器,就得到了一个热备份系统:在任何时间点都能提出第二台机器,它是数据库的当前副本。

注意

ux_dump和ux_dumpall不会产生文件系统级别的备份,并且不能用于连续归档。这类转储是逻辑的并且不包含足够的信息用于WAL重放。

就简单的文件系统备份技术来说,这种方法只能支持整个数据库集群的恢复,却无法支持其中一个子集的恢复。另外,它需要大量的归档存储:一个基础备份的体积可能很庞大,并且一个繁忙的系统将会产生大量需要被归档的WAL流量。尽管如此,在很多需要高可靠性的情况下,它是首选的备份技术。

要使用连续归档成功地恢复,需要从基础备份时间开始的连续的归档WAL文件序列。为了开始,在建立第一个基础备份之前,应该建立并测试用于归档WAL文件的过程。如下首先讨论归档WAL文件的机制。

在编写此文档时,连续归档技术存在一些限制。这可能会在未来的发布中被修复:

注意

还需要注意的是,因为包括很多磁盘页快照,默认的WAL格式相当庞大。这些页快照用于支持崩溃恢复,修复断裂的磁盘页。依靠系统硬件和软件,页断裂的风险小到可以忽略,在此种情况下可以通过使用full_page_writes参数关闭页快照来显著降低归档日志的总容量。关闭页快照并不会阻止使用日志进行PITR操作。同时,管理员可能希望通过尽可能增大检查点间隔参数来减少WAL中包含的页快照数量。

XML 地图 | Sitemap 地图