pg_auto_failover

pg_auto_failover简介

pg_auto_failover是PostgreSQL的扩展，用于监视和管理postgres集群的故障转移。它针对简单性正确性和业务连续性进行了优化。

pg_auto_failover独立于PostgreSQL服务的体系结构，为您的PostgreSQL实现业务连续性。pg_auto_failover使用具有自动故障转移功能的多个节点实现单个PostgreSQL服务，以保证其用户和应用程序服务的可用性。

pg_auto_failover每个PostgreSQL服务使用三个节点：

一个PostgreSQL主节点
一个PostgreSQL备节点，使用流复制
一个pg_auto_failover Monitor节点，既充当见证者又充当协调者。

pg_auto_failover Monitor实现了一个状态机，并依赖于PostgreSQL来提供HA。例如。当备节点被检测为不可用节点时，或者当其滞后高于定义的阈值（默认为1个WAL文件或16MB，见 pgautofailover.promote_wal_log_threshold），则该监视器从它主节点上的synchronous_standby_names删除该备节点。在备节点恢复正常运行之前，不允许进行故障转移和切换操作，从而防止数据丢失。

pg_auto_failover快速入门

我们将创建一个PostgreSQL服务，由一个主节点和备节点组成，并设置pg_auto_failover以使它们之间复制数据。我们将模拟主节点中的故障，并查看系统是如何平滑地切换（故障转移）到辅助节点。

为简单起见，我们将在一台机器上运行所有部件，但在生产中，每个托管的PostgreSQL服务都会涉及三台独立的机器。一个用于主服务器，另一个用于辅助服务器，最后一个用作监视其他节点健康状况的监视器，管理全局状态，并为节点分配其角色。

创建监视器

pg_auto_failover监视器是第一个运行的组件。它会定期尝试连接其他节点并观察其健康状况。它还维护全局状态，与每个节点上的“Keeper”进行协商以确定他们自己在系统中的角色。

因为我们在一台机器上运行所有东西，所以我们为每个PostgreSQL实例提供一个单独的TCP端口。我们将为监视器提供一个独特的端口（6000）：

pg_autoctl create monitor   \
  --pgdata ./monitor     \
  --pgport 6000

此命令在–pgdata选项指向的位置初始化PostgreSQL集群。当–pgdata被省略时pg_autoctl 会尝试使用PGDATA环境变量。如果PostgreSQL实例已存在于目标目录中，则此命令会将其配置为监视器使用。

在我们的示例中，创建一个名为pg_auto_failover的数据库，安装Postgres扩展pgautofailover，创建autoctl用户，并授予对新用户的访问权限。

创建PostgreSQL集群服务

我们将使用pg_autoctl create的子命令创建主数据库。但是，为了模拟节点用尽磁盘空间时会发生什么，我们将主节点的数据文件存储在一个小的临时文件系统中。

sudo mkdir /mnt/node_a
sudo mount -t tmpfs -o size=400m tmpfs /mnt/node_a
sudo mkdir /mnt/node_a/data
sudo chown postgres -R /mnt/node_a

# initialize on that disk
pg_autoctl create postgres     \
  --pgdata /mnt/node_a/data \
  --pgport 6010             \
  --pgctl /usr/pgsql-11/bin/pg_ctl \
  --monitor postgres://autoctl_node@127.0.0.1:6000/pg_auto_failover \
  --nodename 'localhost'

sudo umount /mnt/node_a可以删除这个临时文件系统

它在指定的端口和目录中创建数据库。注意连接monitor的信息 – 这是监视器创建时会提示的连接信息。我们还给它指向pg_ctl的路径，以便即使系统上安装了其他版本的postgres，也会使用正确版本的pg_ctl。

在上面的示例中，Keeper创建主数据库。它选择将节点A设置为主节点，因为监视器中还没有其他节点。

此时，我们已经创建并运行监视器和主节点。接下来我们需要Keeper。它是一个独立的过程，因此即使Postgres主要发生故障，它也可以继续运行：

pg_autoctl run --pgdata /mnt/node_a/data

这会在终端中运行并输出日志。我们可以打开另一个终端并创建备节点，类似于我们创建主数据库的方式：

pg_autoctl create postgres  \
  --pgdata ./node_b      \
  --pgport 6011          \
  --pgctl /usr/pgsql-11/bin/pg_ctl \
  --monitor postgres://autoctl_node@127.0.0.1:6000/pg_auto_failover

pg_autoctl run --pgdata ./node_b

这里不同的是我们在另一个端口上运行postgreSQL并指向另一个数据目录。它从监视器中发现主存在，然后将其自己的状态切换为热备用，并开始从主数据库传输WAL内容。

观察复制状态

pg_autoctl show state --pgdata ./monitor
     Name |   Port | Group |  Node |     Current State |    Assigned State
----------+--------+-------+-------+-------------------+------------------
127.0.0.1 |   6010 |     0 |     1 |           primary |           primary
127.0.0.1 |   6011 |     0 |     2 |         secondary |         secondary

这看起来不错。我们可以将数据添加到主数据库，并观察它在备数据库中的反映。

# add data to primary
psql -p 6010 \
  -c 'create table foo as select generate_series(1,1000000) bar;'

# query secondary
psql -p 6011 -c 'select count(*) from foo;'
  count
---------
 1000000

触发故障转移

在另一个终端，我们将消耗节点A的磁盘空间并尝试重新启动数据库。它会拒绝启动。

# postgres went to sleep one night and didn’t wake up…
pg_ctl -D /mnt/node_a/data stop &&
  dd if=/dev/zero of=/mnt/node_a/bigfile bs=300MB count=1

# it will refuse to start back up with no free disk space
df /mnt/node_a
Filesystem     1K-blocks   Used Available Use% Mounted on
tmpfs             409600 409600         0 100% /mnt/node_a

在多次尝试重新启动节点A失败后，其Keeper发出信号给monitor表明该节点不健康，并将该节点处于“降级”状态。监视器将节点B提升为新的主节点。

pg_autoctl show state --pgdata ./monitor
     Name |   Port | Group |  Node |     Current State |    Assigned State
----------+--------+-------+-------+-------------------+------------------
127.0.0.1 |   6010 |     0 |     1 |           demoted |        catchingup
127.0.0.1 |   6011 |     0 |     2 |      wait_primary |      wait_primary

节点B不能被认为完全处于“primary”状态，因为没有备节点存在。它被标记为“wait_primary”，直到出现备节点。

客户端（无论是Web服务还是psql）可以在其PostgreSQL连接字符串中列出多个主机，并使用该参数 target_session_attrs添加有关选择哪个服务器的规则。

要在我们的案例中使用的URL，可以使用以下命令：

pg_autoctl show uri --formation default --pgdata ./monitor
postgres://127.0.0.1:6010,127.0.0.1:6011/?target_session_attrs=read-write

在这里，我们要求连接到节点A或B – 无论哪个支持读写：

psql \
  'postgres://127.0.0.1:6010,127.0.0.1:6011/?target_session_attrs=read-write'

当节点A和B都运行时，psql将连接到节点A，因为B将是只读的。但是现在A离线且B可写，psql将连接到B.我们可以插入更多数据：

-- on the prompt from the psql command above:
insert into foo select generate_series(1000001, 2000000);

复活故障节点

让我们增加节点A的磁盘空间，这样它就能再次运行。

rm /mnt/node_a/bigfile

现在，下一次Keeper重试时，它会恢复节点A。节点A在更新其数据以匹配B时经历状态“catchup”。一旦完成，A成为辅助，B现在是完整的primary节点。

pg_autoctl show state --pgdata ./monitor
     Name |   Port | Group |  Node |     Current State |    Assigned State
----------+--------+-------+-------+-------------------+------------------
127.0.0.1 |   6010 |     0 |     1 |         secondary |         secondary
127.0.0.1 |   6011 |     0 |     2 |           primary |           primary

更重要的是，如果我们直接连接到节点A并运行查询，我们可以看到它包含我们在关闭时插入的行。

psql -p 6010 -c 'select count(*) from foo;'
  count
---------
 2000000

pg_auto_failover架构

pg_auto_failover使用三个节点来处理单个PostgreSQL服务的故障，并且是有弹性的当三个节点中任何一个失败时。

附架构图

单个Monitor可以处理许多PostgreSQL服务，因此在实践中如果要处理N PostgreSQL服务，则至少需要2 * N + 1个服务器（不是3 * N）。

pg_auto_failover认为，当遵循以下两个保证时，PostgreSQL服务是高度可用的：
1. 单个节点故障在任何情况下都会阻止数据丢失。
2. 如果服务停机，服务将尽快恢复，首先处理规则1

pg_auto_failover针对业务连续性进行了优化。如果单个节点不可用，那么pg_auto_failover能够保障PostgreSQL服务的连续，并且由于PostgreSQL 同步复制，这样做可以防止任何数据丢失。
pg_auto_failover的设计权衡了业务连续性，在备用节点发生故障时使用异步复制放松复制时数据的保证。这允许PostgreSQL服务在单个服务器可用时接受业务的写入，这将触发潜在的数据丢失如果现在主节点也发生错误。

pg_auto_failover监视器

pg_auto_failover中的每个PostgreSQL节点都运行一个Keeper进程，该进程通知中央Monitor节点有关自己节点状态的变更。有些请求是monitor对节点进行编排的变更：

新节点
在初始化时，必须为每个节点配置PostgreSQL流复制，并使集群在每个组中同时具有主节点和辅助节点。监视器确定每个新节点的角色
节点故障
监视器在检测到不健康的节点时协调故障转移。pg_auto_failover的设计允许监视器关闭先前指定的主节点的服务，从而避免“裂脑”情况。

监视器是权威节点，它通过向节点的Keeper进程发出命令来管理全局状态并在集群中进行更改。pg_auto_failover监视器节点的故障对系统的影响非常有限，虽然它可以防止在其他节点故障时做出反应，但它不会影响复制，pg_auto_failover的PostgreSQL的流复制不依赖于监视器是否启动或运行。

pg_auto_failover 术语

pg_auto_failover使用以下概念处理单个PostgreSQL服务：

MONITOR（监视器）
跟踪一个或多个包含两个节点组成的高可用。
Monitor监视器采用PostgreSQL extension方式实现，因此当您运行 pg_autoctl create monitor 命令时，它会初始化PostgreSQL实例/配置extension扩展/启动数据库。将监视器服务嵌入到PostgreSQL服务中。
FORMATION
PostgreSQL服务的逻辑集合。
GROUP
一个组由两个PostgreSQL NODES组成，以高可用的方式提供单个PostgreSQL服务。GROUP由PostgreSQL主服务和具有Hot Standby的备服务通过同步复制的方式组成。pg_auto_failover可以为您协调并设置整个高可用的配置。
KEEPER（管理器）
KEEPER是必须与PostgreSQL节点运行在同一个服务器上的代理。KEEPER控制本地PostgreSQL实例（使用pg_ctl命令行工具和SQL）并与MONITOR通信：

发送有关本地节点的更新数据，例如WAL之间的延迟，通过PostgreSQL视图的统计信息。
它从监视器接收状态分配。

此外，KEEPER维护一个本地状态，包括与MONITOR和本组的其他PostgreSQL节点进行通信，使其能够检测网络。

NODE
NODE是pg_auto_failover的一个节点，运行PostgreSQL实例和KEEPER服务。
STATE
STATE是每个实例和每个组的状态的表示。监视器（monitor）和管理器（keeper）实现有限状态机来驱动GROUP中的PostgreSQL实例并实现高可用性保障数据不会丢失。

KEEPER主循环强制执行本地PostgreSQL实例的当前预期状态，并将当前状态和其他信息报告给MONITOR。MONITOR使用这组信息和自己的健康检查信息来驱动状态机并将目标状态分配给KEEPER。

KEEPER实现当前状态和MONITOR分配的目标状态之间的转换。

客户端内置HA

从10版本开始，PostgreSQL的驱动程序libpq中实现了客户端高可用性的功能。使用此驱动程序，可以在同一连接字符串中指定多个主机名或IP地址：

$ psql -d "postgresql://host1,host2/dbname?target_session_attrs=read-write"
$ psql -d "postgresql://host1:port2,host2:port2/dbname?target_session_attrs=read-write"
$ psql -d "host=host1,host2 port=port1,port2 target_session_attrs=read-write"

使用上述任一语法时，psql应用程序尝试连接到host1，并在成功连接后，根据target_session_attrs进行状态确认，如果此参数设置为read-write，则只有接受读写事务的连接才被认为是可接受的。此参数的默认值any表示所有连接均可接受。

当尝试连接到host1失败时，或者无法验证target_session_attrs时，psql应用程序将尝试连接到host2。

该行为在连接库libpq中实现，因此使用它的任何应用程序都可以从此实现中受益，而不仅仅是psql。

使用pg_auto_failover时，请将应用程序连接字符串配置为主节点和备节点，并进行target_session_attrs=read-write的设置，以便即使在发生故障转移后，应用程序也会自动连接到当前主服务器。

监控协议

监视器以两种方式与数据节点交互：

数据节点定期的运行SELECT pgautofailover.node_active（…）以传达其当前状态并获取其目标状态。
监视器定期连接到所有数据节点以查看它们是否健康，执行的操作与pg_isready相同。

当数据节点调用node_active时，节点的状态信息将存储在 pgautofailover.node表中，并且两个节点的状态机都会进行。

如果节点未与监视器通信，则它将导致故障转移（如果节点是主节点），禁用同步复制（如果节点是辅助节点），或导致状态机暂停直到节点返回（其他情况）。在大多数情况下，后者是无害的，但在某些情况下，它可能会导致停机时间更长，例如，如果备用数据库在故障转移期间出现故障。

如果监视器无法连接并且尚未通过node_active报告其状态一段时间，则该节点仅被视为不健康。例如，重新启动PostgreSQL而不会导致检查失败。

同步 vs异步复制

默认情况下，pg_auto_failover使用同步复制，这意味着所有写入都会阻塞，直到备用数据库接受它们为止。为了处理备用数据库失败的情况，备用数据库的运行状况主要在wait_primary 和primary之间切换。

在wait_primary中，会自动设置synchronous_standby_names=''异步模式来允许继续写入，但是由于备用数据库可能出现很多异常情况，因此也会禁用故障转移。如果备用数据库响应运行状况检查并且延迟在1个WAL内，则通过设置synchronous_standby_names = '*'重新启用主数据库上的同步复制，这可能会导致短暂的延迟峰值，因为写入将阻塞，直到备用数据库赶上。

如果要禁用同步复制，则需要将以下内容添加到postgresql.conf：

synchronous_commit = 'local'

通过禁用同步复制，确保了所有情况下在主数据库上的写入提交后会立即返回。在这种情况下，故障转移可能会导致一些数据丢失，但如果辅助节点落后主节点超过10个WAL段（可配置），则不会启动故障转移。在手动故障转移期间，备用数据库将继续接受来自旧主数据库的写入，主数据库失败或2分钟未收到写入时才会停止。

节点恢复

在故障转移后恢复节点时，Keeper会简单的重启一下。如果需要，它还将重新启动postgres并从监视器获取其目标状态。如果失败的节点是主节点并被降级（可以从监视器获取到）。将通过运行pg_rewind变成备节点的状态。如果它太落后太多则执行一个新的pg_basebackup。

pg_auto_failover容错

pg_auto_failover实现的核心是状态机。状态机由监视器驱动，其状态转换在Keeper服务中实现并向监视器报告成功状态。

Keeper根据需要会进行多次状态转换，直到它们成功为止，并且也报告未能达到的指定状态给监视器。监视器还会对已注册的PostgreSQL节点实施频繁的健康状态检查。

当监视器检测到某些内容不符合预期状态时，它会通过向Keeper分配新的目标状态，并向该目标状态转换，然后反馈执行结果。

不健康的节点

pg_auto_failover监视器负责对其管理的每个PostgreSQL节点运行常规运行状况检查。当能够使用PostgreSQL协议（libpq）连接到PostgreSQL节点（模仿pg_isready命令时）时，状况检查是成功的。

这些健康检查的频率（默认为20秒），PostgreSQL连接超时（默认为5秒），连接失败从试的次数（默认2），可以在Monitor节点上设置。

SELECT name, setting
    FROM pg_settings
   WHERE name ~ 'pgautofailover\.health';
                  name                   | setting
-----------------------------------------+---------
 pgautofailover.health_check_max_retries | 2
 pgautofailover.health_check_period      | 20000
 pgautofailover.health_check_retry_delay | 2000
 pgautofailover.health_check_timeout     | 5000
(4 rows)

Keeper程序还会报告PostgreSQL是否按预期运行。这对于当PostgreSQL服务器所在的操作系统运行正常并且keeper（pg_autoctl run）处于正常状态但PostgreSQL失败无法启动的情况非常有用。例如磁盘上的文件系统已满，系统级别的文件丢失损坏等。

主节点被monitor检测到不健康

当主节点不健康时，并且仅当备节点处于正常状态时，则要求主节点转换到DRAINING状态，并且备节点转换到PREPARE_PROMOTION状态。在此状态下，要求备节点赶上主节点的WAL，然后报告成功。

然后监视器继续升级备节点：它停止主数据库，并将备数据库提升为主数据库。

根据触发主节点不健康的确切情况，备服务器可能无法从中赶上WAL，在这种情况下，在PREPARE_PROMOTION_CATCHUP_TIMEOUT后，备用数据库将报告成功，并且继续进行故障转移。

备节点被monitor检测到不健康

当辅助节点运行状况不健康时，监视器会为其分配状态CATCHINGUP，并将状态WAIT_PRIMARY分配给主节点。实现从PRIMARY到WAIT_PRIMARY的转换时，Keeper会禁用同步复制。

当Keeper再次在两个节点中报告可接受的WAL差异时，将会升级成同步，当备节点未处于SECONDARY状态时，将不会进行提升。

Monitor节点失败

主节点和辅助节点就像你没有设置pg_auto_failover一样，因为Keeper无法报告本地状态。也不会发生自动故障转移。

注册pg_auto_failover系统服务

pg_autoctl show systemd 命令会显示注册系统服务的方法。

应该使用pg_autoctl启动PostgreSQL服务，而不是简单的启动PostgreSQL。

网络故障容错

除了这些简单的情况，pg_auto_failover对网络故障也具有弹性。以下是对pg_auto_failover行为产生影响的情况列表，以及为确保PostgreSQL服务的高可用性而采取的措施：

主节点无法连接到监视器
可能是主节点在网络分区的另一侧（不能与monitro相连的意思），或者监视器已经无法启动。Keeper根据备节点是否仍然连接到主节点的复制槽来决定，如果可以连接我们有备节点，则继续提供PostgreSQL的服务。

否则，当备节点不能连接到主节点的时，并且在NETWORK_PARTITION_TIMEOUT过去之后，主服务器认为它可能在不同的网络分区中（不能与monitro相连的意思）：这是一个脑裂的情况，但只有一种方法可以预防它。停止主节点，并报告DEMOTE_TIMEOUT的新状态。

network_partition_timeout可以在Keeper的配置中设置，默认为20秒。

监视器无法连接到主节点

完成所有重试并且超时后，主节点被认为是不健康的，并且监视器开始故障转移。这个过程有几个步骤，每个步骤都可以控制我们的期望，并在需要时退后一步。

为了实现故障转移，辅助节点需要健康并且追上主的数据。只有当我们在等待WAL重新回放（默认为30秒）超时，才可以提升辅助数据库。

监视器无法连接到备节点

只要备服务器被认为不健康，监控器就会为主节点分配WAIT_PRIMARY状态，将复制设置更改为异步。备节点也被分配了状态CATCHINGUP，这意味着在故障的情况下不能提升它。

当监视器跟踪两个服务器之间的WAL在允许范围内时，此时它会被分配SECONDARY状态，并且复制切换回同步模式

故障处理和网络故障检测

如果某个节点无法与监视器通信，或者由于监视器关闭或者由于网络出现问题，它将保持相同的状态，直到监视器恢复。

如果存在网络分区，则可能是监视器和辅助节点仍然可以通信，并且监视器决定提升辅助节点，因为主节点不再响应。同时，主网络仍然在网络分区的另一端运行。如果主服务器无法与监控器通信，则会开始检查辅助服务器是否仍然在连接。在postgres中，辅助连接会在30秒后自动超时。如果最后一次与监视器联系并且上一次与辅助站点的连接在过去时间都超过30秒，则主认为它处于网络分区的丢失状态并自行关闭。另一个情况也有可能是辅助和监视器实际上已关闭，主要是唯一存活的节点，但这种情况无法区分。

在非对称网络分区中，主服务器可能仍然能够与辅助服务器通信，而无法与监控器通信。在故障转移期间，监视器为辅助节点分配stop_replication状态，这将导致它与主节点断开连接。在那之后，主节点在30秒至最多60秒之后关闭。为了考虑最坏情况，监视器会等待90秒，然后再将备节点提升为主节点。

操作pg_auto_failover

安全

监视器和数据节点之间的连接默认使用信任身份验证。这使得用于pg_auto_failover连接节点的帐户无需密码。–auth 创建监视器或数据节点时，可以使用参数更改默认行为。PostgreSQL支持的任何auth方法都可以在这里使用。

操作用户

可以直接从监视器操作pg_auto_failover的formations和group。

出于安全原因，autoctl_node不允许执行维护操作。该用户仅限于pg_autoctl的需要和使用。您可以创建特定用户和身份验证规则以进行管理，也可以编辑用户的默认HBA规则为autoctl用户。

维护辅助节点

可以将任何辅助节点设置为MAINTENANCE状态，以便Postgres服务器不再进行同步复制，例如内核升级等

监视器提供以下API以在辅助节点上执行维护操作：

$ psql postgres://autoctl@monitor/pg_auto_failover
> select pgautofailover.start_maintenance('nodename', 5432);
> select pgautofailover.stop_maintenance('nodename', 5432);

命令行工具pg_autoctl也可以在当前节点上执行维护操作：

$ pg_autoctl enable maintenance
$ pg_autoctl disable maintenance

当备用节点处于维护状态时，监视器会将主节点状态设置为WAIT_PRIMARY：在此角色中，PostgreSQL流复制是异步的，备节点的PostgreSQL可能会停止，重新启动等。

触发故障转移

通过使用监视器提供的SQL API，可以使pg_auto_failover手动触发故障转移：

$ psql postgres://autoctl@monitor/pg_auto_failover
> select pgautofailover.perform_failover(formation_id => 'default', group_id => 0);

要调用该函数，您需要确定发生故障转移的组的formation和group。在pg_auto_failover keeper节点上运行以下命令：

$ export PGDATA=...
$ pg_autoctl config get pg_autoctl.formation
$ pg_autoctl config get pg_autoctl.group

实现受控切换

区分受控切换到故障切换通常很有用。在受控切换情况下，可以以避免数据丢失和将停机时间降至最低。

对于pg_auto_failover，因为我们使用同步复制，所以在触发手动故障转移时我们不会面临数据丢失风险。此外，我们的监视器在触发故障转移时知道当前的主节点的运行状况，并相应地执行故障转移操作。

因此，要使用pg_auto_failover触发受控切换，您可以使用与手动故障转移相同的API：

$ psql postgres://autoctl@monitor/pg_auto_failover
> select pgautofailover.perform_failover(formation_id => 'default', group_id => 0);

当前状态，最后事件

以下命令显示pg_auto_failover监视器pgautofailover.node表和pgautofailover.event表的信息：

$ pg_autoctl show state
$ pg_autoctl show events

当在监视器上运行时，该命令输出监视器上所有节点的状态和事件。在PostgreSQL节点上运行时，该命令将连接到监视器并仅输出与本地节点的服务组相关的信息。

配置pg_auto_failover

可以查看和更改pg_auto_failover的多个默认设置，具体取决于您希望在自己的生产设置中实现的权衡。您可以更改的设置将影响以下操作：

何时提升备节点
pg_auto_failover在检测到主节点运行状况不佳时，会实施故障转移。更改以下设置将影响pg_auto_failover监视器决定何时升级备节点：

pgautofailover.health_check_max_retries
pgautofailover.health_check_period
pgautofailover.health_check_retry_delay
pgautofailover.health_check_timeout
pgautofailover.node_considered_unhealthy_timeout

提升备节点的时间
在备节点升级时，pg_auto_failover会等待以下时间，以确保主服务器上的所有挂起写入在关闭时都进入辅助节点，从而防止数据丢失：

pgautofailover.primary_demote_timeout

防止提升备节点
pg_auto_failover实现了数据可用性超过服务可用性的权衡。当检测到PostgreSQL服务的主节点不健康时，才会提升辅助节点。

在主节点丢失的同时和使用同步复制的情况下，我们可以安全地切换到辅助节点，并且在这种情况下wal滞后为0。

如果之前检测到辅助服务器运行状况不佳，则pg_auto_failover监视器会将其从状态SECONDARY切换到状态CATCHING-UP，然后阻止升级。

超过这个设置的wal差值会变成异步模式：

pgautofailover.promote_wal_log_threshold

pg_auto_failover监控器配置

监视器的配置在已部署扩展的PostgreSQL数据库中，您可以像往常一样设置PostgreSQL的参数，无论是在 postgresql.conf文件中还是使用命令ALTER DATABASE pg_auto_failover SET parameter = value然后重载配置。

pg_auto_failover=> select name, setting, unit, short_desc from pg_settings where name ～ 'pgautofailover.'

post_auto_failover Keeper配置

示例配置文件如下所示：

[pg_autoctl]
role = keeper
monitor = postgres://autoctl_node@192.168.1.34:6000/pg_auto_failover
formation = default
group = 0
nodename = node1.db.local.tld
nodekind = standalone

[postgresql]
pgdata = /data/pgsql/
pg_ctl = /usr/pgsql-10/bin/pg_ctl
dbname = postgres
host = /tmp
port = 5000

[replication]
slot = pgautofailover_standby
maximum_backup_rate = 100M

[timeout]
network_partition_timeout = 20
postgresql_restart_failure_timeout = 20
postgresql_restart_failure_max_retries = 3

要输出，编辑和检查配置，请使用以下命令，不应该手动更改：

pg_autoctl config check [--pgdata <pgdata>]
pg_autoctl config get [--pgdata <pgdata>] section.option
pg_autoctl config set [--pgdata <pgdata>] section.option value

pg_autoctl.monitor
pg_auto_failover监视器的PostgreSQL服务URL。
如pg_autoctl show uri命令输出中所示。
pg_autoctl.formation
单个pg_auto_failover监视器可以处理几个formation。默认的名称是default。
pg_autoctl.group
在向监视器注册节点时，pg_auto_failover管理器将检索此信息，之后不应更改此信息。使用风险由您自己承担。
pg_autoctl.nodename
群集中所有其他节点用于联系此节点的节点主机名。
replication.slot
pg_auto_failover自动部署的流复制设置中使用的PostgreSQL复制槽的名称。在PostgreSQL中无法重命名复制槽。
replication.maximum_backup_rate
当pg_auto_failover使用该pg_basebackup 命令构建备用节点时，将使用此参数pg_basebackup来限制所使用的网络带宽。默认为100Mbps。
timeout.network_partition_timeout（默认20秒）
我们无法与其他节点通信的超时时间（以秒为单位）。此检查仅在PRIMARY服务器上完成。
当检测到PRIMARY节点位于网络分区的丢失侧时，pg_auto_failover管理器进入DEMOTE状态并停止PostgreSQL实例以防止裂脑情况。
timeout.postgresql_restart_failure_timeout（默认3）
timeout.postgresql_restart_failure_max_retries（默认20秒）
当PostgreSQL没有运行时，pg_auto_failover守护者做的第一件事就是尝试重新启动它。如果出现瞬态故障，最佳操作方法是再次尝试一段时间，然后再联系监视器并要求进行故障转移。

pg_auto_failover命令参考

pgautofailover插件实现pg_auto_failover的监视器。
pg_autoctl命令管理pg_auto_failover的服务。

pg_autoctl

每隔5秒，Keeper连接到PostgreSQL监视器并运行SELECT pg_auto_failover.node_active(...)，同时传达其当前状态并获得其目标状态。它按照配置将其当前状态存储在自己的状态文件中。

配置文件
~/.config/pg_autoctl/data/pgsql/pg_autoctl.cfg
状态文件
~/.local/share/pg_autoctl/data/pgsql/pg_autoctl.state

pg_autoctl help 查看详细
PG_AUTOCTL_DEBUG=1 pg_autoctl help 可以用于测试

pg_autoctl drop node 不会删除配置文件

张连壮

[CitusDB中国]站主，PostgreSQL粉丝，现从事Citus研发工作
愿Citus在中国发展的越来越好