发布于 2021

• 故障:时间回溯

  2021-02-22 @ 故障

  【草稿】 机器因为故障重启，NTP服务在PG启动后修复了PG的时间，导致Patroni无法启动。 Patroni中的故障信息如下所示。 patroni 进程启动时间和pid时间不一致。就会认为：postgres is not running。 两个时间相差超过30秒。patroni就尿了。 还发现了Patroni里的一个BUG：https://github.com/zalando/patroni/issues/811 错误信息里两个时间戳打反了。

  更多

发布于 2019

• 故障:扩展导致拒绝连接

  2019-06-13 @ 故障

  今天遇到一个比较有趣的Case，客户报告说数据库连不上了。报这个错： psql: FATAL: could not load library "/export/servers/pgsql/lib/pg_hint_plan.so": /export/servers/pgsql/lib/pg_hint_plan.so: undefined symbol: RINFO_IS_PUSHED_DOWN 当然，这种错误一眼就知道是插件没编译好，报符号找不到。因此数据库后端进程在启动时尝试加 …

  更多

发布于 2018

• 故障:连接池污染

  2018-12-11 @ 故障

  PostgreSQL很棒，但这并不意味着它是Bug-Free的。这一次在线上环境中，我又遇到了一个很有趣的Case：由pg_dump导致的线上故障。这是一个非常微妙的Bug，由Pgbouncer，search_path，以及特殊的pg_dump操作所触发。 背景知识 连接污染 在PostgreSQL中，每条数据库连接对应一个后端进程，会持有一些临时资源（状态），在连接结束时会被销毁，包括： 本会话中修改过的参数。RESET ALL; 准备好的语句。 DEALLOCATE ALL 打开的游 …

  更多

• 故障:页面数据损坏

  2018-11-29 @ 故障

  PostgreSQL是一个很可靠的数据库，但是再可靠的数据库，如果碰上了不可靠的硬件，恐怕也得抓瞎。本文介绍了在PostgreSQL中，应对数据页面损坏的方法。 最初的问题 线上有一套统计库跑离线任务，业务方反馈跑SQL的时候碰上一个错误： ERROR: invalid page in block 18858877 of relation base/16400/275852 看到这样的错误信息，第一直觉就是硬件错误导致的关系数据文件损坏，第一步要检查定位具体问题。 这里，16400是数据库 …

  更多

• 故障:序列号溢出

  2018-07-20 @ 故障

  0x01 概览 故障表现： 某张使用自增列的表序列号涨至整型上限，无法写入。 发现表中的自增列存在大量空洞，很多序列号没有对应记录就被消耗掉了。 故障影响：非核心业务某表，10分钟左右无法写入。 故障原因： 内因：使用了INTEGER而不是BIGINT作为主键类型。 外因：业务方不了解SEQUENCE的特性，执行大量违背约束的无效插入，浪费了大量序列号。 修复方案： 紧急操作：降级线上插入函数为直接返回，避免错误扩大。 应急方案：创建临时表，生成5000万个浪费空洞中的 …

  更多

• 故障:事务号回卷

  2018-07-20 @ 故障

  遇到一次磁盘坏块导致的事务回卷故障： 主库（PostgreSQL 9.3）磁盘坏块导致几张表上的VACUUM FREEZE执行失败。 无法回收老旧事务ID，导致整库事务ID濒临用尽，数据库进入自我保护状态不可用。 磁盘坏块导致手工VACUUM抢救不可行。 提升从库后，需要紧急VACUUM FREEZE才能继续服务，进一步延长了故障时间。 主库进入保护状态后提交日志（clog）没有及时复制到从库，从库产生存疑事务拒绝服务。 摘要 这是一个即将下线老旧库，疏于管理。坏块征兆在一周前就已经出 …

  更多

• 故障:移除负载导致过载

  2018-04-08 @ 故障

  最近发生了一起匪夷所思的故障，某数据库切走了一半的数据量和负载。 其他什么都没变，本来还好；压力减小，却在高峰期陷入濒死状态，完全不符合直觉。 但正如福尔摩斯所说，当你排除掉一切不可能之后，剩下的即使再离奇，也是事实。 一、摘要 某日凌晨4点，进行了核心库进行分库迁移，拆走一半的表和一半的查询负载，原库节点规模不变。 当日晚高峰核心库所有热备库（15台）出现连接堆积，压力暴涨，针对性地清理慢查询不再起效。 无差别持续杀查询，有立竿见影的救火效果（22:30后），且暂停后故障立刻重 …

  更多