PostgreSQL 教程: 使用 PAF 实现自动故障转移

十一月 12, 2024

摘要：在本教程中，我们将深入探讨 ClusterLabs 的 PostgreSQL 自动故障转移（PAF）解决方案。

PostgreSQL 自动故障转移

PostgreSQL 自动故障转移（PAF），是 ClusterLabs 为 PostgreSQL 提供的高可用管理解决方案。PAF 利用流行的行业内标准的 Pacemaker 和 Corosync 技术栈。结合使用 Pacemaker 和 Corosync，您将能够检测系统中的故障，并采取相应的措施。

Pacemaker 能够在其资源代理的帮助下，实现对许多资源的管理。然后，资源代理负责处理特定资源、让它们应该如何表现，并将结果通知 Pacemaker。

您的资源代理的实现，必须符合开放集群框架（OCF）规范。该规范定义了资源代理的行为，以及停止、启动、升主、降备和与 Pacemaker 交互等方法的实现。

PAF 是一个用 Perl 编写的适用于 PostgreSQL 的 OCF 资源代理。使用内部流复制构建 PostgreSQL 集群后，PAF 能够向 Pacemaker 提供每个节点上 PostgreSQL 实例的当前状态：主数据库、从数据库、已停止、同步追赶中等。

运作方式

PAF 会与 Pacemaker 就集群状态进行通信，并监控 PostgreSQL 的运行情况。如果发生故障，它会通知 Pacemaker，如果当前的主数据库没有机会恢复，它将触发在当前的备用服务器之间进行选主。有了强大的 Pacemaker，PAF 将在所有 PostgreSQL 节点上执行管理操作，例如启动、停止、监控和故障转移。

有没有任何设置要求？

PAF 支持 PostgreSQL 版本 9.3 及更高版本。
PAF 不负责 PostgreSQL 主和备用数据库的创建或设置，您必须在使用 PAF 之前创建和设置好流复制。
PAF 不会编辑 Postgres 的任何配置。但是，它要求用户遵循一些先决条件，例如：
- 从数据库必须配置为热备状态。
- 必须提供恢复的模板文件（默认值：<PostgreSQL 数据目录路径>/recovery.conf.pcmk），指定以下参数：
  - standby_mode = on
  - recovery_target_timeline = ’latest'
  - primary_conninfo 中必须定义 application_name 参数，并将其设置为本地节点名称，和在 Pacemaker 中一样。
PAF 提供了与 PostgreSQL 资源管理相关的多个参数。这可以根据自己的要求进行配置。以下是参数：
- bindir：PostgreSQL 二进制文件的位置（默认值：/usr/bin）
- pgdata：实例数据目录 PGDATA 的位置（默认值：/var/lib/pgsql/data）
- datadir：postgresql.conf 文件中 data_directory 参数设置的目录路径
- pghost：用于连接到本地实例的套接字目录或 IP 地址（默认值：/tmp）
- pgport：连接本地实例的端口（默认值：5432）
- recovery_template：将会复制为 PGDATA/recovery.conf 文件的本地模板。此模板文件必须存在于所有节点上（默认值：$PGDATA/recovery.conf.pcmk）
- start_opts：启动时为 Postgres 进程提供的其他参数。有关可用选项，请参阅 “postgres --help”。当 postgresql.conf 文件不在数据目录（PGDATA）中时很有用，例如： -c config_file=/etc/postgresql/9.3/main/postgresql.conf
- system_user：实例进程的系统所有者（默认值：postgres）
- maxlag：在我们给备用数据库设置负的选主评分之前，所允许的最大延迟

PAF 优点

PAF 为用户提供了灵活实用的 PostgreSQL 配置和设置。
PAF 可以处理节点故障，并在主服务器宕机时触发选举。
可以在 PAF 中强制实施仲裁行为。
它将为资源提供完整的高可用管理解决方案，包括启动、停止和监控，并处理网络隔离场景。
它是一种分布式解决方案，支持从其中一个节点管理任何节点。

PAF 缺点

PAF 不会检测备用节点是否在恢复配置中错误配置了未知或不存在的节点。节点将显示为从节点，即使备用节点正在运行，而未连接到主节点/级联备节点。
需要启用一个额外的端口（默认为 5405），以便使用 UDP 进行 Pacemaker 和 Corosync 组件的通信。
不支持基于 NAT 的配置。
不支持 pg_rewind。

高可用测试场景

我们进行了一些测试，以确定使用 PAF 进行 PostgreSQL 高可用管理的能力。所有这些测试都是在应用程序运行并将数据插入 PostgreSQL 数据库时运行的。该应用程序是使用 PostgreSQL 的 Java JDBC 驱动程序编写的，该应用程序利用了驱动的连接故障转移功能。

备用服务器测试

测试场景	观察
终止 PostgreSQL 进程	Pacemaker 将 PostgreSQL 进程恢复到运行状态。应用程序写入数据没有中断。
停止 PostgreSQL 进程	Pacemaker 将 PostgreSQL 进程恢复到运行状态。应用程序写入数据没有中断。
重新启动服务器	备用服务器最初被标记为离线状态。服务器重新启动运行后，PostgreSQL 将由 Pacemaker 启动，并且服务器被标记为在线状态。如果启用了隔离，则不会将节点自动添加到集群中。应用程序写入数据没有中断。
停止 Pacemaker 进程	它还将停止 PostgreSQL 进程，并且服务器将被标记为离线状态。应用程序写入数据没有中断。

主服务器测试

测试场景	观察
终止 PostgreSQL 进程	Pacemaker 将 PostgreSQL 进程恢复到运行状态。在阈值时间内恢复了主数据库，因此未触发选主。应用程序写入数据中断了大约 26 秒。
停止 PostgreSQL 进程	Pacemaker 将 PostgreSQL 进程恢复到运行状态。在阈值时间内恢复了主数据库，因此未触发选主。应用程序写入数据中断了大约 26 秒。
重新启动服务器	在主服务器不可用的阈值时间后，Pacemaker 触发了选主。最符合条件的备用服务器被提升为新的主服务器。旧的主服务器重新启动运行后，它将被作为备用服务器添加回集群中。如果启用了隔离，则不会将节点自动添加到集群中。应用程序写入数据中断了大约 26 秒。
停止 Pacemaker 进程	它还将停止 PostgreSQL 进程，服务器将被标记为离线状态。将触发选主，并选举新的主服务器。应用程序写入数据出现了中断。

网络隔离测试

测试场景	观察
将备用服务器与其他服务器之间的网络隔离	Corosync 通信在备用服务器上被阻止了。服务器被标记为离线状态，并且 PostgreSQL 服务由于仲裁策略而关闭。应用程序写入数据没有出现中断。
将主服务器与其他服务器之间的网络隔离（脑裂场景）	Corosync 通信在主服务器上被阻止了。由于仲裁策略，PostgreSQL 服务已关闭，主服务器被标记为离线状态。在大范围的选区内选举了一个新的主服务器。应用程序写入数据出现了中断。

其他测试

测试场景	观察
通过关闭所有备用服务器来退化集群。	当所有备用服务器都宕机时，由于仲裁策略，主服务器上的 PostgreSQL 服务会停止。在此测试之后，当所有备用服务器都恢复运行后，会选择一个新的主服务器。应用程序写入数据出现了中断。
从主服务器开始，一个接一个地随机关闭所有服务器，然后同时将它们全部运行起来	所有服务器都启动并加入集群。选举了新的主服务器。应用程序写入数据出现了中断。

推论

PostgreSQL 自动故障转移，在处理 PostgreSQL 高可用方面具有多项优势。在故障转移发生期间，PAF 使用 IP 地址故障转移，而不是重新启动备用数据库，来连接到新的主数据库。在用户不想重启备用节点的情况下，这被证明是有利的。PAF 也只需要很少的人工干预，即可管理所有资源的整体运行状况。唯一需要手动干预的情况是，时间线不同时，用户可以选择使用 pg_rewind。