Postgres主从(2)Repmgr基本命令

本文详细介绍了repmgr工具的各个命令,包括主节点注册、注销,从节点克隆、注册、注销、提升,主从切换,节点状态检查、复制检查、重新加入,以及集群管理和监控历史清理等功能。repmgr是PostgreSQL高可用解决方案的关键组件,用于管理和监控PostgreSQL集群。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

命令简介

命令说明
repmgr primary register安装pg的repmgr扩展并注册为主节点
repmgr primary unregister注销不活动的主节点
repmgr standby clone从其他节点复制数据到从节点
repmgr standby register注册从节点(添加从的信息到repmgr元数据)
repmgr standby unregisterrepmgr元数据中移除从的信息
repmgr standby promote将从提升为主
repmgr standby follow将从跟随新主
repmgr standby switchover将从提升为主并将主降级为从
repmgr witness register注册一个观察节点
repmgr witness unregister移除一个观察节点
repmgr node status显示节点的基本信息和复制状态
repmgr node check从复制的角度对节点进行健康监测
repmgr node rejoin重新加入一个失效节点到集群
repmgr cluster show显示所有集群中注册的节点信息
repmgr cluster matrix在所有节点运行show并汇总
repmgr cluster crosscheck在节点间两两交叉监测连接
repmgr cluster event输出时间记录
repmgr cluster cleanup清理监控历史

repmgr primary register注册主

说明

在集群中注册一个主节点,并配置PostgreSQL安装repmgr扩展,必须在所有从节点注册前注册

参数

  • -f:指定配置文件
  • –dry-run:测试命令执行条件是否满足,但不实际执行

将触发primary_register事件

repmgr primary unregister注销主

说明

注销非活动状态的主,典型场景是当主宕机,新主已产生时用本命令注销老主

参数

  • –node-id:要注销的主的nodeId
  • –dry-run:测试命令执行条件是否满足,但不实际执行

将触发primary_unregister 事件

repmgr standby clone克隆数据到从

说明

从其他节点(一般是主节点)克隆数据,并自动创建recovery.conf文件

克隆后并未启动从,需要先用repmgr standby register注册从,然后再启动数据库

PGDATA中postgresql.conf, postgresql.auto.conf, pg_hba.conf和pg_ident.conf等所有文件都将被复制,需要修改配置文件

自动创建recovery.conf

自动创建的以下配置

  • standby_mode:值总是on
  • recovery_target_timeline:值总是’latest’
  • primary_conninfo
  • primary_slot_name (如果使用复制槽)

如果repmgr.conf下配置了以下参数也将被复制到recovery.conf

  • restore_command
  • archive_cleanup_command
  • recovery_min_apply_delay

参数

  • –dry-run:测试命令执行条件是否满足,但不实际执行
  • -c, --fast-checkpoint:强制fast checkpoint
  • 其他参数见https://repmgr.org/docs/repmgr.html#REPMGR-STANDBY-CLONE

将触发standby_clone 事件

repmgr standby register 注册从

参数

  • –upstream-node-id:可选,复制源的NodeID
  • –dry-run:测试命令执行条件是否满足,但不实际执行

将触发standby_register 事件

repmgr standby unregister 注销从

并不会影响复制,只将元数据中删除从信息

参数

  • –node-id:可选,要注销的NodeId

将触发standby_unregister 事件

repmgr standby promote 提升从

说明

当主宕机时将从提升为主

执行成功成为主后,不需要重启PG。其他的从需要跟随新主(使用repmgr standby follow)

示例

$ repmgr -f /etc/repmgr/10/repmgr.conf standby promote

将触发standby_promote 事件

repmgr standby follow从跟随新主

示例

测试

repmgr -f /etc/repmgr.conf standby follow --dry-run

执行操作

repmgr -f /etc/repmgr.conf standby follow

将触发standby_follow 事件

事件参数

  • %p:新主的NodeID
  • %c:conninfo字符串
  • %a:本节点的node name

repmgr standby switchover主从切换

说明

提升从为主,并将主降级为从

需要主和从间可进行无密码的SSH连接

需要任何节点的repmgrd处于关闭状态

参数

  • –always-promote:即使主从不一致也将执行提升(原来的主将被关闭)
  • –dry-run:检查
  • –siblings-follow:让其他从跟随新主
  • –force-rewind[=/path/to/pg_rewind]:当主从不一致时使用pg_rewind重新同步主从

repmgr.conf

  • reconnect_attempts: 在原主执行关闭后进行完全关闭检查的次数
  • reconnect_interval: 在原主执行关闭后进行完全关闭检查的间隔时间
  • replication_lag_critical: 复制延迟(秒)超过该值退出主从切换
  • standby_reconnect_timeout: 原主降级重启后尝试连接到其的超时秒数.

新主将触发standby_switchover和standby_promote 事件

standby_switchover参数

  • %p:旧主的node id

旧主将触发node_rejoin 事件

repmgr node status节点状态

检查当前节点的基本信息和复制状态

例如:

$ repmgr node status
Node "node1":
    PostgreSQL version: 10beta1
    Total data size: 30 MB
    Conninfo: host=node1 dbname=repmgr user=repmgr connect_timeout=2
    Role: primary
    WAL archiving: off
    Archive command: (none)
    Replication connections: 2 (of maximal 10)
    Replication slots: 0 (of maximal 10)
    Replication lag: n/a

repmgr node check 节点复制检查

从复制的角度对本地节点进行检查

例如

$ repmgr -f /etc/repmgr.conf node check
Node "node1":
    Server role: OK (node is primary)
    Replication lag: OK (N/A - node is primary)
    WAL archiving: OK (0 pending files)
    Downstream servers: OK (2 of 2 downstream nodes attached)
    Replication slots: OK (node has no replication slots)

参数说明:

  • –role: 检查角色是否如预期
  • –replication-lag: 检查延迟是否超过repmgr.conf配置的replication_lag_warning或replication_lag_critical
  • –archive-ready: 检查WAL文件是否被存档
  • –downstream: 检查下游节点是否如预期
  • –slots: 检查是否有非活动的复制槽

repmgr node rejoin节点重新加入

说明

将休眠(已停止)节点重新加入到复制群集

可选择使用pg_rewind来重新加入脱离集群的节点,通常是发生故障的主节点。

提示: 如果节点正在运行并且需要连接到当前的主节点,请使用 repmgr standby follow

参数

repmgr node rejoin

  • -d:必须,指定集群中任何可访问的节点的conninfo
  • –dry-run:测试
  • –force-rewind[=/path/to/pg_rewind]:需要时使用pg_rewind
  • –config-files:逗号间隔的保留文件,pg_rewind会重写所有文件,这里可指定保留的文件
  • –config-archive-dir:临时存放config-files的位置,默认/tmp

触发node_rejoin 事件

repmgr cluster show集群状态

repmgr cluster matrix集群连通性矩阵

repmgr cluster event 事件查询

参数

  • –all: 输出所有数据
  • –limit: 设置最大输出数量 (default: 20)
  • –node-id: 查询指定node id的事件
  • –node-name: 查询指定node name的事件
  • –event: 查询指名称的事件

repmgr cluster cleanup

如果监控数据在repmgr.conf中设置以下参数

  • monitoring_history:yes/no,是否启用监控
  • #monitor_interval_secs:监控间隔时间

监控数据量很大需要定期清理

本命令通过参数-k/–keep-history只保留指定天数的数据

例如保留30天

repmgr cluster cleanup -k30
<think>好的,我现在需要处理用户关于PostgreSQL三个节点使用repmgr重新初始化的问题。首先,我得理解用户的具体需求。用户提到的是三个节点的repmgr集群需要重新初始化,可能是因为整个集群出现了无法修复的故障,或者需要完全从头开始配置。这时候,重新初始化可能比逐个修复更高效。 接下来,我应该考虑用户的使用场景。用户可能是一个数据库管理员,负责维护高可用性的PostgreSQL集群。他们可能遇到了数据不一致、主从同步失败或者其他严重问题,导致现有的集群无法正常运行。因此,他们需要将整个集群重置,确保所有节点回到一个干净的状态,然后重新搭建环境。 用户的需求可能不仅仅是步骤性的操作指南,还可能包括注意事项和潜在风险。例如,在重新初始化之前,是否需要备份数据?如何确保所有节点上的旧数据被彻底清除?此外,用户可能还想知道如何验证重新初始化后的集群是否正常运作。 然后,我需要回忆repmgr的相关知识。repmgr是一个用于PostgreSQL流复制的管理工具,支持自动故障转移和节点管理。重新初始化整个集群通常涉及以下步骤:停止所有节点的PostgreSQL服务,清理数据目录,重新初始化主节点,配置主节点的repmgr,然后注册备用节点,并重新建立复制关系。 在这个过程中,需要注意每个步骤的顺序是否正确,例如必须先停止所有节点的服务,避免数据写入导致不一致。清理数据目录时,要确保使用正确的命令,比如pg_ctl stop -m immediate来立即停止服务,以及rm -rf来删除数据目录,但必须小心操作,防止误删其他重要文件。 注册主节点时,需要使用repmgr primary register命令,而备用节点则需要使用repmgr standby clone和repmgr standby register。此外,参数如--force在必要时使用,比如当旧节点信息仍然存在时需要强制注册。 可能用户会遇到的问题包括节点注册失败、网络配置错误、或者权限问题。例如,防火墙设置可能阻止节点之间的通信,或者PostgreSQL的pg_hba.conf文件没有正确配置复制用户的访问权限。这时候需要检查日志文件,如/var/log/postgresql/postgresql-XX-main.log,来排查错误。 另外,用户可能会问是否需要重新生成新的流复制槽,或者在重新初始化后如何监控集群状态。这时候可以建议使用repmgr cluster show来验证集群拓扑是否正确,以及检查复制延迟等指标。 还有,用户可能会关心数据备份的问题。在重新初始化之前,如果还有可用的数据,应该先进行备份,避免数据丢失。即使集群需要重置,备份也是一个好习惯。 最后,需要提醒用户,重新初始化会清除所有数据,所以必须确保这是必要的操作,并且已经做好了相应的备份和迁移准备。同时,建议在测试环境中先演练整个过程,熟悉步骤后再在生产环境中执行,以减少风险。</think>以下是对PostgreSQL三节点repmgr集群重新初始化的分步说明: --- ### **重新初始化repmgr集群的必要场景** - 集群出现无法修复的脑裂/数据不一致 - 主备节点全部故障且无有效备份 - 需要彻底重建集群拓扑结构 --- ### **准备工作** 1. **停止所有节点服务** ```bash # 在所有节点执行 pg_ctl stop -m immediate ``` 2. **清理旧数据** ```bash # 在所有节点执行 rm -rf /var/lib/postgresql/XX/main/* # 确保目录存在且权限正确 mkdir -p /var/lib/postgresql/XX/main && chown postgres:postgres /var/lib/postgresql/XX/main ``` --- ### **初始化主节点(原主节点或新节点)** 1. **初始化数据库** ```bash sudo -iu postgres initdb -D /var/lib/postgresql/XX/main --data-checksums ``` 2. **配置postgresql.conf** ```conf listen_addresses = '*' wal_level = replica max_wal_senders = 10 hot_standby = on ``` 3. **启动主库并创建复制用户** ```sql CREATE USER repuser REPLICATION LOGIN CONNECTION LIMIT 3; ALTER USER repuser PASSWORD 'SecurePass123!'; ``` --- ### **注册主节点到repmgr** ```bash repmgr primary register -f /etc/repmgr.conf --force ``` **关键参数说明**: - `--force`:强制覆盖已有注册信息 - 验证注册:`repmgr cluster show` --- ### **备节点初始化(以node2为例)** 1. **克隆主节点数据** ```bash repmgr standby clone \ -h <primary-ip> \ -U repuser \ -d repmgr \ --recovery-conf-only \ --force ``` 2. **注册备用节点** ```bash repmgr standby register -f /etc/repmgr.conf --force ``` 3. **启动备节点服务** ```bash pg_ctl start -D /var/lib/postgresql/XX/main ``` --- ### **验证集群状态** 1. **检查集群拓扑** ```bash repmgr cluster show ``` 预期输出应显示1个primary + 2个standby 2. **检查复制状态** ```sql SELECT client_addr, state, sync_state FROM pg_stat_replication; ``` --- ### **故障排查要点** 1. **日志检查路径** ```bash tail -f /var/log/postgresql/postgresql-XX-main.log ``` 2. **常见错误处理** - **流复制中断**:检查`pg_hba.conf`是否允许repuser从备节点IP访问 - **节点注册冲突**:使用`repmgr node unregister`清理旧记录 - **时间不同步**:确保所有节点已配置NTP服务 --- ### **注意事项** 1. **数据安全** - 重新初始化会**完全清除原有数据** - 操作前必须确认无可用备份需要恢复 2. **网络要求** - 节点间必须开放5432PostgreSQL)和22(SSH)端口 - 建议配置SSH互信免密登录 3. **参数一致性** - 所有节点的`postgresql.conf`中`max_connections`等核心参数必须一致 --- 通过以上步骤可完成三节点repmgr集群的彻底重建。建议在维护窗口期操作,并提前做好全量备份。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值