# PostgreSQL运维避坑案例整理

> 整理自用户提供的《新炬运维避坑指南合集》41 篇离线文章。按案例涉及的主要技术归类，归纳原文中的现象、排查处置和建议；案例措施仅代表原文环境，执行前应按当前版本、拓扑和变更流程复核。

共整理 **5 个案例**。期数按专辑标题编号；来源链接取自离线文章元数据。

[查看或下载 Markdown 原稿](新炬运维避坑案例整理.md)

## 案例目录

- [第 36 期｜Postgresql 高可用问题分析](#case-1)
- [第 27 期｜TelePG数据库连接异常与VIP切换故障](#case-2)
- [第 23 期｜某系统的telepg数据库对表添加同步后业务异常](#case-3)
- [第 21 期｜greenplum集群互信异常问题分析](#case-4)
- [第 18 期｜PG数据库大表未触发autovacuum](#case-5)

<a id="case-1"></a>

## 第 36 期｜Postgresql 高可用问题分析

- 专辑文件：`06.html`，第 9 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247566146&idx=1&sn=d15673a55794256f56a08199fdaa4f5e&chksm=f8da78c3bc74479f90c68a5f1478e3868ea12da851580e2c822515544f5e68742f252cdd02f0#rd)
- **现象：** Patroni高可用使用案例。
- **处置过程：** DCS参数max_replication_slots配置小于数据库复制槽个数，导致数据库启动失败，而修改DCS参数、重建etcd都无法解决问题，割接回退。；研究后，删除patroni.dynamic.json文件，则重启patroni即可生效。；部分品牌的物理机由于硬件的watchdog配置，导致触发watchdog重启的时候，主机启动异常，需去机房进行“contune"操作才可继续启动。
- **运维建议：** 数据库重要组件变更，使用迁移的方式进行，而不是直接修改组件；新建数据库，需进行详尽的高可用性测试验证

<a id="case-2"></a>

## 第 27 期｜TelePG数据库连接异常与VIP切换故障

- 专辑文件：`15.html`，第 4 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247562000&idx=1&sn=8c906945a61862b190e5d4e425f949b4&chksm=f88e88553a72b2d8ffa17f7835b3d93ee7ad2f5a5f5719a161a343b041194351ba125fd68b1e#rd)
- **现象：** 某业务系统telepg数据库业务执行批量操作，网络流量突增，导致gateway和zk之间心跳超时，vip切换引起程序连接出现报错。
- **处置过程：** 收到某业务系统数据库连接数过多，达到1979，产生了告警，业务反馈程序不可用。；业务紧急切换到灰度环境，连接数陆续下降，业务逐渐恢复正常。；查看数据库资源和主机资源历史情况，确定问题时间点。
- **运维建议：** 避免高峰期进行批量操作；在业务高峰期，严格控制批量操作；（如大表更新、存储过程执行等）

<a id="case-3"></a>

## 第 23 期｜某系统的telepg数据库对表添加同步后业务异常

- 专辑文件：`19.html`，第 2 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247560374&idx=1&sn=973ef698612ac5e7f6c7f6e1d7b91771&chksm=f809b38113526af6d617cae3717ed9e2ca4f006a87930338cd2b7b7d8913cb8b345725feade8#rd)
- **现象：** 某系统的telepg数据库对表添加同步后业务异常。
- **处置过程：** 业务反馈某个表不能执行update和delete；通过分析怀疑和刚搭建该表的增量同步有关。；cannot update table
- **运维建议：** 确保同步表具有主键或唯一标识符；在telepg数据库中添加逻辑同步时，目标表必须包含主键或其他唯一标识符。这是因为逻辑复制依赖于这些标识符来唯一确定每条记录。；如果表中没有主键或唯一标识符，可能会导致无法执行更新或删除操作，直接影响业务的正常运行。

<a id="case-4"></a>

## 第 21 期｜greenplum集群互信异常问题分析

- 专辑文件：`21.html`，第 9 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247559855&idx=1&sn=6d6126bdf60a61d0700bfbc30a6164cd&chksm=f8ecb6b58fc8f4602cc5f55f65682bff8f616bf575b7f97eb33a866aea324e42d26a2435be1b#rd)
- **现象：** greenplum通过kdc认证做集群间互信认证，kdc主机下线,导致集群互信异常。
- **处置过程：** 数据库巡检发现基于互信的命令gpstate,gpstop,gpstart,gprecoverseg等命令无法返回结果。；查看ssh日志,kdc认证的主机已下线，导致认证失败，这些gpstate命令是基于免密互信的，注释掉/etc/krb5.conf 中server相关行,保持主机互信正常。
- **运维建议：** 确保KDC主机的高可用性；（Key Distribution Center）；主机是Kerberos认证的核心组件，其下线会直接影响到基于KDC的认证服务。

<a id="case-5"></a>

## 第 18 期｜PG数据库大表未触发autovacuum

- 专辑文件：`24.html`，第 5 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247557767&idx=1&sn=69ce887ff2044e523ab1ab089655c2b1&chksm=f89e7d05abda444a45ee125a3b68780fa677b20ebb033ecd5db39244b9b06ad31dee41c79c76#rd)
- **现象：** 某系统telepg；(postgresql)；数据库大表未触发autovacuum。
- **处置过程：** 某日收到数据库告警，事务年龄超过告警阈值，；检查数据库并没有长事务的情况，；检查数据库autovacuum的相关参数，
- **运维建议：** 有效的数据库告警，能及时的发现问题，从而快速介入解决；数据库的默认参数并不能适合所有的业务，针对数据库的压力及时调整优化参数；建立有效的监控系统，监控数据库中表的dead tuple数量、autovacuum的执
