PostgreSql集群安装 Pgpool-II以及服务器设置和操作

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 libtool

cd 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 check failed 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 follows NODE STATUS DEAD = 1 NODE 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 命令完成。

相关推荐
qq_5432485215 分钟前
Linux网络配置与测试
linux·运维·网络
成都纵横智控科技官方账号1 小时前
EG8200Mini-104边缘计算网关!聚焦IEC104协议的工业数据转换与远程运维平台
运维·边缘计算·数据采集·104协议·智改数转
小峰编程1 小时前
谈Linux之磁盘管理——万字详解
linux·运维·服务器·经验分享·笔记·centos·运维开发
乐渔leyu1 小时前
Debian 12 服务器搭建Beego环境
服务器·debian·beego
程序猿John2 小时前
nginx实现负载均衡与例子详解
运维·nginx·负载均衡
不剪发的Tony老师2 小时前
rqlite:一个基于SQLite构建的分布式数据库
数据库·分布式·sqlite
archko2 小时前
telophoto源码查看记录
java·服务器·前端
爱的叹息2 小时前
Redis 与 MongoDB 对比分析
数据库·redis·mongodb
·薯条大王2 小时前
MySQL视图
大数据·数据库·mysql
Truelon2 小时前
【QT】QT编译链接 msql 数据库
数据库·qt