立即开始增强您的 PostgreSQL。
作者：Abhinav D.
如果您使用过 PostgreSQL 中的生产规模数据库，您就会知道有效的备份和定义明确的恢复计划对于管理它们至关重要。备份可以保护您的数据免遭丢失或损坏，并使您能够在发生故障、中断或人为错误时恢复数据库。在本指南中，我们将探讨 pg_restore，这是一个专门设计用于处理逻辑备份的 PostgreSQL 实用程序，在数据库恢复中起着至关重要的作用。
pg_restore 允许您从 pg_dump 创建的逻辑备份中恢复数据库。逻辑备份包含重新创建数据库对象和数据的 SQL 命令，可在不同的 PostgreSQL 版本和其他数据库系统之间提供灵活性和可移植性。
但是，请务必注意，pg_restore 和逻辑备份并不适合所有情况。它们有局限性，尤其是在处理大规模数据库或复杂的恢复场景时。在本文中，我们将深入探讨
了解 pg_restore 是什么以及它是如何工作的
确定何时 pg_restore 是满足您恢复需求的合适工具
探索有效使用 pg_restore 的实际示例
在本指南结束时，您将对 pg_restore 以及它如何适应您的 PostgreSQL 数据库整体备份和恢复策略有一个清晰的了解。
逻辑备份与物理备份不同，因为它们不包含数据库文件的直接副本。相反，逻辑备份是一个文件，其中包含一系列 SQL 命令，这些命令在执行时会将数据库重建到备份时的状态。
这种方法具有以下几个优点
逻辑备份可在不同的 PostgreSQL 版本之间移植，甚至可以迁移到支持 SQL 的其他数据库系统。
它们允许选择性地恢复特定的数据库对象，例如表或模式。
逻辑备份是人类可读的，并且可以在需要时进行检查或修改。
在创建 PostgreSQL 数据库的逻辑备份时，pg_dump 是首选工具。要使用 pg_dump 创建逻辑备份，您可以使用以下基本命令
pg_dump [database_name] -f backup_file.sql
-f 或 --file：指定输出文件的路径。
此命令连接到指定的数据库，检索重新创建数据库对象和数据所需的 SQL 命令，并将它们保存到名为 backup_file.sql 的文件中。
例如，要创建我们的电子商务数据库的逻辑备份，您将运行
pg_dump ecommerce -f /tmp/ecommerce_backup.sql
pg_dump 提供了许多用于自定义备份过程的选项。一些常用的选项包括
-U 或 --username：指定用于连接到数据库的用户名。
-W 或 --password：提示输入密码以验证连接。
-j 或 --jobs：通过指定并发作业数来启用并行备份。
-F 或 --format：指定备份文件的输出格式。可用的格式有 plain（默认）、custom、directory 和 tar。
例如，要使用用户名和密码验证创建 tar 格式的电子商务数据库备份，您可以运行
pg_dump -U postgres -W -F tar ecommerce -f /tmp/ecommerce_backup.tar
在这个例子中
-F tar 指定 tar 格式，它创建一个未压缩的 tar 归档文件。
输出文件扩展名是 .tar，以反映 tar 格式。
需要注意的是，当使用 pg_dump 进行迁移时，您应该使用 custom 或 directory 格式，因为它们提供了额外的功能，如压缩和并行恢复。您可以在PostgreSQL 文档中找到可用选项的完整列表。
除了 pg_dump 之外，PostgreSQL 还提供了 pg_dumpall，它可以创建整个 PostgreSQL 集群的逻辑备份，包括所有数据库、角色和其他集群范围的对象。
pg_dump 和 pg_dumpall 之间的关键区别在于，pg_dumpall 包括集群级对象（如用户角色和权限），而 pg_dump 则专注于单个数据库。
要使用 pg_dumpall 创建整个集群的逻辑备份，您可以使用以下命令
pg_dumpall -U postgres -W -f /tmp/cluster_backup.tar
此命令将生成一个 SQL 脚本，其中包含重新创建所有数据库、角色和其他集群范围对象的命令。
请注意多个密码提示。pg_dumpall 将连接到每个数据库，因此每次数据库连接都会出现密码提示。这是使用密码验证时的默认行为。但是，如果有多个数据库，则可以使用 passfile 选项。
使用 pg_dump 和 pg_dumpall，您可以创建 PostgreSQL 数据库和集群的全面逻辑备份，确保您拥有恢复数据库环境所需的数据和配置。
使用 pg_dump 创建逻辑备份后，您可以使用 pg_restore 从该备份文件重建数据库。pg_restore 是一个强大的工具，允许您恢复整个数据库或其特定部分，从而在恢复过程中为您提供灵活性。
让我们将这些示例与上一节联系起来，在上一节中，我们使用 pg_dump 创建了电子商务数据库的逻辑备份。我们将使用该备份文件来演示如何使用 pg_restore。
简单示例要从备份文件恢复整个电子商务数据库，可以使用以下命令
pg_restore -d ecommerce ecommerce_backup.sql
此命令假定目标数据库电子商务已存在，并将恢复数据。如果数据库不存在，则需要先创建它。
带选项的示例
pg_restore 提供了几个选项来自定义恢复过程。以下是一些重要的选项
-c 或 --clean：在重新创建数据库对象之前删除它们。这可以确保干净的恢复。
-C 或 --create：在恢复数据之前创建目标数据库。
-j 或 --jobs：指定并行恢复的并发作业数。
以下示例将从上一节中创建的备份文件恢复电子商务数据库
pg_restore -U postgres -W -C -c --if-exists -d postgres /tmp/ecommerce_backup.tar
在这个例子中，
-C：此选项告诉 pg_restore 在恢复数据之前创建数据库。如果数据库已存在，pg_restore 将退出并显示错误，除非还指定了 --if-exists 选项。
-c：此选项为恢复指定“clean”模式。它告诉 pg_restore 在重新创建数据库对象（表、函数等）之前删除它们。这可以确保恢复的数据库处于干净状态，并与备份文件的结构相匹配。
--if-exists：此选项与 -C 选项一起使用。它告诉 pg_restore 忽略正在创建的数据库已存在时的错误。如果数据库存在，pg_restore 将继续进行恢复，而不会尝试再次创建它。
-d postgres：此选项指定最初要连接到的数据库的名称。在本例中，它是 Postgres 数据库，它是 PostgreSQL 安装中通常存在的默认数据库。pg_restore 需要连接到现有数据库才能创建备份文件中指定的新数据库。
/tmp/ecommerce_backup.tar：这是包含数据库转储的备份文件的路径。它应该是由 pg_dump 以“tar”格式创建的有效备份文件。
您可以在PostgreSQL 文档中找到可用选项的完整列表。
当您运行 pg_restore 时，它将按照以下步骤重建数据库
读取备份文件：pg_restore 读取指定的备份文件，该文件包含由 pg_dump 生成的 SQL 命令。
创建数据库（可选）：如果使用了 -C 选项，pg_restore 会在继续恢复之前创建目标数据库。
删除现有对象（可选）：如果使用了 -c 选项，pg_restore 会在重新创建数据库对象之前删除任何现有的数据库对象。
执行 SQL 命令：pg_restore 执行备份文件中的 SQL 命令，以重新创建数据库对象，如表、索引、约束和数据。
并行处理（可选）：如果使用了 -j 选项，pg_restore 会利用多个作业并行执行 SQL 命令，从而加快恢复过程。pg_restore 中可以使用 custom 或 directory 归档格式进行并行处理。
在整个恢复过程中，pg_restore 在重建数据库的特定部分方面提供了灵活性。您可以使用 -t 或 --table 等选项仅恢复特定表，使用 -n 或 --schema 恢复特定模式，等等。这允许您有选择地恢复数据库的所需部分。
此外，如果您使用 pg_dumpall 创建了整个 PostgreSQL 集群的逻辑备份，则可以使用 pg_restore 重建整个集群，包括所有数据库和集群范围对象。
通过了解 pg_restore 的工作原理，并考虑到这些限制，您可以有效地从逻辑备份重建数据库，确保数据恢复和迁移能力。
让我们探讨和讨论 pg_restore 的具体用例。
pg_restore 的主要用例之一是系统迁移。当您需要将 PostgreSQL 数据库移动到不同的服务器、升级到较新版本或切换到不同的数据库系统时，由 pg_dump 创建并使用 pg_restore 恢复的逻辑备份可能是一个可行的解决方案。
逻辑备份基于 SQL 的结构允许在不同的 PostgreSQL 版本之间，甚至到其他符合 SQL 的数据库轻松传输。pg_restore 可以处理目标系统上的数据库对象重新创建和数据插入，从而简化迁移过程。
但是，需要注意的是，使用逻辑备份迁移大型数据库可能非常耗时且资源密集型。复制或并行恢复等迁移技术可能更适合。
pg_restore 的另一个有价值的用例是部分还原。有时，您可能只需要还原数据库的特定部分，而不是整个数据库。 pg_restore 提供了过滤器和选项，可以选择性地还原单个表、模式或其他数据库对象。
例如，您可以使用 -t 或 --table 选项仅还原特定表，或者使用 -n 或 --schema 选项还原特定模式内的对象。当恢复特定数据或解决与特定数据库对象相关的问题时，这种对还原过程的精细控制非常有用。
关于逻辑备份和还原工具（如 pg_restore）的优缺点。
灵活的格式：pg_dump 创建的逻辑备份可以采用多种格式进行格式化，例如纯 SQL、自定义存档或目录格式。这种灵活性允许更轻松地操作和自定义备份文件。
将数据库完全还原到最新状态：逻辑备份会捕获数据库在备份时的完整状态。当使用 pg_restore 还原时，数据库将重建到备份时的确切状态，包括所有数据和架构对象。相反，物理还原只能将数据库还原到固定的保存点。
适用于迁移和更新：当将数据库迁移到较新版本的 PostgreSQL 或在不同数据库系统之间移动数据时，逻辑备份特别有用。逻辑备份基于 SQL 的特性使其在不同 PostgreSQL 版本之间，甚至与其他兼容 SQL 的数据库之间兼容。
支持部分还原：pg_restore 允许选择性地还原特定的数据库对象，例如表、模式或函数。当您只需要还原数据库的子集而不是整个数据库时，此功能非常方便。
还原过程较慢：使用 pg_restore 从逻辑备份还原数据库可能比从物理备份还原慢。还原过程涉及执行 SQL 命令以重新创建数据库对象并插入数据，这对于大型数据库而言可能非常耗时。
需要计算资源：pg_restore 需要执行备份文件中的 SQL 命令，这需要目标数据库服务器上的 CPU 和内存资源。这可能会在还原过程中影响服务器的性能。
大型数据库的挑战：pg_restore 的逻辑备份和还原在处理大型数据库时可能会遇到困难。生成备份文件和在还原过程中执行 SQL 命令可能会花费大量时间和资源，这使得它不太适用于具有 TB 级数据的数据库。
让我们看一个使用 pg_restore 和过滤器从数据库备份中重建特定表的示例。假设我们有一个名为 ecommerce_backup.tar 的逻辑备份文件，其中包含我们电子商务数据库的备份。
要查看备份文件的目录，可以使用 -l 或 --list 选项
pg_restore -l ecommerce_backup.tar
此命令将显示备份文件中所有对象的列表。
要仅还原特定表，您可以创建一个列表文件，其中包含要还原的表的名称。例如，我们只想还原 products 和 customers 表。
首先，让我们将备份文件的内容输出到 restore_list.txt
pg_restore -l ecommerce_backup.tar > restore_list.txt
然后，您可以保留要还原的对象。在本例中，我们将只保留两个表。
215; 1259 17198 TABLE public customers postgres
217; 1259 17202 TABLE public order_items postgres
然后，使用 -L 或 --use-list 选项指定列表文件
pg_restore -U postgres -W -d ecommerce -L restore_list.txt ecommerce_backup.tar
此命令将仅从备份文件中将 order_items 和 customers 表还原到电子商务数据库中。
您可以使用 -n 或 --schema 选项还原特定模式内的对象。例如，仅还原 public 模式中的对象
pg_restore -U postgres -W -d ecommerce -n public ecommerce_backup.tar
使用 -N 或 --exclude-schema 选项排除特定模式内的对象。例如，要从还原中排除 temp 模式：
pg_restore -U postgres -W -d ecommerce -N temp ecommerce_backup.tar
此命令将还原备份文件中的所有对象，但属于 temp 模式的对象除外。
这些示例演示了 pg_restore 如何根据您的需求灵活地选择性还原数据库的特定部分。
让我们探讨一个使用 pg_restore 将 PostgreSQL 数据库迁移到 Timescale 的示例。Timescale 是一个时间序列数据库，它扩展了 PostgreSQL，增加了处理时间序列数据的额外功能。
要使用 pg_restore 将 PostgreSQL 数据库迁移到 Timescale，请按照 Timescale 文档 中概述的步骤操作。
以下是一些需要牢记的关键注意事项
角色管理：在转储数据之前，单独处理角色和权限非常重要。您可以将 pg_dumpall 与 --roles-only 选项一起使用，以从源 PostgreSQL 数据库转储角色。
模式和数据转储：使用 pg_dump 创建源数据库模式和数据的逻辑备份。但是，您必须指定某些标志以确保与 Timescale 兼容。
--no-tablespaces：Timescale 对表空间支持有限制，因此此标志是必需的。
--no-owner 和 --no-privileges：这些标志是必需的，因为 Timescale 的默认用户 tsdbadmin 不是超级用户，并且与 PostgreSQL 的默认超级用户相比权限受限。
使用并发进行还原：当对 pg_dump 和 pg_restore 使用目录格式时，您可以利用并发来加快还原过程。但是，由于权限不足，并发加载 _timescaledb_catalog 模式可能会导致错误。要解决 此问题，请先串行加载 _timescaledb_catalog 模式，然后再并发加载数据库的其余部分。
迁移后任务：加载数据后，建议通过对所有数据运行 ANALYZE 来更新表统计信息。这有助于优化 Timescale 中的查询性能。
验证和应用程序设置：在将应用程序与迁移后的数据库一起上线之前，请彻底验证数据完整性并确保迁移成功。
重要的是要注意，使用 pg_dump 和 pg_restore 迁移大型数据库可能非常耗时，并且可能需要应用程序停机。对于大于 100 GB 的数据库，Timescale 建议使用他们的 实时迁移 策略来实现低停机时间迁移解决方案。
此外，请记住，迁移到 Timescale 可能需要额外的步骤，以便在迁移完成后启用 Timescale 特定的功能，例如超表、数据压缩和保留策略。
本指南探讨了 pg_restore 的多功能性，它是 PostgreSQL 的逻辑备份和恢复工具。我们已经了解了 pg_restore 如何与 pg_dump 协同工作以创建和还原逻辑备份，从而提供对还原过程的灵活性和粒度控制。
pg_restore 的一些主要优势在于它能够促进系统迁移和部分数据库还原。无论您是需要将 PostgreSQL 数据库迁移到较新版本、在不同系统之间移动数据，还是有选择地还原特定对象，pg_restore 都提供了轻松完成这些任务的工具和选项。
但是，需要注意的是，对于大多数实际工作负载，尤其是涉及较大数据库或需要最小停机时间的工作负载，逻辑复制通常是系统迁移的推荐方法。
如果您正在处理时间序列数据并考虑迁移到专门的时间序列数据库（如 Timescale），那么 pg_restore 可能很有价值。这使您能够使用 Timescale 的强大功能，例如超表、数据压缩和保留策略，来优化您的时间序列工作负载并实现最大的效率。
要亲身体验 Timescale 的优势，请立即免费试用。创建您的帐户 并探索专用时间序列数据库的可能性。
了解更多关于迁移策略的信息