工具 | PG 集群复制管理工具 repmgr
作者:颜博 青云科技数据库研发工程师
目前从事 PostgreSQL 产品开发工作,热衷于 PostgreSQL 数据库的学习和研究
| REPMGR 简介
repmgr[1] 是一套开源工具,用于管理 PostgreSQL 服务器集群内的复制和故障转移。repmgr 支持并增强了 PostgreSQL 的内置流复制,它提供了一个单一的读/写主服务器和一个或多个只读备用服务器。
repmgr 流复制管理工具对 PostgreSQL 集群节点的管理是基于分布式的管理方式。集群每个节点都具备一个 repmgr.conf 配置文件,用来记录本节点的 ID、节点名称、连接信息、数据库的 PGDATA 目录等配置参数。在完成参数配置后,就可以通过 repmgr 命令实现对集群节点的 “一键式” 部署。
repmgr 架构图(图片来源:https://repmgr.org/ )如下:
集群节点部署完成后,每个节点都可通过 repmgrd 守护进程来监控节点数据库状态;每个节点元数据表可独立维护,这些元数据表将记录所有集群节点的信息。
选举原理
在发生 Auto Failover 时,备节点在尝试多次连接主节点失败后(尝试次数及尝试间隔可以通过 repmgr.conf 配置文件修改),repmgrd 会在所有备节点中选举一个候选备节点(选举机制参考下文)提升为新主节点,其他备节点去 Follow 到该新主上,形成一个新的集群。
repmgr 选举候选备节点按照以下顺序选举:LSN > Priority > Node_ID
- 系统将优先选举一个 LSN 较大的节点,作为候选备节点;
- 若 LSN 一样,会根据 Priority 优先级进行比较(该优先级是在配置文件中进行参数配置,如果 Priority 为 0,则代表该节点被禁止提升为主节点);
- 若优先级也一样,会比较节点的 Node ID,小者会优先选举。
两个工具
repmgr 主要提供了 repmgr 和 repmgrd 两个工具。
repmgr 是一个执行管理任务的命令行工具,方便进行 PostgreSQL 服务器集群的管理。具备以下功能特点:
- 设置备用服务器
- promote 备
- 主从切换
- 显示复制集群中服务器的状态
repmgrd 是一个守护进程,它主动监视复制集群中的服务器并支持以下任务:
- 监控和记录复制集群信息
- 故障检测、故障转移
- 集群中事件的通知(需要自定义脚本接受通知)
用户与元数据
为了有效地管理复制集群,repmgr 需要将集群中节点的相关信息存储在 repmgr 专用数据库表中。此架构由 repmgr 扩展自动创建,该扩展在初始化由 repmgr 管理的集群(repmgr primary register)的第一步中安装,并包含以下对象:
- Tables:
repmgr.events
: records events of interestrepmgr.nodes
: 复制集群中每个节点的连接和状态信息repmgr.monitoring_history
: repmgrd 写入的历史备用监控信息
- Views:
repmgr.show_nodes
: 基于repmgr.nodes
表,另外显示服务器上游节点的名称repmgr.replication_status
: 当启用 repmgrd 的监控时,显示每个 standby 的监控状态。repmgr 元数据信息可以存储在已有的数据库或在自己的专用数据库。
注意:repmgr 元数据信息不能存储在不属于 repmgr 管理的复制集群的 PostgreSQL 服务器上。repmgr 需要一个可以访问数据库和执行必要的更改的用户,该用户可以不是超级用户,但是某些操作(例如 repmgr 扩展的初始安装)将需要超级用户连接(可以在需要时使用命令行选项指定 --superuser)。
| 安装 repmgr
注意:必须在集群的所有节点安装相同的 “主要” repmgr 版本(例如 5.2.1.x)[2]。
repmgr 版本
repmgr 版本 | 支持的 PostgreSQL 版本 | 最新版本 |
---|---|---|
repmgr 5.2 | 9.4, 9.5, 9.6, 10, 11, 12, 13 | 5.2.1 (2020-12-07) |
repmgr 5.1 | 9.3, 9.4, 9.5, 9.6, 10, 11, 12 | 5.1.0 (2020-04-13) |
repmgr 5.0 | 9.3, 9.4, 9.5, 9.6, 10, 11, 12 | 5.0 (2019-10-15) |
repmgr 4.x | 9.3, 9.4, 9.5, 9.6, 10, 11 | 4.4 (2019-06-27) |
- repmgr 2.x 和 3.x 系列不再维持,不在此罗列。
- repmgr 5.0 发布之后,将不会再发布 repmgr 4.x 系列。
安装过程
以 repmgr 5.2.x 版本为例,从源码仓库,Clone 并安装 repmgr。
$ git clone https://github.com/EnterpriseDB/repmgr $ git checkout REL5_2_STABLE $ cd repmgr/ ./configure $ make install
make install 成功后,pg_bin_path 里会有 repmgr、repmgrd 两个可执行文件。
| 使用 repmgr
repmgr 工具的基本语法[3]:
repmgr [OPTIONS] primary {register|unregister} repmgr [OPTIONS] standby {register|unregister|clone|promote|follow|switchover} repmgr [OPTIONS] node {status|check|rejoin|service} repmgr [OPTIONS] cluster {show|event|matrix|crosscheck|cleanup} repmgr [OPTIONS] witness {register|unregister} repmgr [OPTIONS] service {status|pause|unpause} repmgr [OPTIONS] daemon {start|stop}
- 一般配置选项
-b, --pg_bindir=PATH PostgreSQL 二进制文件的路径(可选) -f, --config-file=PATH repmgr 配置文件的路径 -F, --force 强制执行有潜在危险的操作
- 数据库连接选项
-d, --dbname=DBNAME 要连接的数据库(默认:“postgres”) -h, --host=HOSTNAME 数据库服务器主机 -p, --port=PORT 数据库服务器端口(默认:“5432”) -U, --username=USERNAME 要连接的数据库用户名(默认:“postgres”)
- 特定于节点的选项
-D, --pgdata=DIR 节点数据目录的位置 --node-id 通过id指定节点(仅适用于部分操作) --node-name 按名称指定节点(仅适用于部分操作)
- 记录选项
--dry-run 显示动作会发生什么,但不执行它 -L, --log-level 设置日志级别(覆盖配置文件;默认值:NOTICE) --log-to-file 记录到 repmgr.conf 中定义的文件(或记录工具) -q, --quiet 禁止除错误之外的所有日志输出 -t, --terse 不显示细节、提示和其他非关键输出 -v, --verbose 显示额外的日志输出(用于调试)
常用操作
- 操作类
命令 | 描述 |
---|---|
repmgr primary register | 注册当前节点为 primary 节点 |
repmgr primary unregister | 注销 primary 主节点 |
repmgr standby clone | 当前节点使用 pg_basebackup 从 primary 主节点复制数据目录 |
repmgr standby register | 注册当前节点为 standby 节点 |
repmgr standby unregister | 注销 standby 节点 |
repmgr standby promote | 将 standby 节点提升为 primary 主节点 |
repmgr standby follow | 一主多从架构中,standby 节点重新指向新的 primary 主节点 |
repmgr standby switchover | 将指定 standby 节点提升为 primary 主节点,并将 primary 主节点降级为 standby 节点 |
repmgr witness register | 注册当前节点为见证服务器节点 |
repmgr witness unregister | 注销见证服务器节点 |
- 查看类
命令 | 描述 |
---|---|
repmgr node status | 查看各节点的基本信息和复制状态 |
repmgr node check | 高可用集群节点状态信息检查 |
repmgr node rejoin | 重新加入一个失效节点到集群 |
repmgr cluster show | 查看集群中已注册的节点基本信息与状态 |
repmgr cluster matrix | 查看集群中所有节点的 matrix 信息 |
repmgr cluster crosscheck | 查看集群中所有节点间两两交叉连接检测 |
repmgr cluster event | 查看集群事件记录信息 |
repmgr cluster cleanup | 清理集群监控历史 |
下期预告
下期我们将使用 repmgr ,带您一步步搭建一套 PostgreSQL 高可用集群。
参考
[1]. repmgr:https://github.com/EnterpriseDB/repmgr
[2]. 5.2.1文档:https://repmgr.org/docs/5.2/
[3]. 常见操作:https://blog.csdn.net/weixin_37692493/article/details/117032458?ivk_sa=1024320u

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
常用的前端JavaScript方法封装
1、输入一个值,返回其数据类型 function type(para) { return Object.prototype.toString.call(para) } 复制代码 2、数组去重 function unique1(arr) { return [...new Set(arr)] } function unique2(arr) { var obj = {}; return arr.filter(ele => { if (!obj[ele]) { obj[ele] = true; return true; } }) } function unique3(arr) { var result = []; arr.forEach(ele => { if (result.indexOf(ele) == -1) { result.push(ele) } }) return result; } 复制代码 3、字符串去重 String.prototype.unique = function () { var obj = {}...
- 下一篇
推开“微前端”的门
导读:“微前端”和“微服务”类似,是这两年被频繁提及的名词。web开发从前后端放在一起的单体应用,演进成前后端分离的SPA,这些改变让前后端实现了开发解耦、独立发布。解耦让开发、调试、发布的过程都更加自由灵活,但随着业务的发展,中大型的SPA逐渐成为了“巨石应用”(Monolithic Applications),当初因为前后端分离带来的“自由”也渐行渐远,模块的拆解越来越被需要。 全文5574字,预计阅读时间14分钟 本文主要分享两方面内容: 思考什么样的系统或者前端需要微前端 简述微前端工程中需要关注的一些设计要点 本文仅会从选型和设计上做一些思考总结,「不会」重点介绍以下内容: 深入介绍某些开源框架并对比 如何设计一个非常通用的微前端框架 针对某个设计点的实现方式非常详尽的介绍 希望能给正在踌躇是否使用微前端的你一些思路。 一、什么样的系统或者前端团队需要微前端? 如果你有下面案例的困境,微前端可能是你的一个选择。假设一个SPA的前端模块,包含了ABCD四个模块,它们错综复杂地依赖了多个单独部署的后端服务,如下图: 图一 上线当天,你们可能需要梳理一个模块依赖图谱,以确定当前的上...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Windows10,CentOS7,CentOS8安装Nodejs环境
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- Docker安装Oracle12C,快速搭建Oracle学习环境
- CentOS8编译安装MySQL8.0.19
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- CentOS8安装Docker,最新的服务器搭配容器使用
- CentOS6,CentOS7官方镜像安装Oracle11G
- CentOS关闭SELinux安全模块