repmgr 5.0.0 说明书
摘要
这是repmgr 5.0.0的正式文档,可与PostgreSQL 9.3-PostgreSQL 12一起使用。
repmgr正在不断开发中,我们强烈建议您使用最新版本。请检查repmgr网站以获取有关当前repmgr版本以及当前repmgr文档的详细信息。
repmgr由2ndQuadrant与其他个人和组织共同开发。感谢并欢迎来自社区的贡献-通过github或邮件列表/论坛进行联系。多个2ndQuadrant客户提供资金以使repmgr开发成为可能。
repmgr得到2ndQuadrant的24/7生产支持的完全支持。 PostgreSQL项目的主要赞助商2ndQuadrant继续开发和维护repmgr。欢迎其他组织和个人开发人员参与其中。
目录
一、入门
- repmgr概述
- 安装
- 快速入门指南
二、repmgr管理手册
- repmgr配置
- 克隆备用数据库
- 使用repmgr升级备用服务器
- 跟随新的主要
- 使用repmgr执行切换
- 事件通知
- 升级repmgr
三、使用repmgrd
- repmgrd概述
- 使用repmgrd自动故障转移
- repmgrd的设置和配置
- repmgrd操作
- 使用repmgrd进行BDR故障转移
四、repmgr命令参考
repmgr primary register —初始化repmgr安装并注册主节点
repmgr primary unregister —注销不活动的主节点
repmgr standby clone—从另一个PostgreSQL节点克隆一个PostgreSQL备用节点
repmgr standby register——将备用信息添加到repmgr元数据
repmgr standby unregister——备用数据库注销—从repmgr元数据中删除备用数据库的信息
repmgr standby promote—将备用升级为主要
repmgr Standby Follow —将正在运行的备用数据库附加到新的上游节点
repmgr standby switchover—将备用数据库升级为主要数据库,并将现有的主要数据库降级为备用数据库
repmgr witness register—将见证人节点的信息添加到repmgr元数据
repmgr witness unregister——见证者注销—将见证节点的信息删除到repmgr元数据中
repmgr node status——显示节点的基本信息和复制状态的概述
repmgr node check——从复制角度对节点执行一些运行状况检查
repmgr node rejoin —将休眠(已停止)节点重新加入复制集群
repmgr node service —显示或执行系统服务命令以停止/启动/重新启动/重新加载/升级节点
repmgr cluster show —显示有关复制群集中每个已注册节点的信息
repmgr cluster matrix—在每个节点上运行repmgr群集显示并汇总输出
repmgr cluster crosscheck —交叉检查节点的每个组合之间的连接
repmgr cluster event—输出格式化的集群事件列表
repmgr cluster cleanup—清除监视历史记录
repmgr service status—显示有关集群中每个节点上repmgrd状态的信息
repmgr service stop—指示复制群集中的所有repmgrd实例暂停故障转移操作
repmgr deamon start——服务取消暂停-指示复制群集中的所有repmgrd实例恢复故障转移操作
repmgr deamon stop—在本地节点上启动repmgrd守护程序
一、入门
概念
本指南假定您熟悉PostgreSQL管理和流复制概念。有关流复制的更多详细信息,请参见关于流复制的PostgreSQL文档部分。
在repmgr文档中使用以下术语。
replication cluster
在repmgr文档中,“复制群集”是指通过流复制连接的PostgreSQL服务器网络。
node
节点是复制群集中的单个PostgreSQL服务器。
upstream node
备用服务器连接到的节点,以接收流复制。这是主服务器,或者在级联复制的情况下,是另一个备用服务器。
failover
如果主服务器发生故障,并且合适的备用服务器被提升为新的主服务器,则会发生此操作。 repmgrd守护程序支持自动故障转移,以最大程度地减少停机时间。
switchover
在某些情况下,例如硬件或操作系统维护,有必要使主服务器脱机;在这种情况下,有必要进行受控的切换,从而促进合适的备用数据库并以受控的方式从复制群集中删除现有的主数据库。 repmgr命令行客户端提供了此功能。
fencing
在故障转移情况下,升级新的备用数据库后,至关重要的是先前的主数据库不要意外地恢复联机,这会导致脑裂的情况。为了防止这种情况,应该将发生故障的主数据库与应用程序隔离开,即“隔离”。
witness server
repmgr提供了设置所谓的“见证服务器”的功能,以协助在故障转移情况下确定具有多个备用服务器的新主服务器。见证服务器本身不是复制群集的一部分,尽管它确实包含repmgr元数据架构的副本。
见证服务器的目的是提供一个“广播投票”,其中复制群集中的服务器被拆分到多个位置。如果位置之间的连接丢失,则见证服务器的存在与否将决定该位置的服务器是否升级为主服务器。这是为了防止出现“裂脑”的情况,在这种情况下,隔离的位置会将网络中断解释为(远程)主节点的故障并提升(本地)备用节点。
仅当使用repmgrd时,才需要创建见证服务器。
组成
repmgr是一套开源工具,用于管理PostgreSQL服务器集群中的复制和故障转移。它支持并增强了PostgreSQL的内置流复制,该复制提供了一个单一的读/写主服务器以及一个或多个只读备用数据库,其中包含主服务器数据库的近实时副本。它提供了两个主要工具:
repmgr
用于执行管理任务的命令行工具,例如:
- 设置备用服务器
- 将备用服务器升级为主服务器
- 切换主备服务器
- 显示复制群集中服务器的状态
repmgrd
守护程序,该守护程序主动监视复制群集中的服务器并执行以下任务:
- 监视和记录复制性能
- 通过检测主服务器的故障并升级最合适的备用服务器来执行故障转移
- 将有关集群中事件的通知提供给用户定义的脚本,该脚本可以执行任务,例如通过电子邮件发送警报
Repmgr用户和元数据
为了有效地管理复制群集,repmgr需要在专用数据库架构中存储有关群集中服务器的信息。此架构由repmgr扩展名自动创建,该扩展名是在初始化repmgr管理的集群(repmgr主寄存器)的第一步期间安装的,并且包含以下对象:
tables
- repmgr.events:记录感兴趣的事件
- repmgr.nodes:复制群集中每个服务器的连接和状态信息
- repmgr.monitoring_history:repmgrd编写的历史备用监视信息
views
- repmgr.show_nodes:基于表repmgr.nodes,另外显示服务器上游节点的名称
- repmgr.replication_status:启用repmgrd的监视时,显示每个备用数据库的当前监视状态。
repmgr元数据架构可以存储在现有数据库或其自己的专用数据库中。请注意,repmgr元数据架构不能驻留在数据库服务器上,该数据库服务器不是repmgr管理的复制群集的一部分。
数据库用户必须可供repmgr访问该数据库并执行必要的更改。该用户不必是超级用户,但是某些操作(例如repmgr扩展的初始安装)将需要超级用户连接(可以在命令行选项–superuser要求的位置进行指定)。
二、安装
安装repmgr的要求
repmgr是在Linux和OS X上开发和测试的,但是应该在PostgreSQL本身支持的任何类似UNIX的系统上运行。不支持Microsoft Windows。
repmgr 5.0.0与9.3以上的所有PostgreSQL版本兼容。有关版本兼容性的概述,请参见repmgr兼容性列表。
复制群集中的所有服务器必须运行相同的主PostgreSQL版本,我们建议它们也运行相同的次要版本。
repmgr必须安装在复制群集中的每台服务器上。如果从软件包安装repmgr,则软件包版本必须与PostgreSQL版本匹配。如果从源代码安装,则必须针对相同的主版本编译repmgr。
不需要repmgr的专用系统用户;由于许多repmgr和repmgrd操作需要直接访问PostgreSQL数据目录,因此这些命令应由postgres用户执行。
有关网络要求的信息,另请参阅配置先决条件。
兼容表
repmgr version | Supported? | Latest release | Supported PostgreSQL versions |
---|---|---|---|
repmgr 5.x | YES | 5.0.0 (2019-10-15) | 9.3, 9.4, 9.5, 9.6, 10, 11, 12 |
repmgr 4.x | NO | 4.4 (2019-06-27) | 9.3, 9.4, 9.5, 9.6, 10, 11 |
repmgr 3.x | NO | 3.3.2 (2017-05-30) | 9.3, 9.4, 9.5, 9.6 |
repmgr 2.x | NO | 2.0.3 (2015-04-16) | 9.0, 9.1, 9.2, 9.3, 9.4 |
重要性
repmgr 2.x和3.x系列不再受维护或支持。我们强烈建议升级到最新的repmgr版本。
在repmgr 5.0发布之后,将不会再发布repmgr 4.x系列。请注意,repmgr 5.x是4.x系列的增量开发,并且repmgr 4.x用户应尽快升级到此版本。
PostgreSQL 9.3和9.4支持
请注意,某些repmgr功能在PostgreSQL 9.3和PostgreSQL 9.4中不可用:
PostgreSQL 9.3不支持复制插槽,因此相应的repmgr功能不可用。
在PostgreSQL 9.3和PostgreSQL 9.4中,pg_rewind不是核心发行版的一部分。 pg_rewind将需要单独编译才能使用任何利用它的repmgr功能。
重要性
PostgreSQL 9.3的社区支持期已结束(最终版本于2018年11月为9.3.25),将不再通过安全性或错误修复进行更新。
PostgreSQL 9.4已到其社区支持期的末尾(最终版本于2020年2月为9.4.26),将不再通过安全性或错误修正进行更新。
我们建议这些版本的用户尽快迁移到最新的PostgreSQL版本。
有关更多详细信息,请参见PostgreSQL版本控制策略。
三、快速入门指南
使用repmgr设置基本复制群集的先决条件
下一节将介绍如何使用repmgr命令行工具使用主服务器和备用服务器设置基本复制群集。我们假设主节点称为IP地址为192.168.1.11的node1,备用节点称为IP地址为192.168.1.12的node2
两台服务器上都必须安装以下软件:PostgreSQL和repmgr(与已安装的PostgreSQL主版本匹配)
在网络级别上,必须在两个方向上都可以在PostgreSQL端口(默认值:5432)之间进行连接。如果要repmgr复制位于PostgreSQL数据目录之外的配置文件和/或测试switchover功能,则还需要在两台服务器之间建立无密码的SSH连接,并且应该安装rsync。
PostgreSQL配置
在主服务器上,必须初始化并运行PostgreSQL实例。可能需要调整以下复制设置:
# Enable replication connections; set this value to at least one more
# than the number of standbys which will connect to this server
# (note that repmgr will execute "pg_basebackup" in WAL streaming mode,
# which requires two free WAL senders).
#
# See: https://www.postgresql.org/docs/current/runtime-config-replication.html#GUC-MAX-WAL-SENDERS
max_wal_senders = 10
# If using replication slots, set this value to at least one more
# than the number of standbys which will connect to this server.
# Note that repmgr will only make use of replication slots if
# "use_replication_slots" is set to "true" in "repmgr.conf".
# (If you are not intending to use replication slots, this value
# can be set to "0").
#
# See: https://www.postgresql.org/docs/current/runtime-config-replication.html#GUC-MAX-REPLICATION-SLOTS
max_replication_slots = 10
# Ensure WAL files contain enough information to enable read-only queries
# on the standby.
#
# PostgreSQL 9.5 and earlier: one of 'hot_standby' or 'logical'
# PostgreSQL 9.6 and later: one of 'replica' or 'logical'
# ('hot_standby' will still be accepted as an alias for 'replica')
#
# See: https://www.postgresql.org/docs/current/runtime-config-wal.html#GUC-WAL-LEVEL
wal_level = 'hot_standby'
# Enable read-only queries on a standby
# (Note: this will be ignored on a primary but we recommend including
# it anyway, in case the primary later becomes a standby)
#
# See: https://www.postgresql.org/docs/current/runtime-config-replication.html#GUC-HOT-STANDBY
hot_standby = on
# Enable WAL file archiving
#
# See: https://www.postgresql.org/docs/current/runtime-config-wal.html#GUC-ARCHIVE-MODE
archive_mode = on
# Set archive command to a dummy command; this can later be changed without
# needing to restart the PostgreSQL instance.
#
# See: https://www.postgresql.org/docs/current/runtime-config-wal.html#GUC-ARCHIVE-COMMAND
archive_command = '/bin/true'
另外,如果打算使用pg_rewind,并且未使用数据校验和初始化集群,则可能需要考虑启用wal_log_hints。有关更多详细信息,请参见使用pg_rewind。另请参阅repmgr配置指南中的PostgreSQL配置部分。
创建repmgr用户和数据库
创建一个专用的PostgreSQL超级用户帐户和一个用于repmgr元数据的数据库,例如
createuser -s repmgr
createdb repmgr -O repmgr
注意:为了简单起见,将repmgr用户创建为超级用户。如果需要,可以将repmgr用户创建为普通用户。但是,对于某些操作,需要超级用户权限。在这种情况下,可以提供命令行选项–superuser来指定超级用户。还假定repmgr用户将用于建立从备用数据库到主数据库的复制连接;同样,可以通过在注册每个节点时指定一个单独的复制用户来覆盖它。
提示:repmgr将安装repmgr扩展,该扩展将创建一个repmgr模式,其中包含repmgr的元数据表以及其他功能和视图。我们还建议您将repmgr用户的搜索路径设置为包括该架构名称,例如
ALTER USER repmgr SET search_path TO repmgr, "$user", public;
在pg_hba.conf中配置认证
确保repmgr用户在pg_hba.conf中具有适当的权限,并且可以复制模式连接; pg_hba.conf应包含类似于以下内容的条目:
local replication repmgr trust
host replication repmgr 127.0.0.1/32 trust
host replication repmgr 192.168.1.0/24 trust
local repmgr repmgr trust
host repmgr repmgr 127.0.0.1/32 trust
host repmgr repmgr 192.168.1.0/24 trust
请注意,这些是用于测试目的的简单设置。根据您的网络环境和身份验证要求进行调整。
准备备库
在备用数据库上,请勿创建PostgreSQL实例(即不执行initdb或程序包提供的任何数据库创建脚本),但请确保目标数据目录(以及您希望PostgreSQL使用的任何其他目录)存在并归其所有,postgres系统用户。权限必须设置为0700(drwx ------)。
提示:repmgr会将主数据库的数据库文件的副本放置在此目录中。但是,如果已经在其中创建了PostgreSQL实例,它将拒绝运行。
使用psql检查备用数据库是否可访问主数据库:
psql 'host=node1 user=repmgr dbname=repmgr connect_timeout=2'
注意:repmgr始终将连接信息存储为 libpq connection strings 。本文档将它们称为conninfo字符串。备用名称是DSN(数据源名称)。我们将使用它们代替-h主机名-d数据库名-U用户名语法。
repmgr配置文件
在主服务器上创建repmgr.conf文件。该文件必须至少包含以下参数:
node_id=1
node_name='node1'
conninfo='host=node1 user=repmgr dbname=repmgr connect_timeout=2'
data_directory='/var/lib/postgresql/data'
repmgr.conf不应存储在PostgreSQL数据目录中,因为在设置或重新初始化PostgreSQL服务器时,它可能会被覆盖。有关repmgr.conf的更多详细信息,请参见配置和配置文件部分。
注意:repmgr仅在直接执行PostgreSQL二进制文件时才使用pg_bindir。对于promote_command和各种service _ * _ commands等用户定义的脚本,您必须始终明确提供所执行的二进制文件或脚本的完整路径,即使它本身是repmgr。这是因为这些选项可以在任意位置包含用户定义的脚本,因此前置pg_bindir可能会破坏它们。
注册主服务器
要使repmgr支持复制集群,必须在repmgr中注册主节点。这将安装repmgr扩展名和元数据对象,并添加主服务器的元数据记录:
$ repmgr -f /etc/repmgr.conf primary register
INFO: connecting to primary database...
NOTICE: attempting to install extension "repmgr"
NOTICE: "repmgr" extension successfully installed
NOTICE: primary node record (id: 1) registered
验证集群状态,如下所示:
$ repmgr -f /etc/repmgr.conf cluster show
ID | Name | Role | Status | Upstream | Connection string
----+-------+---------+-----------+----------+--------------------------------------------------------
1 | node1 | primary | * running | | host=node1 dbname=repmgr user=repmgr connect_timeout=2
repmgr元数据表中的记录将如下所示:
repmgr=<