2 .安装 Pgpool-II
2.1. 规划
由于 Pgpool-II 是一个管理 PostgreSQL 的工具，我们需要决定如何 首先部署它们。此外，还可以有多个 Pgpool-II 安装数量达到 增强 Pgpool-II 本身的可用性。我们需要提前计划需要多少次 Pgpool-II 安装。在 本章我们首先讨论 PostgreSQL 的运行模式，然后是 Pgpool-II 的部署。
2.1.1. PostgreSQL 的集群模式
可以有多个或等于一个 PostgreSQL 安装，通常有更多的 而不是 2 次安装，因为如果只有一个 安装后，如果 PostgreSQL 不可用，则整个数据库系统都会宕机。当我们 使用两个或多个 PostgreSQL 服务器，它 对于以某种方式同步数据库是必需的。我们调用 将数据库同步为 “clustering running mode” 的方法。这 有史以来最流行的模式是 “流复制模式”。 除非有必要有特别的考虑，否则它是 推荐使用流式复制模式。有关运行模式的更多详细信息，请参见 Section 3.3.2 。
接下来我们需要考虑的是我们需要多少个 PostgreSQL 安装。如果 有两个，我们可以继续操作数据库 系统。但是，如果您想使用 read ，使用两个以上的 PostgreSQL 并不少见 通过对多个 read quires 运行多个 read quire 来查询负载平衡 服务器。Pgpool-II 提供丰富的 用于调整负载均衡的各种选项。有关更多详细信息，请参阅 Section 5.8 。
由于稍后可以在 Pgpool-II 中添加 PostgreSQL 服务器，因此两个 PostgreSQL 可以是一个很好的起点 你。
2.1.2. 部署 Pgpool-II
虽然可以只使用一个 Pgpool-II，但我们建议使用更多 比 1 个 Pgpool-II 避免整个 由于 Pgpool-II 宕机而导致的数据库不可用。多个 Pgpool-II 协同工作并监控 彼此。其中一个称为“leader”，它有一个虚拟的 IP 的 IP 文件。客户端不需要知道有多个 Pgpool-II，因为它们总是访问 同一个 VIP。（参见第 4.1 节 watchdog） 的如果 Pgpool-II 中的一个 down，其他 Pgpool-II 接管 leader 角色。
由于不允许有多个 leader，因此 watchdog 投票给 决定新的领导者。如果 Pgpool-II 的数量为偶数，则无法决定 通过投票成为新的领导人。因此，我们建议部署大于或等于 3 个奇数的 Pgpool-II。
请注意，Pgpool-II 和 PostgreSQL 可以在同一台服务器上。为 例如，你只能有 3 个服务器来运行 Pgpool-II 和 PostgreSQL。
您可以在流式复制中找到使用三个 Pgpool-II 和两个 PostgreSQL 的生产级详细示例 mode 为那些想要 今天有一个生产级别的 Pgpool-II 安装。
2.2. 安装 Pgpool-II
本章介绍安装 Pgpool-II 的。首先，安装 解释了源代码分发。然后从 RPM 安装 packages 的
2.3. 要求
一般来说，一个现代的 Unix 兼容平台应该能够运行 Pgpool-II。不支持 Windows。
构建 Pgpool-II 需要以下软件包：
需要 GNU make 版本 3.80 或更高版本;其他 make 程序或较旧的 GNU make 版本将不起作用。 （GNU make 有时安装在 名称 gmake。要测试 GNU make enter：
make --version
您需要一个 ISO/ANSI C 编译器（至少 符合 C89 标准）。最近 推荐使用 GCC 版本，但已知 Pgpool-II 使用各种各样的 来自不同供应商的编译器。
需要 tar 来解压缩源 发行版。
需要多个 PostgreSQL 软件包才能 安装 Pgpool-II。您安装 postgresql-libs 和 PostgreSQL-devel 软件包。
如果你从 Git 树而不是 Git 树构建 使用已发布的源码包，或者如果您想进行服务器开发， 您还需要以下软件包：
需要 Flex 和 Bison 才能从 Git 签出进行构建，或者如果您更改了实际的 scanner 和 parser 定义文件。如果您需要它们，请确保 以获取 Flex 2.5.31 或更高版本以及 Bison 1.875 或更高版本。不能使用其他 lex 和 yacc 程序。
如果你需要获取 GNU 软件包，你可以找到 它位于您本地的 GNU 镜像站点（参见 http://www.gnu.org/order/ftp.html 的列表）或 ftp://ftp.gnu.org/gnu/。
还要检查您是否有足够的磁盘空间。您将需要大约 编译期间源代码树为 40 MB，编译期间源代码树约为 20 MB 安装目录。如果你要 运行回归测试，您暂时需要最多一个额外的 4 GB。使用 df 命令检查可用磁盘 空间。
2.4. 获取源码
Pgpool-II 4.5.5 源码可以获取 从我们的 网站： http://www.pgpool.net。您应该 获取文件 命名 pgpool-II-4.5.5.tar.gz。在您之后 获取到文件后，解压：
tar xf pgpool-II-4.5.5.tar.gz
这将在当前目录下创建一个目录 pgpool-II-4.5.5 与 Pgpool-II 源码一起使用。 更改为该目录以获取其余部分 的安装过程。
2.5. 安装 Pgpool-II
解压源 tarball 后，按照以下步骤构建 源代码并安装 Pgpool-II。
从 Pgpool-II 4.5 开始，由 autoconf/autoreconf 生成的 configure 等文件已经从仓库中删除，因此首先运行 autoreconf -fi 来生成 configure。
dnf install libtoolcd pgpool-II-4.5.5
autoreconf -fi
接下来，执行 configure 脚本。
./configure
您可以通过提供一个 或以下更多命令行选项进行配置：
–prefix=路径
指定 Pgpool-II 二进制文件和相关 将安装 docs 等文件。默认值为 /usr/local。
–with-pgsql=路径
指定 PostgreSQL 的客户端库所在的顶级目录 安装。默认值是pg_config命令提供的路径。
–带有 openssl
将构建 Pgpool-II 二进制文件 支持 OpenSSL。如果您打算 使用 AES256 加密加密密码，您需要此选项 太。有关更多信息，请参见 Section 6.4 详。OpenSSL 支持是 默认情况下处于禁用状态。
–enable-sequence-lock
使用 insert_lock 兼容 带 Pgpool-II 3.0 系列 （3.0.4 之前）。Pgpool-II 锁 针对序列中的一行 桌子。PostgreSQL 8.2 或更高版本 在 2011 年 6 月之后发布的 API 不能使用此锁 方法。
–enable-table-lock
使用 insert_lock 兼容 使用 Pgpool-II 2.2 和 2.3 系列。Pgpool-II 锁 针对 Insert Target 表。这种锁定方式是 已弃用，因为它会导致锁冲突 带真空。
–with-memcached=路径
Pgpool-II 二进制文件将在 memory query cache 的 CACHE 查询。您必须 安装 libmemcached。
–带 pam
Pgpool-II 二进制文件将构建 PAM 身份验证支持。 默认情况下，PAM 身份验证支持处于禁用状态。
编译源文件。
make
安装 pgpool-II。
make install
这将安装 Pgpool-II。（如果您使用 Solaris 或 FreeBSD，请将 make 替换为 gmake)
2.6. 安装 pgpool_recovery
Pgpool-II 需要 、 和 、 的函数 当您使用描述后者的 Online Recovery 时。 还有管理工具的 pgpoolAdmin，通过使用 停止、重启或重新加载屏幕上的 PostgreSQL。 如果这些函数先安装在 template1 中就足够了。这些 不需要在所有数据库中安装的功能。pgpool_recoverypgpool_remote_startpgpool_switch_xlogpgpool_pgctl
这在所有 Pgpool-II 安装中都是必需的。
$ cd pgpool-II-4.5.5/src/sql/pgpool-recovery
$ make
$ make install
在此之后：
$ psql template1
=# CREATE EXTENSION pgpool_recovery;
或
$ psql -f pgpool-recovery.sql template1
使用 Pgpool-II 3.3 或更高版本，你需要 调整 postgresql.conf。假设路径 pg_ctl的是 /usr/local/pgsql/bin/pg_ctl。那么你 将以下内容添加到 postgresql.conf 中。
pgpool.pg_ctl = '/usr/local/pgsql/bin/pg_ctl'可能您希望在此之后执行以下内容：
$ pg_ctl reload -D /usr/local/pgsql/data
2.7. 安装 pgpool-regclass
如果您使用的是 PostgreSQL 9.4 或 稍后，您可以跳过此部分。
如果您使用的是 PostgreSQL 8.0 到 PostgreSQL 9.3，在 上安装 强烈建议 Pgpool-II 访问所有 PostgreSQL，因为 它被 Pgpool-II 内部使用。 如果没有这个，在不同 架构可能会导致麻烦（临时表不是问题）。 如果您使用的是 PostgreSQL 9.4 或 稍后，安装不是 necessary 的，因为等效的 （） 包含在 PostgreSQL 核心中。pgpool_regclasspgpool_regclassto_regclass
$ cd pgpool-II-4.5.5/src/sql/pgpool-regclass
$ make
$ make install在此之后：
$ psql template1
=# CREATE EXTENSION pgpool_regclass;或
$ psql -f pgpool-regclass.sql template1
应执行 CREATE EXTENSION 或 pgpool-regclass.sql 在每个访问的数据库上 通过 Pgpool-II。但是，您不需要 对于在执行 CREATE EXTENSION 或 psql -f pgpool-regclass.sql template1 后创建的数据库，执行此操作。 因为此模板数据库将被克隆以创建新数据库。
2.8. 创建 insert_lock 表
如果您不打算使用 本机复制模式和快照隔离模式，您可以跳过此项 部分。
如果您计划使用原生复制模式或快照隔离模式，并且insert_lock， 创建 pgpool_catalog.insert_lock 表 强烈建议进行互斥。没有这个， 到目前为止，insert_lock有效。然而，在那个 case Pgpool-II 锁在插入物上 目标表。此行为是相同的表锁冲突 使用 VACUUM，因此 INSERT 处理可能会保持等待很长时间。
$ cd pgpool-II-4.5.5/src/sql
$ psql -f insert_lock.sql template1
执行 insert_lock.sql 应该是 对访问的每个数据库执行 通过 Pgpool-II。您无需 对于执行 psql -f insert_lock.sql template1 后创建的数据库执行此操作，如下所示 模板数据库将被克隆以创建新数据库。
2.9. 编译和安装文档
2.9.1. 工具集
Pgpool-II 文档是用 SGML（更准确地说，DocBook，这是一种实现的语言 使用 SGML）。要生成可读的 HTML 文档，您需要 使用 Docbook 工具编译它们。要在 上安装 Docbook 工具 RHEL 或类似系统，请使用：
dnf install --enablerepo=powertools docbook-dtds docbook-style-dsssl docbook-style-xsl libxslt openjade
2.9.2. 编译文档
在系统上安装工具集后，您可以编译文档：
$ cd doc
$ make
$ cd ..
$ cd doc.ja
$ make
您将在 doc/src/sgml/html 下看到英文 HTML 文档，在 sgml/man 下看到在线文档[1-8]。 日文文档可以在 doc.ja/src/sgml/html 下找到，在线文档可以在 sgml/man 下找到[1-8]。
2.10. 从 RPM 安装
本章描述了从 RPM 安装 Pgpool-II。 如果您打算从源代码安装，请查看 Section 2.2。
Pgpool-II 社区为 RHEL9/8/7 提供 RPM 软件包 以及与 RHEL 兼容的操作系统。 你可以从官方的 Pgpool-II 仓库下载包文件。
Pgpool-II 官方仓库包含以下软件包：
表 2-1.pgpool-II RPM 软件包
| 包 | 描述 |
|---|---|
| pgpool-II-pgXX | 运行 Pgpool-II 所需的库和二进制文件 |
| pgpool-II-pgXX-extensions | 必须在所有 PostgreSQL 服务器上安装此软件包才能使用在线恢复功能 |
| pgpool-II-pgXX-debuginfo | 用于调试的调试符号 |
| pgpool-II-pgXX-debug源 | 仅适用于 RHEL8/9。用于调试的调试符号 |
| pgpool-II-pgXX-extensions-debuginfo | 仅适用于 RHEL8/9。用于调试的调试符号 |
| pgpool-II-pgXX-devel | 面向开发人员的头文件 |
Pgpool-II 需要 PostgreSQL 的 library 和 extensions 目录下。由于目录路径不同 对于特定的 PostgreSQL 版本，Pgpool-II 为每个 PostgreSQL 版本提供了单独的软件包。 上述包中的“XX”是一个两位数的数字，表示 PostgreSQL 的版本。 选择与您的 PostgreSQL 版本对应的 Pgpool-II RPM。 （例如，如果你正在使用 PostgreSQL 16，你需要安装 pgpool-II-pg16)
2.10.1. 安装前
由于 Pgpool-II 相关的包也包含在 PostgreSQL YUM 仓库中， 如果已安装 PostgreSQL 存储库包，则 将「排除」设定加入 /etc/yum.repos.d/pgdg-redhat-all.repo， 这样 Pgpool-II 就不会从 PostgreSQL YUM 仓库安装。 如果 Pgpool-II 和 PostgreSQL 安装在不同的服务器上，你可以跳过本节。
vi /etc/yum.repos.d/pgdg-redhat-all.repo
以下是 /etc/yum.repos.d/pgdg-redhat-all.repo 的设置示例。
[pgdg-common]
...
exclude=pgpool*[pgdg16]
...
exclude=pgpool*[pgdg15]
...
exclude=pgpool*[pgdg14]
...
exclude=pgpool*[pgdg13]
...
exclude=pgpool*[pgdg12]
...
exclude=pgpool*[pgdg11]
...
exclude=pgpool*
2.10.2. 安装 RPM
这里我们使用 Pgpool-II 官方的 YUM 仓库安装 Pgpool-II。
以下命令假设您在 RHEL8 上使用 Pgpool-II 4.5.x for PostgreSQL 16。 如果您使用的是其他版本，请将 “pgXX” 替换为您的 PostgreSQL 版本。
首先，安装与你的 Pgpool-II 版本和发行版相对应的仓库。 对于 REHL7/9，请参阅此处。
dnf install https://www.pgpool.net/yum/rpms/4.5/redhat/rhel-8-x86_64/pgpool-II-release-4.5-1.noarch.rpm
然后，安装 Pgpool-II。
dnf install pgpool-II-pg16
要使用在线恢复功能，请在所有 PostgreSQL 服务器上安装 pgpool-II-pg16-extensions。 因为 pgpool-II-pgXX-extensions 依赖于 pgpool-II-pgXX 软件包， 如果 pgpool-II 和 PostgreSQL 安装在不同的服务器上，pgpool-II-pgXX 也需要安装 在 PostgreSQL 服务器上。
注意： pgpool-II-pgXX-extensions 需要安装在 PostgreSQL 服务器上。 如果 Pgpool-II 和 PostgreSQL 安装在不同的服务器上，则 不需要在运行 Pgpool-II 的服务器上安装它。
dnf install pgpool-II-pg16-extensions pgpool-II-pg16
（可选）如有必要，您可以为开发人员安装 debuginfo 和 devel 软件包。
dnf install pgpool-II-pg16-debuginfo pgpool-II-pg16-devel
2.10.3. 配置 pgpool-II
所有 Pgpool-II 配置文件 安装在 /etc/pgpool-II 中。请参考 到 Section 3.3 了解如何设置 配置文件。
2.10.4. 启动/停止 Pgpool-II
在 RHEL9/8/7 上，如果设置了 Pgpool-II 的自动启动，请执行一次。
systemctl enable pgpool.service
在此之后，要启动 Pgpool-II， 运行以下命令或重新启动整个系统。 请注意，在此之前必须启动 PostgreSQL 服务器。
systemctl start pgpool.service
要停止 Pgpool-II，请执行一次。 请注意，Pgpool-II 必须停止 在停止 PostgreSQL 之前。
systemctl stop pgpool.service
在此之后，您可以停止 PostgreSQL 服务器。
2.11. 安装提示
本章收集了安装 Pgpool-II 的随机技巧。
2.11.1. 防火墙
当 Pgpool-II 连接到 其他 Pgpool-II 服务器 或 PostgreSQL 服务器，则目标端口 必须通过启用防火墙管理软件来访问。
首先，允许访问 Pgpool-II 使用的端口。 在下面的例子中，让 Pgpool-II 监听 端口号为 9999，PCP 侦听 端口号为 9898，看门狗 listen port number 为 9000 和 heartbeat listen port number 为 9694. 请注意，只有心跳端口使用 UDP，而其他端口使用 TCP。
firewall-cmd --permanent --zone=public --add-port=9999/tcp --add-port=9898/tcp --add-port=9000/tcp
firewall-cmd --permanent --zone=public --add-port=9694/udp
firewall-cmd --reload
以下是 CentOS/RHEL7 在 设置为 PostgreSQL。
firewall-cmd --permanent --zone=public --add-service=postgresql
firewall-cmd --reload
“PostgreSQL” 是分配的服务名称 到 PostgreSQL。服务一览 名称可以通过以下方式获得：
firewall-cmd --get-services
请注意，您可以在 /usr/lib/firewalld/services/ 中。
如果 PostgreSQL 正在侦听 11002 port 而不是标准的 5432 端口，您可以执行以下操作：
firewall-cmd --zone=public --remove-service=postgresql --permanent
firewall-cmd --zone=public --add-port=11002/tcp --permanent
firewall-cmd --reload
3.服务器设置和操作
3.1. Pgpool-II 用户账户
与任何可供外部世界访问的服务器守护程序一样， 建议在 单独的用户帐户。此用户帐户应仅拥有数据 由服务器管理，不应与其他 守护 进程。（例如，使用用户 nobody 是不好的 想法。不建议安装此公司拥有的可执行文件 用户，因为受感染的系统可以修改自己的 二进制文件。
要将 Unix 用户帐户添加到系统，请查找命令 useradd 或 adduser。用户 名称 pgpool 经常被使用，并且是假定的 在本书中，但如果您愿意，您可以使用其他名称。
3.2. 配置 pcp.conf
Pgpool-II 提供了一个接口 供管理员执行管理操作，例如 获取 Pgpool-II 状态或终止 Pgpool-II 进程 远程。pcp.conf 是用户/密码文件 用于此接口的身份验证。所有操作模式 需要设置 pcp.conf 文件。将创建一个 $prefix/etc/pcp.conf.sample 文件 安装期间 Pgpool-II 的。将文件复制为 $prefix/etc/pcp.conf 并添加您的用户名和密码 到它。
$ cp $prefix/etc/pcp.conf.sample $prefix/etc/pcp.conf
空行或以 # 开头的行被视为 注释，将被忽略。用户名及其关联的 密码必须使用以下格式写成一行：
username:[md5 encrypted password]
[MD5 加密密码] 可以使用 $prefix/bin/pg_md5 命令生成。
$ pg_md5 your_password
1060b7b46a3bd36b3a0d66e0127d0517
如果您不想将密码作为参数传递，请执行 pg_md5 -p。
$ pg_md5 -p
password: your_password
pcp.conf 文件必须可由 执行 Pgpool-II 的用户。
3.3. 配置 pgpool-II
3.3.1. 配置 pgpool.conf
pgpool.conf 是主要的配置文件 Pgpool-II 的。您需要指定 path 到文件 使用 -f 选项启动 Pgpool-II。pgpool.conf 位于 在 $prefix/etc/pgpool.conf 中， 如果它是从源代码安装的。
指定 Pgpool-II 集群 模式，设置 backend_clustering_mode 参数 的值。
表 3-1.backend_clustering_mode pgpool.conf 中的值
| Clustering mode | value |
|---|---|
| Streaming replication mode | streaming_replication |
| Replication mode | native_replication |
| Logical replication mode | logical_replication |
| Slony mode | slony |
| Snapshot isolation mode | snapshot_isolation |
| Raw mode | raw |
这些配置文件位于 /usr/local/etc 中，其中 从源代码进行默认安装。 你可以将其中一个复制为 pgpool.conf。 （可能您需要 root 权限）
#cd /usr/local/etc
#cp pgpool.conf.sample pgpool.conf
3.3.2. Pgpool-II 的集群模式
Pgpool-II 中有六种不同的集群模式：流式复制模式、逻辑 复制模式、主副本模式（SLONY 模式）、本机 复制模式、原始模式和快照隔离模式。在任何 模式中，Pgpool-II 提供了连接池，并且 自动故障转移。在线恢复只能与 流式复制模式、快照隔离模式和 Native 复制模式。有关在线恢复的更多详细信息，请参见 Section 5.11 。
这些模式彼此排斥，之后无法更改 启动服务器。您应该决定在 设计系统的早期阶段。如果您不确定，它 建议使用流式复制模式或 快照隔离模式。
可以使用流式复制模式 使用 PostgreSQL 服务器运行流式处理 复制。在此模式下，PostgreSQL 为 负责同步数据库。这种模式被广泛使用 以及最推荐的 Pgpool-II 使用方法。负荷 在该模式下可以进行平衡。可见性一致性 节点数。
在快照隔离模式下，Pgpool-II 负责同步 数据库。该模式的优点是同步是 done in synchronous way：写入数据库不会返回 直到所有 PostgreSQL 服务器都完成写入 操作。此外，它还保证了 节点。简单来说，就是 单个服务器上的事务应用于一个集群，包括 多个服务器。这是 Pgpool-II 中的 snapshot 隔离模式。事实上，快照 Pgpool-II 中的隔离模式是唯一的 保证节点之间可见性一致性的系统 目前没有对 PostgreSQL 进行修改。 因此，应用程序不需要识别它们 正在使用由 PostgreSQL 服务器组成的集群，而不是 单个 PostgreSQL 系统。然而，在 此模式的事务隔离级别必须为 可重复读取。您需要像这样设置 postgresql.conf：
default_transaction_isolation = 'repeatable read'
此外，您还需要注意该模式下的性能可能会更差 比流式复制模式和原生复制模式 由于开销，以保持事务的一致性。
在本地复制模式下，Pgpool-II 负责同步 数据库。该模式的优点是同步是 done in synchronous way：写入数据库不会返回 直到所有 PostgreSQL 服务器都完成写入 操作。由于节点之间的可见性一致性不是 保证，建议使用快照隔离模式 但您想使用 REPEATABLE READ 隔离模式以外的其他方式。 在该模式下可以进行负载均衡。
可以使用逻辑复制模式 使用 PostgreSQL 服务器进行逻辑操作 复制。在此模式下，PostgreSQL 为 负责同步表。可以进行负载均衡 在模式中。由于逻辑复制不会复制所有 表中，用户有责任复制 可以进行负载均衡。Pgpool-II 负载均衡 所有表。这意味着，如果表不是 replicad，Pgpool-II 可能会查找过时的表 在订阅者端。
主副本模式（slony 模式） 可与 PostgreSQL 服务器一起使用 经营 Slony。在这个 模式，则 Slony/PostgreSQL 为 负责同步 数据库。由于 Slony-I 已被 流式复制，我们不建议使用这种模式 除非你有特定的理由 使用 Slony。负载均衡可以在 模式。
在原始 模式中，Pgpool-II 并不关心 数据库同步。用户有责任做出 整个系统都在做一件有意义的事情。负载均衡 在 Mode 中是不可能的。
3.3.3. 进程管理模式
Pgpool-II 实现了一个多进程架构，其中 每个子进程在任何时候都可以处理一个客户端连接。 Pgpool-II 可以处理的并发客户端连接总数由 num_init_children config 参数配置。Pgpool-II 支持两种子进程管理模式。动态和静态。 在静态进程管理模式下，Pgpool-II 会预先分叉 num_init_children 个子项 进程，并且每个子进程都会继续侦听传入的 客户端连接。在动态进程管理模式下，Pgpool-II 会跟踪空闲的进程和 fork 或 kill 进程将此数字保持在指定的边界内。
process_management_mode 在 Pgpool-II V4.4 之前不可用。
3.4. 配置后端信息
为了让 Pgpool-II 识别 PostgreSQL 后端服务器，你需要在 pgpool.conf 中配置 backend*。首先，在 需要 least backend_hostname 和 backend_port 参数 设置为 Pgpool-II 服务器。
3.4.1. 后端设置
Pgpool-II 使用的后端 PostgreSQL 必须在 pgpool.conf 中指定。 参见 Section 5.5
3.5. 启动 Pgpool-II 和 PostgreSQL
要启动 Pgpool-II，请执行：
$ pgpool -f /usr/local/etc/pgpool.conf -F /usr/local/etc/pcp.conf
这将启动服务器在后台运行。“-f” 指定主 pgpool 配置文件的路径和 “-F” 指定 pcp server 的配置文件路径，该路径 是 Pgpool-II 的控制服务器。为 命令的其他选项请查看 pgpool 手册。
在启动 Pgpool-II 之前，你必须 启动 PostgreSQL，因为如果 PostgreSQL 还没有启动，Pgpool-II 会触发故障转移过程，并且 使 PostgreSQL 处于关闭状态。
如果你在控制 PostgreSQL 的启动顺序上有困难，比如 Pgpool-II 和 PostgreSQL 安装在不同的 servers 中，您可以延长search_primary_node_timeout（默认值为 5 分钟），以便 Pgpool-II 等待 PostgreSQL 启动，直到 search_primary_node_timeout 过期。如果 PostgreSQL 在 search_primary_node_timeout 过期之前启动，则 Pgpool-II 应该在没有 问题。如果 search_primary_node_timeout 在 PostgreSQL 启动之前过期，则不会 主节点，这意味着您无法执行 DML/DDL 的 DDL 中。在这种情况下，你需要重启 Pgpool-II。要确认主节点是否存在，您可以使用 SHOW POOL NODES 命令。
请注意search_primary_node_timeout可以 仅在流式复制模式下使用，因为 parameter 仅在 mode 中有效。有关流式传输的更多详细信息，请参阅 Section 3.3.2 复制模式。对于其他模式，调整健康检查（参见 第 5.9 节）参数，以便有 在 PostgreSQL 成为 可用。
如果健康检查检测到 PostgreSQL 在 Pgpool-II 启动之前不可用 up，则部分或全部 PostgreSQL 是 已识别为“关闭”状态。在这种情况下，您需要手动将 PostgreSQL 服务器处于 “up” 状态 using pcp_attach_node 命令。如果客户端尝试 在 PostgreSQL 可用之前连接到 Pgpool-II，故障转移可以 被触发。在这种情况下pcp_attach_node您还需要执行命令以将 PostgreSQL 服务器置于“up”状态。
3.6. 停止 pgpool-II 和 PostgreSQL
要停止 Pgpool-II，请执行：
$ pgpool -f /usr/local/etc/pgpool.conf -F /usr/local/etc/pcp.conf -m fast stop
“-m” 选项指定 Pgpool-II 停止的温和程度。“fast” 表示立即关闭 Pgpool-II，即使有 来自客户端的现有连接。您可以将 “smart” 指定为 选项，它强制 Pgpool-II 等待 直到所有客户端都与 Pgpool-II 断开连接。但这可能会让 Pgpool-II 永远等待，这可能会 导致从操作系统发送 SIGKILL 信号，并且 留下垃圾，下次启动 Pgpool-II 时会带来麻烦。
关闭 Pgpool-II 后，你可以 shutdown PostgreSQL 的 SQL 中。
3.7. 临时关闭 PostgreSQL
有时，您希望暂时停止或重新启动 PostgreSQL 以进行维护或升级 它。在本节中，如何以最少的停机时间执行任务。
3.7.1. 使用 pcp_detach_node 命令
如果你使用 pg_ctl 停止 PostgreSQL，故障转移不会发生，直到 Pgpool-II 通过运行状况检测到它 根据运行状况检查设置进行检查，这将需要 有时用于分离 PostgreSQL。 特别是如果 Watchdog 是 启用并且 failover_require_consensus 是开启的，那么 Pgpool-II 不会启动故障转移，直到 超过一半的看门狗节点同意 PostgreSQL 已停止。如果分离 节点通过使用 pcp_detach_node，故障转移将 无论运行状况检查的设置如何，立即启动。请 请注意，分离的 PostgreSQL 节点 实际上并未停止，如有必要，您需要手动 停下。
3.7.2. 使用 backend_flag
停止或重新启动 PostgreSQL 会导致故障转移。如果运行模式不是流式复制 模式，或者服务器是流复制中的备用服务器 模式，这可能没什么大不了的，因为客户端总是可以 使用集群中的其他服务器。但是，如果服务器是主服务器 server 时，会通过提升 备用服务器。此外，如果只剩下一台服务器 在集群中，没有备用服务器或备用服务器 可以推广。
在这种情况下，您可以使用 backend_flag 来避免 故障转移。通过在 pgpool.conf 中设置以下内容将避免 backend0 的
backend_flag0 = DISALLOW_TO_FAILOVER
这将在重新加载或重启 Pgpool-II 时生效。如果设置了此标志，则故障转移 如果后端不可用，则不会发生。虽然后端 不可用，客户端将收到错误消息：
psql: error: could not connect to server: FATAL: failed to create a backend connection
DETAIL: executing failover on backend
重启后端后，客户端可以照常连接。 要再次允许在后端进行故障转移，您可以设置：
backend_flag0 = ALLOW_TO_FAILOVER
并重新加载或重启 Pgpool-II。
3.8. 备份 PostgreSQL 数据库
如果您计划备份 PostgreSQL 数据库 使用 pg_dump、pg_basebackup 或任何其他工具，我们强烈建议您运行命令 直接针对 PostgreSQL。因为 Pgpool-II 是一个代理 软件，它会为中继消息数据包提供开销。因为 获取备份往往会产生大量数据包，执行 通过 Pgpool-II 进行备份会很慢 与直接相比 连接 PostgreSQL，除非 数据库非常小。
此外，如果 parallel pg_dump 是 通过 Pgpool-II 执行，因为 命令处理快照 ID，这是一个依赖于数据库的对象。
在大多数情况下，您希望选择主服务器作为备份服务器 目标。如果您想要备份备用服务器，您必须非常 在选择正确的 PostgreSQL 服务器来获取备份时要小心，因为如果数据过时，您 可能具有过时的数据库备份。您可以 使用 SHOW POOL NODES 或 pcp_node_info 了解备用服务器如何 赶上主服务器。
第 4 章.看门狗
4.1. 简介
看门狗是 Pgpool-II 的一个子进程，用于添加高 可用性。看门狗用于解析 失败。监督者是第一位的 在 pgpool-II V3.2 中引入，并在 Pgpool-II V3.5 中得到显著增强，以 确保始终存在 quorum。这个新增的 watchdog 使其在处理方面更具容错性和健壮性，并且 防范裂脑综合症和网络 分区。此外，V3.7 还引入了 quorum 故障转移（参见第 5.15.6 节）以减少 false PostgreSQL 服务器的优点 失败。为了确保仲裁机制正常工作，数字 的 Pgpool-II 节点数量必须是奇数 且大于或等于 3。
4.1.1. 协调多个 Pgpool-II 节点
看门狗协调多个 Pgpool-II 节点 通过相互交换信息。
在启动时，如果启用了看门狗，则 Pgpool-II 节点 从 Leader Watchdog 节点同步所有已配置的后端节点的状态。 如果节点本身继续成为领导节点，它会初始化后端 status 在本地。当后端节点状态因故障转移等原因发生变化时， 看门狗将信息通知给其他 Pgpool-II 节点并同步它们。发生联机恢复时，监视器会限制 客户端连接到其他 Pgpool-II 节点，以避免后端之间的不一致。
看门狗还与所有连接的 Pgpool-II 节点协调，以确保 failback、failover 和 follow_primary 命令只能在一个 pgpool-II 节点上执行。
4.1.2. 其他 Pgpool-II 节点的寿命检查
看门狗 lifecheck 是看门狗的子组件，用于监控 参与的 Pgpool-II 节点的健康状况 来提供高可用性。 传统上 Pgpool-II 看门狗提供 远程节点运行状况检查的两种方法。“heartbeat” 和 “query” 模式。 Pgpool-II V3.5 中的看门狗为 wd_lifecheck_method 添加了一个新的 “外部”， 它支持挂接外部第三方运行状况检查 带有 Pgpool-II 看门狗的系统。
除了远程节点健康检查外，看门狗 lifecheck 还可以检查 通过监控与上游服务器的连接来确定安装它的节点的运行状况。 如果监控失败，看门狗会将其视为本地 Pgpool-II 节点故障。
在心跳模式下，看门狗通过使用心跳信号来监控其他 Pgpool-II 进程。 看门狗定期接收其他 Pgpool-II 发送的心跳信号。如果一段时间内没有信号， watchdog 认为这是 Pgpool-II 的失败。 为了实现冗余，您可以使用多个网络连接进行检测信号 Pgpool-II 节点之间的交换。 这是用于运行状况检查的默认和推荐模式。
在查询模式下，看门狗监控 Pgpool-II 服务而不是进程。在这种模式下，看门狗向其他 Pgpool-II 发送查询并检查响应。
注意： 注意，这种方法需要来自其他 Pgpool-II 的连接， 因此，如果 num_init_children 参数不够大，它将无法进行监控。 此模式已弃用，保留用于向后兼容。
external 模式由 Pgpool-II V3.5 引入。此模式基本上禁用了内置的 lifecheck 的 Pgpool-II 看门狗，并期望外部系统 将通知 Watchdog 有关参与 Watchdog 集群的本地和所有远程节点的运行状况。
4.1.3. 所有 Pgpool-II 节点上的配置参数的一致性
启动时，看门狗会验证本地节点的 Pgpool-II 配置是否与配置一致 在 leader watchdog 节点上，并警告用户任何差异。 这消除了可能发生的意外行为的可能性 因为不同的 Pgpool-II 节点上的配置不同。
4.1.4. 在检测到某个故障时更改主用/备用状态
当检测到 Pgpool-II 的故障时， watchdog 会通知其他 watchdog。 如果这是活动的 Pgpool-II， 看门狗通过投票来决定新的活动 Pgpool-II，并改变 active/standby 状态。
4.1.5. 自动虚拟 IP 切换
当备用 Pgpool-II 服务器提升为活动服务器时， 新的 Active Server 将启动虚拟 IP 接口。同时，之前的 Active Server 关闭虚拟 IP 接口。这使得活跃的 Pgpool-II 可以使用相同的 即使服务器切换时，IP 地址也是如此。
4.1.6. 在 Recovery 中自动将服务器注册为 standby
当损坏的服务器恢复或连接新服务器时，看门狗进程 将此通知集群中的其他看门狗以及新服务器的信息， 监视程序进程接收活动服务器上的信息，并且 其他服务器。然后，连接的服务器将注册为备用服务器。
4.1.7. 启动/停止看门狗
看门狗进程作为子进程自动启动和停止 的 Pgpool-II 中，因此没有 用于启动和停止 watchdog 的专用命令。
看门狗控制虚拟 IP 接口，执行的命令由 用于启动和关闭 VIP 的监视程序需要 root 权限。Pgpool-II 需要 运行 Pgpool-II 的用户拥有 root 权限。 然而，以 root 用户身份运行 Pgpool-II 并不是一个好的安全实践，另一种选择 首选的方法是以普通用户身份运行 Pgpool-II，并使用 if_up_cmd、 if_down_cmd 的自定义命令。 以及使用 sudo 或使用 setuid arping_cmd（“在执行时设置用户 ID”） on if_* 命令
Lifecheck 进程是 watchdog 的一个子组件，它的工作是监控 参与的 Pgpool-II 节点的健康状况 监视程序群集。Lifecheck 进程会自动启动 当 watchdog 配置为使用内置的生命周期检查时， 它在 watchdog 主进程初始化完成后启动。 但是，只有当所有配置的 watchdog 时，lifecheck 过程才会启动 节点加入集群并变为活动状态。如果某个远程节点发生故障 在 Lifecheck 变为活动状态之前，Lifecheck 不会捕获该故障。
4.2. 将外部 lifecheck 与看门狗集成
Pgpool-II 看门狗进程使用 BSD 套接字与 所有 Pgpool-II 进程和 相同的 BSD 套接字也可以由任意三个 party 系统为本地和远程 Pgpool-II 看门狗节点提供 lifecheck 功能。 构建 IPC 的 BSD 套接字文件名 通过在 “s.PGPOOLWD_CMD.” 字符串后附加 Pgpool-II wd_port，套接字文件是 放置在 wd_ipc_socket_dir 目录中。
4.2.1. 看门狗 IPC 命令报文格式
watchdog IPC 命令包由 3 个字段组成。 下表详细介绍了消息字段和描述。
表 4-1.看门狗 IPC 命令报文格式
| Field | Type | Description |
|---|---|---|
| TYPE | BYTE1 | Command Type |
| LENGTH | INT32 in network byte order | The length of data to follow |
| DATA | DATA in JSON format | Command data in JSON format |
4.2.2. 看门狗 IPC 结果包格式
watchdog IPC 命令结果报文由 3 个字段组成。 下表详细介绍了消息字段和描述。
表 4-2.看门狗 IPC 结果包格式
| Field | Type | Description |
|---|---|---|
| TYPE | BYTE1 | Command Type |
| LENGTH | INT32 in network byte order | The length of data to follow |
| DATA | DATA in JSON format | Command data in JSON format |
4.2.3. 看门狗 IPC 命令数据包类型
发送到看门狗进程的 IPC 命令数据包的第一个字节 ，并且 watchdog 进程返回的结果被标识为 命令或命令结果类型。 下表列出了所有有效类型及其含义
表 4-3.看门狗 IPC 命令数据包类型
| Name | Byte Value | Type | Description |
|---|---|---|---|
| REGISTER FOR NOTIFICATIONS | ‘0’ | Command packet | 注册当前连接以接收看门狗通知的命令 |
| NODE STATUS CHANGE | ‘2’ | Command packet | 通知看门狗节点的节点状态更改的命令 |
| GET NODES LIST | ‘3’ | Command packet | 获取节点列表’3’命令数据包 |
| NODES LIST DATA | ‘4’ | Result packet | 数据包中的 JSON 数据包含所有已配置的看门狗节点的列表 |
| CLUSTER IN TRANSITION | ‘7’ | Result packet | 当由于集群正在转换而无法处理命令时，Watchdog 会返回此数据包类型。 |
| RESULT BAD | ‘8’ | Result packet | 当 IPC 命令失败时，Watchdog 会返回此数据包类型 |
| RESULT OK | ‘9’ | Result packet | 当 IPC 命令失败时，Watchdog 会返回此数据包类型 |
4.2.4. 外部 lifecheck IPC 数据包和数据
「GET NODES LIST」、「NODES LIST DATA」和「NODE STATUS CHANGE」 看门狗的 IPC 消息可用于集成外部 LifeCheck 系统。请注意，pgpool 内置的 lifecheck 也使用相同的通道和技术。
4.2.4.1. 获取已配置的看门狗节点列表
任何第三方 lifecheck 系统都可以发送 “GET NODES LIST” 看门狗 IPC 套接字上的数据包，其中包含包含授权密钥和值的 JSON 数据（如果设置了 wd_authkey 或空数据包数据 当 wd_authkey 未配置为获取 “NODES LIST DATA” 结果包。
看门狗为 “GET NODES LIST” 返回的结果数据包 will 包含所有已配置的看门狗节点的列表 运行状况检查以 JSON 格式启用。 看门狗节点的 JSON 包含所有看门狗节点的 “WatchdogNodes” 数组。 每个看门狗 JSON 节点都包含每个节点的 “ID”、“NodeName”、“HostName”、“DelegateIP”、“WdPort” 和 “PgpoolPort”。
-- The example JSON data contained in "NODES LIST DATA"{"NodeCount":3,"WatchdogNodes":[{"ID":0,"State":1,"NodeName":"Linux_ubuntu_9999","HostName":"watchdog-host1","DelegateIP":"172.16.5.133","WdPort":9000,"PgpoolPort":9999},{"ID":1,"State":1,"NodeName":"Linux_ubuntu_9991","HostName":"watchdog-host2","DelegateIP":"172.16.5.133","WdPort":9000,"PgpoolPort":9991},{"ID":2,"State":1,"NodeName":"Linux_ubuntu_9992","HostName":"watchdog-host3","DelegateIP":"172.16.5.133","WdPort":9000,"PgpoolPort":9992}]}-- Note that ID 0 is always reserved for local watchdog node
从 外部 LifeCheck 系统的 watchdog 可以继续执行 监视器节点的运行状况检查，以及当它检测到某些状态时 更改任何节点，它都可以使用 看门狗的 “NODE STATUS CHANGE” IPC 消息。 消息中的数据应包含 JSON 及其状态已更改的节点的节点 ID （节点 ID 必须与该节点的监视器返回的节点 ID 相同 ）和节点的新状态。
-- The example JSON to inform pgpool-II watchdog about health checkfailed on node with ID 1 will look like{"NodeID":1,"NodeStatus":1,"Message":"optional message string to log by watchdog for this event""IPCAuthKey":"wd_authkey configuration parameter value"}-- NodeStatus values meanings are as followsNODE STATUS DEAD = 1NODE STATUS ALIVE = 2
4.3. 对看门狗的限制
4.3.1. 查询模式 lifecheck 的看门狗限制
在查询模式下，当所有 DB 节点都由于 PostgreSQL 服务器而从 Pgpool-II 中分离时 失败或发出 pcp_detach_node，看门狗认为 Pgpool-II 服务处于宕机 状态，并使分配给 watchdog 的虚拟 IP 关闭。 因此 Pgpool-II 的客户端不能 使用 虚拟 IP 不再是 IP 的。这是避免脑裂所必需的， 也就是说，有多个活跃的 Pgpool-II 的情况。
4.3.2. 连接到看门狗状态为 down 的 Pgpool-II
不要在 down 时连接到 Pgpool-II status 使用真实 IP 的 IP 进行验证。因为处于宕机状态的 Pgpool-II 无法接收来自其他 Pgpool-II 看门狗的信息，所以它是后端状态 可能与其他 Pgpool-II 不同。
4.3.3. 看门狗状态为 down 的 Pgpool-II 需要重启
处于宕机状态的 pgpool-II 不能变为活动状态 也不是备用 Pgpool-II。 从宕机状态恢复需要重启 Pgpool-II。
4.3.4. 将 Watchdog 提升为 active 需要几秒钟
在活跃的 Pgpool-II 停止后， 备用 Pgpool-II 需要几秒钟才能提升到新的活动状态，以确保之前的虚拟 IP 是 在宕机通知包被发送到其他 Pgpool-II 之前被宕机。
4.4. 看门狗的架构
看门狗是 Pgpool-II 的一个子进程， 这增加了高可用性并解决了 通过协调多个 Pgpool-II 失败。 看门狗进程在 Pgpool-II 启动时自动启动（如果启用），它由两个 主要组件、看门狗核心和 lifecheck 系统。
4.4.1. 看门狗核心
称为 “看门狗” 的看门狗核心是一个 Pgpool-II 子进程，它 管理所有与 Pgpool-II 节点相关的通信，这些节点位于 cluster 的 Bean 通信，并且还与 Pgpool-II parent 和 lifecheck 进程通信。
看门狗进程的核心是启动 从其初始状态 （WD_LOADING） 和传输 朝向待机 （WD_STANDBY） 或 leader/coordinator （WD_COORDINATOR） 状态。 备用状态和领导/协调器状态都是 看门狗状态机，并且节点保持备用状态，或者 leader/coordinator 状态，直到检测到本地 Pgpool-II 节点中的某个问题，或者一个 远程 Pgpool-II 与集群断开连接。
监视程序进程执行以下任务：
管理和协调本地节点看门狗状态。
与内置或外部 lifecheck 系统交互 用于本地和远程 Pgpool-II 节点健康检查。
与 Pgpool-II main 交互 进程，并为 Pgpool-II 父进程提供机制。 通过 watchdog 通道执行 cluster 命令。
与所有参与的 Pgpool-II 节点通信以协调 leader/coordinator 节点，并确保集群中的 quorum。
管理主动/协调器节点上的虚拟 IP，以及 允许用户为 升级和降级。
验证看门狗集群中参与的 Pgpool-II 节点之间 Pgpool-II 配置的一致性。
在启动时同步所有 PostgreSQL 后端的状态。
为 Pgpool-II 主进程提供分布式锁定工具 用于同步不同的故障转移命令。
4.4.1.1. 与 Cluster 中的其他节点通信
Watchdog 使用 TCP/IP 套接字进行与其他节点的所有通信。 每个 watchdog 节点可以为每个节点打开两个 sockets。一个是 此节点创建的传出（客户端）套接字并启动 连接到远程节点，第二个套接字是 is listening socket for inbound connection initiated by remote （远程发起的入站连接） watchdog 节点。一旦 socket 连接到远程节点成功 watchdog 发送 ADD NODE （WD_ADD_NODE_MESSAGE） 消息。在收到 ADD NODE 消息后， 看门狗节点验证消息中封装的节点信息 替换为该节点的 Pgpool-II 配置，如果该节点通过了 验证测试会将其添加到集群中，否则会添加连接 被丢弃。
4.4.1.2. IPC 和数据格式
Watchdog 进程公开 UNIX 域套接字 用于 IPC 通信，它接受并以 JSON 格式提供数据。所有内部的 Pgpool-II 进程，包括 Pgpool-II 内置的 lifecheck 和 Pgpool-II 主进程 使用此 IPC 套接字接口与看门狗交互。 此 IPC 套接字也可以由任何外部/第三方系统使用 与 watchdog 交互。
有关详细信息，请参阅 Section 4.2 介绍如何使用看门狗 IPC 接口集成外部/第三方系统。
4.4.2. 看门狗 Lifecheck
看门狗 lifecheck 是 watchdog 的子组件，用于监控运行状况 参与看门狗的 Pgpool-II 节点数 簇。Pgpool-II 看门狗提供了三个内置的 远程节点健康检查的方法，“heartbeat”、“query”和“external”模式。
在 heartbeat 模式下，lifecheck 进程通过 UDP 套接字发送和接收数据，以检查远程节点的可用性，以及 对于每个节点，父 LifeCheck 进程都会生成两个子进程，一个用于 发送检测信号，另一个用于接收检测信号。 在 “query” 模式下，lifecheck 进程使用 PostgreSQL libpq 查询远程 Pgpool-II 的接口。 在这种模式下，lifecheck 进程会为每个运行状况创建一个新线程 check 查询，该查询在查询完成后会立即销毁。 当处于 “external” 模式时，该模式会禁用 Pgpool-II 内置的 lifecheck，并期望外部系统 将监控本地和远程节点。
除了远程节点健康检查外，看门狗 lifecheck 还可以检查 通过监控与上游服务器的连接来安装它的节点的运行状况。 为了监控与上游服务器的连接，Pgpool-II lifecheck 使用 execv（） 函数来执行 ‘ping -q -c3 hostname’ 命令。 因此，会生成一个新的子进程来执行每个 ping 命令。 这意味着对于每个运行状况检查周期，都会创建一个子进程，并且 销毁。 例如，如果在 lifecheck 中配置了两个上游服务器，并且它是 要求每隔 10 秒进行一次运行状况检查，然后每 10 秒检查一次 LifeCheck 将生成两个子进程，每个子进程对应一个上游服务器。 并且每个进程都将存在，直到 ping 命令完成。