Postgres主从（2）Repmgr基本命令

分手后的思念是犯贱 2023-07-10 12:44 18阅读 0赞

# 命令简介 #

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

# 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天