标签: PG管理

PostgreSQL 发布了最新一轮小版本更新。这次更新修复了 28 个安全漏洞和 110 多个 Bug。考虑到 7 月以来 Claude Fable 和 ChatGPT Sol 5.6 级别的模型已普遍可用，发现大量漏洞与 Bug 也是意料之中的结果。 老冯建议所有用户尽快安排 PostgreSQL 小版本升级。Pigsty 将于次日发布 v4.5，提供包含最新 PostgreSQL 18.6 的离线安装包。这将是 Pigsty v5.0 与 PostgreSQL 19 发布之前的最后一次小版 …

发布者：PostgreSQL Global Development Group 分类：PostgreSQL 项目安全 PostgreSQL 全球开发组发布了所有受支持 PostgreSQL 版本的更新，包括 18.4、17.10、16.14、15.18 和 14.23。本次发布修复了 11 个安全漏洞，以及过去几个月中报告的 60 多个 bug。 完整变更列表请参阅发行说明。 PostgreSQL 14 生命周期结束提醒 PostgreSQL 14 将于 2026 年 11 月 12 日停止接收 …

2026 年 3 月 18 日起，大量安卓用户发现自己的相册被美团清空。照片、视频、录音、PDF、Word，少则几百，多则上千。系统通知栏写得明明白白：“检测到‘美团’删除了多媒体文件”。有人 504 GB 数据永久丢失，6 年记忆不可恢复；也有人刚从回收站捞回来，过一会儿又被删了一遍。 随即，#美团删照片# 登上微博热搜。 美团随后发布说明，并把问题归因为“第三方插件冲突”。 美团客服的公开回应是这篇文章：《美团客服回应删除用户手机中照片、数据：已第一时间修复，不涉及对个人信息的读取、存储或泄 …

原作者：瑞典马工 · 微信公众号转载页 硅谷这个地方，同时以美国深圳和美国驻马店闻名，一边疯狂创新，一边疯狂忽悠。那里的老哥老姐时不时的发明一个新名词，有的词语是真的创新，有的新词是新瓶装旧酒，有的词语则只为骗钱。 比如说 Palantir，一半以上收入来自美国战争部的赏赐，拿单子全靠Peter Thiel和美国右翼集团的关系，网站挂着星条旗，活脱脱一个美国信创企业。本来应该闷声发大财的，但是他们不甘寂寞，发明一个新词语FDE，所谓前置部署工程师。国内一帮无脑自媒体也跟着嗨。实际上，这玩意就是 …

老冯之前在号外：PG小版本BUG，暂缓一周再安装升级里面说过，之前发布的 PG 小版本有 BUG，需要等新的号外小版本更新之后再部署合适。这不，PG 18.3，17.9 …… 系列小版本如期而至，10 天不到就新鲜出炉了。 不过目前 PGDG 还没出包，镜像站可能还要再晚一天才行。老冯正在快马加鞭测试准备 Pigsty v4.2 ，等 PGDG 一出包就制作离线软件包，发布一个新版本。 PostgreSQL 18.3、17.9、16.13、15.17 和 14.22 发布！ 发布日期 …

18.2 系列小版本引入两个 BUG，请暂缓新建与升级，并及时在下周 18.3 发布后更新。 一周前 PostgreSQL 社区发布了二月度例行小版本更新，Pigsty v4.1 也于当天跟进。 不过老冯必须提醒各位，最好不要在最近两周进行 PostgreSQL 新增部署与更新，因为这个例行小版本引入了两个 BUG。 这两个 BUG 将在 2026-02-26 的 号外小版本（out-of-cycle release）中修复。 表现 BUG 1：substring() 对非 ASCII …

七八年前，老冯手里维护着一百套大规模 PostgreSQL 集群，两百多台顶配物理机，开始做高可用方案选型。 那段时间我把市面上能叫得出名字的方案都翻了一遍：Patroni、Corosync + Pacemaker、repmgr、Stolon、PAF、pgpool-II…… 最后选了 Patroni。基于它做 HA，上线后效果很稳：这些年碰到几十次真实硬件故障，RTO 基本都在二三十秒区间。 最爽的是：半夜告警响了也不用爬起来抢救，流量自动切换，第二天起床再慢慢研究和调整就好了。 回头看，这个选 …

在《尝鲜须谨慎：PG新存储引擎故障案例》中，老冯简单聊过一下 PostgreSQL 上新的节奏 —— 应该用什么 PostgreSQL 大版本。老冯的策略是：当每个 PostgreSQL 大版本的第二个小版本出来的时候，差不多就能上生产了。最近 PostgreSQL 18.1 也就是第二个小版本已经放出了，加上扩展生态也基本上普遍跟进完成，老冯认为 PG 18 已经可以用于生产环境了。 先把BUG修一修 PostgreSQL 的版本发布策略非常规律：每年一个大版本，基本上大版本都会在九月下旬发布 …

昨天，老冯的一篇文章《从PG“断供”看软件供应链中的信任问题》收到一条评论， 评论者称是高校开源镜像站的管理员（清华 TUNA），向老冯提出批评抗议，内容如下： 作为高校开源镜像站管理员，我想要提醒作者，文中“躺平”“没有担当”的措辞是很不负责任的、令人心寒的指控。 老冯看到评论之后也做了回复： 感谢 回复与评论，也感谢这些年 TUNA 以及国内各高校镜像站为开源镜像生态投入的时间和精力。我看到最近几天 TUNA 的 PostgreSQL 仓库已经 恢复了和上游的同步，这一点先点个赞。 最初发现 …

原作者：陈明 · 微信公众号转载页 作为一名AI架构师，我没想到一次技术实践的分享，会在技术群里引发如此激烈的争论。从"把运维干掉"的激进主张，到AI工具能力的认知升级，这场讨论让我看到了一些被忽视的真相。 39个存储卷4小时迁移完成，我在群里聊天AI在干活 今天下午，我完成了一个让自己都有些惊讶的任务。 我们运行在Kubernetes上的测试集群需要进行持久化存储迁移——从一个NFS存储迁移到另一个存储。这涉及39个PV（持久化卷），覆盖数据库、AI训练数据、监控系统等各种应用的重要数据。 …

这个月发生了一起沸沸扬扬的 “开源断供”事件—— KubeSphere 删除镜像跑路， 但其实还有另一件略隐蔽的 “卡脖子案例”，老冯在上个月提到过 —— 《卡脖子：PGDG切断镜像站同步通道》。 这次 “PostgreSQL 断供” 某种程度上扮演了试金石的角色，倒是很好的试出了各家数据库厂商和云厂商的成色。 老冯对此感到非常失望，停止将国内的云厂商和大学镜像站作为软件供应链上游，直接自建了 PGDG YUM/APT 仓库的国内最新同步镜像。 PGDG的“断供” PostgreSQL 是数据库 …

今天老冯起了一个新坑 —— PG 36计。这是一套关于 PostgreSQL 应用开发与运维管理的教程。今天刚刚把架子搭好，准备在后面不断填充内容。 说起这个企划，这本书还是当初 2017 年翻译完 DDIA 第一版后，我想搞的一个系列，PostgreSQL 教程，分应用，管理，内核三篇。昨天刚把 DDIA 第二版的 Claude 机翻给弄好，一下子就想到了这本书，这本书就连目录结构都是照着 DDIA 弄的，原来的版本目录如下： 当初还有两家出版社来找，怂恿我写一本。不过那时候老冯确实比较忙，所 …

最近老冯在构建 Pigsty 离线包的时候发现，在本地测试的时候安装的 PostgreSQL 版本不太对，17.4 比最新的 17.5 落后了一个小版本。而且在 EL10 上测试的时候发现有几个仓库报错了。奇怪的是，在香港使用全球默认仓库没问题，一旦在本地使用中国的镜像站就报错。 仔细一看，发现国内的镜像站点都与 PostgreSQL 上游仓库失去同步了：清华大学开源软件镜像站（TUNA）最后一次成功同步是5月16号，而阿里云阿里云镜像站最后的同步时间戳是 2025 年 3-31。国外的镜像站， …

前天在 HOW 2025 大会的圆桌上，萧主席问了一些关于 AI，数据库 DBA 有趣的问题，以下是老冯的观点，整理发出。 OLTP / OLAP ，谁先被革命？ 问题：OLTP / OLAP 领域，AI 在哪个领域更有可能先带来 “革命性” 的变化，DBA， 数据分析师，架构师又该如何应对这些变化。 老冯：“革命性”的意思说白了就是直接把工作岗位干没了。对于 OLTP 领域，这意味着 AI 干掉 DBA ，对于 OLAP 领域，这意味着干掉数据分析师，数据研发的工作。目前的趋势很显然，OLAP …

老话说的好，不要在星期五发布。昨天晚上， PostgreSQL 全球开发者宣布发布了每季度一次的例行小版本更新，我没有立刻发布一个中文翻译，因为上次 11 月的小版本更新翻车场景《号外：发布当日叫停，PG也躲不过翻车》还历历在目。 不过我没想到的是，还真的又让我连着撞上第二次翻车。仅仅十二小时后，PGDG 就宣布了将在2月20号紧急发布一个号外小版本，来回滚这次的错误。 在 2.14 号例行发布的 17.3, 16.7, 15.11, 14.16, 以及 13.19 小版本中，修复了 …

原作者：瑞典马工 · 微信公众号转载页 SRE 至今还没有一个被广泛接受的中文名，但是很可惜，这个岗位在业界已经被抛弃了。 Site Reliability Engineer 因为来自于Google，一直听起来很酷，实际上，它无非就是指代会写代码的运维（Ops）。不论在中国还是欧美，大量的 SRE 都是运维ops或者系统管理员sysadmin换张名片而已。 SRE 仍然割裂了开发和运维。读过谷歌那几本 SRE 书的朋友可以明显的看出: 谷歌仍然没有解决 ops 不懂代码进而无法独立解决故障的根 …

原作者：瑞典马工 · 微信公众号转载页 降价，打折，优惠券 从事 IT 行业的朋友们，都有一个很具体的感受，云厂商的销售们手里没什么武器，无非就是三样：降价，打折扣，给优惠券。这技术含量还不如农贸市场卖豆腐的。买豆腐的要讲清楚水豆腐，油豆腐和攸县香干的区别；要提供客家酿豆腐菜谱；还要发明西汉淮南王制豆腐的故事。相比之下，卖云计算的所谓专家们只需要做一个事：把目录价格乘以从0.2到0.95不等的折扣数，所需要的全部技能是小学四年级算术。 这个现象也体现在云厂商的财务报表中。大多数云厂商是不盈利的 …

昨天遇到一个客户的案例。使用客户端直连 PostgreSQL，单个主库上有小几千条数据库连接。应用侧扩容之后连接数又大了很多，4000 多条连接，1500 条活跃状态的连接，直接撞上了软件瓶颈，写性能退化严重。后来换成连接池访问之后问题解决了。今天就来简单聊一下这个问题，连接池。 高并发连接数 在这个案例中，应用使用了 1500 条活跃的客户端连接访问单个主库。因为 PostgreSQL 使用多进程架构，这意味着对应着 1500 个后端进程，大部分的客户端请求只是单纯的向某张巨无霸表中插入单条数 …

正如《号外：发布当日叫停，PG也躲不过翻车》一文所述，PostgreSQL 在上周四发布的 17.1 打破了 ABI 当天紧急叫停了发布，并于本周四，也就是几分钟前刚刚发布了新的号外小版本序列：17.2, 16.6, 15.10, 14.15, 13.18, 以及 12.22，修复了此问题。 如果你在过去一周中通过互联网上游直接从官方仓库或镜像安装或升级过 PostgreSQL， 那么你可能有概率会遇到一些扩展兼容性的问题，我们强烈建议你立即升级到最新的 PostgreSQL 小版本以解决此问题 …

PostgreSQL全球开发组发布了所有受支持PG大版本的更新，包括16.4、15.8、14.13、13.16 和 12.20 版本，以及PostgreSQL 17 的第三个 beta 测试版。此次发布修复了1个安全漏洞和过去几个月报告的 55 个 BUG。 欲了解更多变更详情，请查阅发布说明[1]。 PostgreSQL 12 终止支持通知 PostgreSQL 12将于2024年11月14日停止发布修复补丁。如果您在生产环境中运行PostgreSQL 12，我们建议您计划升级到更新的、受支持 …

原作者：程序员 Aike · 微信公众号转载页 今天一篇基础架构部，还有必要吗？的文章刷屏了，作为一名资深的基础架构从业者，浅谈下自己的看法，期望引发广大基础架构从业者、业务开发、测试人员等相关从业者更多的思考和判断！ 01 基础架构部的定位 不同公司对基础架构部的定位不同，以下是可能的几个方面： 1、通过技术和工程手段、运维手段，保障线上服务稳定性。比如运维人员保障业务核心指标健康，网络、服务器等基础设施组件能承受业务压力等。 2、构建统一的基础服务，比如数据库、消息中间件、微服务框架，或者 …

原作者：瑞典马工 · 微信公众号转载页 过去二十年，中国互联网公司取得了巨大的成就。基础架构部（或者技术平台部，或者运维开发部，或者架构平台部）作为互联网公司的技术底座维护者，贡献巨大。但是随着技术的进步，此类部门的老经验在云时代，越来越不适用，而他们又普遍跟不上新问题。两项加起来，使得大家不得不问一个问题：基础架构部，真的还有价值吗？ 基础架构部的价值是向业务单元交付技术 基础架构部出于一个目的建立：集中公司的基础设施和架构人才，为业务单元提供技术支撑。 要达到这个目的，基础架构部需要达到两 …

原作者：王小瑞 · 微信公众号转载页 作者｜王小瑞 AutoMQ 联合创始人 & CEO\ 云计算通过资源池化实现单位资源成本更优，使企业能够将 IDC 建设、基础软件研发和运维等工作外包给云厂商，从而更专注于业务创新。资源池不仅包括服务器，还包括人才。云厂商集聚了优秀工程师，通过云服务为众多企业提供专业服务，让专业的事交给最专业的人。 云计算发展这么多年，弹性是云计算从业者最关注的技术能力之一，但是真正落实到具体的案例上，很少有客户能把弹性用好，弹性反而成为了一种口号，一种理想的架构，本文尝 …

原作者：瑞典马工 · 微信公众号转载页 昨天，阿里云声势浩大的邀请罗永浩直播卖云，结果老罗照本宣科之后，马上就接着卖高露洁牙膏，我的朋友冯老板哈哈大笑，嘲笑阿里云是个牙膏云。\ ALT ALT 从工程师习惯出发，我认真的研究了一些数据和事实，得出了不同的看法：任何一家云厂商都不配牙膏云这个称号。从利润率，到社会价值，到品牌管理，质量管理和市场教育，云厂商们都被牙膏厂全方面吊打。如果哪一天云厂商做到了牙膏厂的水准，那他们股东应该集体去南岳衡山烧香还愿，感谢菩萨保佑。 云厂有牙膏厂赚钱吗？ （以下 …

原作者：瑞典马工 · 微信公众号转载页 什么是云？云是什么？ 中国云计算是一个 5000 亿人民币的庞大产业，但是长久以来，厂家们一直没能说清楚一个问题：云计算究竟是什么，以及可能更重要的，云计算不是什么？ 这个问题可以衍生出更多的问题，包括： 云计算对企业究竟有什么价值？ 云计算的目标用户究竟是谁？ 云和 IDC 究竟有什么质的区别？ 上云和数字化转型究竟是什么关系？ 为什么上云这么难？ 云上计算，存储，网络的溢价这么高，但是为什么云厂家都不赚钱？ 云计算号称高科技行业，但是为什么中国有几十 …

前天开源漫谈第九期主题《DBA会被云淘汰吗？》，我作为主持人全程克制着自己亲自下场的冲动，因此特此写了这篇文章来聊聊这个问题 ： DBA 会被云淘汰吗？ DBA帮助用户用好数据库 很多地方都需要DBA：糟糕的模式设计，奇烂的查询性能，鬼知道有没有用的备份；等等等等。可惜的是，从事软件工作的人中，很少有人了解什么是DBA。成为DBA，意味着与研发人员创造的熵进行永无休止的战斗。 DBA，Database Administrator，数据库管理员，以前也叫做数据库协调员、数据库程序员。DBA是一个横 …

原作者：瑞典马工 · 微信公众号转载页 摘要 软件从业者在基本工程能力上的欠缺，过去被高速增长的业务数据所掩盖，不被当成一个问题。但是潮水一旦落下，我们就看到一个又一个裸泳的屁股。对此，我们没有其他建议，只有一个：老老实实地补课，不要再吹牛逼了。 滴滴不专业的故障沟通 11月27日滴滴出行出了故障，至今没有发布一个官方的时间线，没人知道故障是什么时候开始的和什么时候彻底恢复的。目前最为详细的故障时间线，是一家财经媒体雷达财经发布的《[1]滴滴崩溃原因找到了！并非网络攻击 而是底层系统软件故障 …

在线业务数据库中，慢查询不仅影响终端用户体验，还会浪费系统资源、拉高资源饱和度、导致死锁和事务冲突，增加数据库连接压力，导致主从复制延迟等问题。因此，查询优化 是 DBA 的核心工作内容之一。 在查询优化这条路上，有两种不同的方法： 宏观优化：整体分析工作负载，对其进行剖分下钻，自上而下地识别并改进其中表现最糟糕的部分。 微观优化：分析并改进一条特定的查询，这便需要记录慢查询日志，掌握 EXPLAIN 的玄机，领悟执行计划的奥妙。 今天我们先来说说前者，宏观优化 有三个主要目标与动机： 减少资源 …

有很多用户都问过我，跑数据库用什么操作系统比较好。特别是考虑到 CentOS 7.9 明年就 EOL了，应该有不少用户需要升级OS了，所以今天分享一些经验之谈。 太长不看 长话短说，在现在这个时间点如果用 EL 系列操作系统发行版，特别是如果要跑 PostgreSQL 相关的服务，我强烈推荐 RockyLinux，有“国产化”要求的也可以选龙蜥 OpenAnolis。AlmaLinux 和 OracleLinux 兼容性有点问题，不建议使用。Euler 属于独一档的 IT 领域预制菜进校园，有 …

备份是DBA的生命线 —— 但如果你的 PostgreSQL 数据库已经爆炸了又没有备份，那么该怎么办呢？也许 pg_filedump 可以帮到你！ 最近遇到了一个比较离谱的活儿，情况是这样的：有个用户的 PostgreSQL 数据库损坏了，是 Gitlab 自己拉起的 PostgreSQL。没有从库，没有备份，也没有 dump。跑在拿 SSD 当透明缓存的BCACHE上，断电后起不来了。 但这还没完，接连经受了几轮摧残之后，它彻底歇菜了：首先是因为忘了挂BCACHE盘，导致 Gitlab重新 …

郭德纲有一段相声：比如我和火箭专家说，你那火箭不行，燃料不好，我认为得烧柴，最好是烧煤，煤还得精选煤，水洗煤不行。如果那科学家拿正眼看我一眼，那他就输了。 但不管怎么说，马工也还是一位体面的瑞典研发工程师。没有做过DBA就敢大放厥词，开地图炮拉仇恨，实在勇气可嘉。之前在《你怎么还在招聘DBA》，以及回应文《云数据库是不是智商税》中，我们便已交锋过。 当别人把屎盆子扣在这个行业所有人头上时，还是需要人来站出来说几句的。因此今天特此撰文以驳斥马工的谬论：《再论为什么你不应该招DBA》。 马工的论点 …

原作者：瑞典马工 · 微信公众号转载页 开门见山\ 如果你是IT负责人，是时候停止招聘DBA了。因为 DBA能做的日常运维, 普通开发者使用云平台都能做。 开发者用云服务能把很多数据库管理工作做得更高效。 你以为DBA能做的数据架构设计, 其实他们从来都做不了。 \ DBA究竟在做些什么工作? 下面这个高级DBA工程师的岗位来自直聘网,其工作内容包括： 负责数据库架构设计.方案制定.数据存放选型和落地（包括数据库读写分离.数据库备份.数据库容灾.集群扩展.分库分表策略）；2.负责支持研发在数据 …

上一篇文章《DBA还是份好工作吗》中提到：尽管DBA作为一份职业在没落，但谁也保不准DBA会不会在几次恐怖的大规模云数据库故障后，重新成为潮流。 这不，最近就目睹了一场云数据库删库跑路现场情景剧。本文就来聊一聊在生产环境使用PostgreSQL，如何应对误删数据的问题。 故障现场 解决方案 看完了故事，我们不禁要问，我都已经花钱买了‘开箱即用’的云数据库了，为啥连PITR恢复这么基本的兜底都没有呢？ 说到底，云数据库也是数据库，云数据库并不是啥都不用管的运维外包魔法，不当配置使用，一样会有数据丢 …

蚂蚁金服有过一个自嘲的段子：能干翻支付宝的，除了监管就是 DBA 了。 数字时代，数据是很多企业的核心资产，对于互联网/软件服务类企业更是如此。而负责保管这些数据资产的人，就是 DBA（数据库管理员）。 想象一下所有账户余额和联系人全部丢失的场景，尽管发生概率微乎其微，即使是支付宝与微信，如果出现无法恢复的核心库删库事件，恐怕也只能吃不了兜着走了。 缘从何起？ 软件吃世界，开源吃软件，云吞噬开源，谁来吞噬云？ 很久很久以前，开发软件/信息服务需要使用非常昂贵的商业数据库软件：例如Oracle与 …

PostgreSQL中文社区又开始在线直播啦！本周日（5月23日晚7:30），由我带给大家来一段单口相声 —— 《开源PG全家桶上手指南》。 Pigsty是 开源 的PostgreSQL一条龙解决方案，主要有以下三个目标： 做最顶尖最专业的 开源PostgreSQL 监控系统 做门槛最低最好用的 开源PostgreSQL 管控方案 做开箱即用的数据分析可视化集成环境 \ \ 详情参考：https://pigsty.cc 谁会感兴趣？ PostgreSQL DBA，运维，DevOps：Pigsty …

把数据库拉起来是一回事，部署专业水准的数据库集群又是另一回事。想要真正用好管好数据库，需要良好的架构设计让多种组件协同配合起来。今天我们就来介绍一下典型的高可用PgSQL集群架构及其 落地方式。 本文将以 Pigsty v0.8 为例，介绍高可用集群的设计与部署。 “ Pigsty针对大规模数据库集群监控与管理而设计，提供业界顶尖的PostgreSQL监控系统与开箱即用的高可用数据库供给方案，为用户带来极致的可观测性与丝滑的数据库使用体验。 Pigsty基于开源生态构建，旨在降低 …

为什么Pigsty在初始化Postgres数据库时默认指定了 locale=C 与 encoding=UTF8 答案其实很简单，除非真的明确知道自己会用到LOCALE相关功能，否则就根本不应该配置 C.UTF8 之外的任何字符编码与本地化排序规则选项。 关于字符编码的部分，之前写过一篇文章专门介绍，这里表过不提。今天专门说一下 LOCALE（本地化）的配置问题。 如果说服务端字符编码配置因为某些原因配置为 UTF8 之外的值也许还情有可原，那么 LOCALE 配置为 C 之外的任何选就是 无可救 …

逻辑复制 逻辑复制（Logical Replication），是一种根据数据对象的 复制标识（Replica Identity）（通常是主键）复制数据对象及其变化的方法。 逻辑复制 这个术语与 物理复制 相对应，物理复制使用精确的块地址与逐字节复制，而逻辑复制则允许对复制过程进行精细的控制。 逻辑复制基于 发布（Publication） 与 订阅（Subscription）模型： 一个 发布者（Publisher） 上可以有多个 发布，一个 订阅者（Subscriber） 上可以有多个 订阅 …

引子：土法逻辑复制 复制身份的概念，服务于 逻辑复制。 逻辑复制的基本工作原理是，将逻辑发布相关表上 对行的增删改 事件解码，复制到逻辑订阅者上执行。 逻辑复制的工作方式有点类似于行级触发器，在事务执行后对变更的元组逐行触发。 假设您需要自己通过触发器实现逻辑复制，将一章表A上的变更复制到另一张表B中。通常情况下，这个触发器的函数逻辑通常会长这样： -- 通知触发器 CREATE OR REPLACE FUNCTION replicate_change() RETURNS TRIGGER AS …

You can’t optimize what you can’t measure 慢查询是在线业务数据库的大敌，如何诊断定位慢查询是DBA的必修课题。 本文介绍了使用监控系统 —— Pigsty诊断慢查询的一般方法论。 慢查询：危害 对于实际服务于在线业务事务处理的PostgreSQL数据库而言，慢查询的危害包括： 慢查询挤占数据库连接，导致普通查询无连接可用，堆积并导致数据库雪崩。 慢查询长时间锁住了主库已经清理掉的旧版本元组，导致流复制重放进程锁死，导致主从复制延迟。 查询越慢，查询间相 …

摘要：机器因为故障重启，NTP服务在PG启动后修复了PG的时间，导致 Patroni 无法启动。 Patroni中的故障信息如下所示： Process %s is not postmaster, too much difference between PID file start time %s and process start time %s patroni 进程启动时间和pid时间不一致。就会认为：postgres is not running。 两个时间相差超过30秒。patroni 就 …

如何在线修改主键列类型，比如将 INT 至 BIGINT，同时又不影响业务？ 假设在PG中有一个表，在设计的时候拍脑袋使用了 INT 整型主键，现在业务蓬勃发展发现序列号不够用了，想升级到BIGINT类型。这时候该怎么做呢？ 拍脑袋的方法当然是直接使用DDL修改类型： ALTER TABLE pgbench_accounts ALTER COLUMN aid SET DATA TYPE BIGINT; 但这种方式对于访问频繁的生产大表是不可行的 太长；不看 让我们以 pgbench 自带的场景为 …

前言 玩数据库和玩车有一个共通之处，就是都需要经常看仪表盘。 盯着仪表盘干什么，看指标。为什么看指标，掌握当前运行状态才能有效施加控制。 车有很多指标：车速，胎压，扭矩，刹车片磨损，各种温度，等等等等，各式各样。 但人的注意力空间有限，仪表盘也就那么大， 所以，指标可以分两类： 你会去看的：黄金指标 / 关键指标 / 核心指标 你不会看的：黑匣子指标 / 冷指标。 黄金指标就是那几个关键性的核心数据，需要时刻保持关注（或者让自动驾驶系统/报警系统替你时刻保持关注），而冷指标通常只有故障排查时才 …

名之则可言也，言之则可行也。 概念及其命名是非常重要的东西，命名风格体现了工程师对系统架构的认知。定义不清的概念将导致沟通困惑，随意设定的名称将产生意想不到的额外负担。因此需要审慎地设计。 TL;DR 集群（Cluster） 是基本自治单元，由用户指定唯一标识，表达业务含义，作为顶层命名空间。 集群在硬件层面上包含一系列的 节点（Node），即物理机，虚机（或Pod），可以通过IP唯一标识。 集群在软件层面上包含一系列的 实例（Instance），即软件服务器，可以通过IP:Port唯一标识。 …

管数据库和管人差不多，都需要定KPI（关键性能指标）。那么数据库的KPI是什么？本文介绍了一种衡量PostgreSQL负载的方式：使用一种单一横向可比，与负载类型和机器类型基本无关的指标，名曰 PG Load（PG负载）。 0x01 Introduction 在现实生产中，经常会有衡量数据库性能与负载，评估数据库水位的需求。一种最朴素的形式就是，能不能有一个类似于KPI的单一指标，能直接了当地告诉用户他心爱的数据库负载有没有超过警戒线？工作量到底饱和不饱和？ 当然这里其实隐含着一个重要信息，即用 …

场景 在数据库的生命周期中，有一类需求是很常见的，修改字段类型。例如： 使用 INT 作为主键，结果发现业务红红火火，INT32的21亿序号不够用了，想要升级为 BIGINT 使用 BIGINT 存身份证号，结果发现里面有个 X 需要改为 TEXT 类型。 使用 FLOAT 存放货币，发现精度丢失，想要修改为Decimal 使用 TEXT 存储JSON字段，想用到PostgreSQL的JSON特性，修改为JSONB类型。 那么，如何应对这种需求呢？ 常规操作 通常来说，ALTER TABLE 可 …

今天遇到一个比较有趣的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 当然，这种错误一眼就知道是插件没编译好，报符号找不到。因此数据库后端进程在启动时尝试加载 …

PostgreSQL的并发控制以 快照隔离（SI） 为主，以 两阶段锁定（2PL） 机制为辅。PostgreSQL对DML（SELECT, UPDATE, INSERT, DELETE 等命令）使用SSI，对DDL（CREATE TABLE 等命令）使用2PL。 PostgreSQL有好几类锁，其中最主要的是 表级锁 与 行级锁，此外还有页级锁，咨询锁等，表级锁 通常是各种命令执行时自动获取的，或者通过事务中的 LOCK 语句显式获取；而行级锁则是由 SELECT FOR …

复制是系统架构中的核心问题之一。 集群拓扑 假设我们使用4单元的标准配置：主库，同步从库，延迟备库，远程备库，分别用字母M,S,O,R标识。 M：Master, Main, Primary, Leader, 主库，权威数据源。 S: Slave, Secondary, Standby, Sync Replica，同步副本，需要直接挂载至主库 R: Remote Replica, Report instance，远程副本，可以挂载到主库或同步从库上 O: Offline，离线延迟备库，可以挂载到主 …

备份是DBA的安身立命之本，也是数据库管理中最为关键的工作之一。有各种各样的备份，但今天这里讨论的备份都是物理备份。物理备份通常可以分为以下四种： 热备（Hot Standby）：与主库一模一样，当主库出现故障时会接管主库的工作，同时也会用于承接线上只读流量。 温备（Warm Standby）：与热备类似，但不承载线上流量。通常数据库集群需要一个延迟备库，以便出现错误（例如误删数据）时能及时恢复。在这种情况下，因为延迟备库与主库内容不一致，因此不能服务线上查询。 冷备（Code Backup）： …

PostgreSQL驾驶技巧 PostgreSQL是一个很棒的数据库，但也相当复杂。上手虽简单，但想要用好不容易，想要管理好就更麻烦了。监控系统是几乎所有运维工作的基础，更亦是驾驭数据库的必备工具。用好一个监控系统，理解各种指标背后的意义并不是一件简单的事情，因此本司机决定写一系列文章，来介绍了PostgreSQL监控系统的设计，实施与使用。 0x01 PostgreSQL监控面板 为了帮助读者形成一种直觉，这里展示了在实际环境中，我所使用的监控面板。最为常用的监控面板为“单数据库实例”监控，并 …

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

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

PostgreSQL使用了MVCC作为主要并发控制技术，它有很多好处，但也会带来一些其他的影响，例如关系膨胀。关系（表与索引）膨胀会对数据库性能产生负面影响，并浪费磁盘空间。为了使PostgreSQL始终保持在最佳性能，有必要及时对膨胀的关系进行垃圾回收，并定期重建过度膨胀的关系。 在实际操作中，垃圾回收并没有那么简单，这里有一系列的问题： 关系膨胀的原因？ 关系膨胀的度量？ 关系膨胀的监控？ 关系膨胀的处理？ 本文将详细说明这些问题。 关系膨胀概述 假设某个关系实际占用存储100G，但其中有很 …

官方网站：https://www.timescale.com 官方文档：https://docs.timescale.com/v0.9/main Github：https://github.com/timescale/timescaledb 为什么使用TimescaleDB 什么是时间序列数据？ 我们一直在谈论什么是“时间序列数据”，以及与其他数据有何不同以及为什么？ 许多应用程序或数据库实际上采用的是过于狭窄的视图，并将时间序列数据与特定形式的服务器度量值等同起来： Name: CPU …

PipelineDB安装与配置 PipelineDB可以直接通过官方rpm包安装。 加载PipelineDB需要添加动态链接库，在 postgresql.conf 中修改配置项并重启： shared_preload_libraries = 'pipelinedb' max_worker_processes = 128 注意如果不修改 max_worker_processes 会报错。其他配置都参照标准的PostgreSQL PipelineDB使用样例 —— 维基PV数据 -- 创建Stream …

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

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

表的空间布局 宽泛意义上的 表（Table），包含了 本体表 与 TOAST表 两个部分： 本体表，存储关系本身的数据，即狭义的关系，relkind='r'。 TOAST表，与本体表一一对应，存储过大的字段，relinkd='t'。 而每个表，又由 主体 与 索引 两个 关系（Relation） 组成（对本体表而言，可以没有索引关系） 主体关系：存储元组。 索引关系：存储索引元组。 每个 关系 又可能会有 四种分支： main: 关系的主文件，编号为0 fsm：保存关于main分支中空闲空间的信 …

PgAdmin4的安装与配置 PgAdmin是一个为PostgreSQL定制设计的GUI。用起来很不错。可以以本地GUI程序或者Web服务的方式运行。因为Retina屏幕下面PgAdmin依赖的GUI组件显示效果有点问题，这里主要介绍如何以Web服务方式（Python Flask）配置运行PgAdmin4。 下载 PgAdmin可以从官方FTP下载。 postgresql网站FTP目录地址 wget …

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

一些PostgreSQL与Bash交互的技巧。 使用严格模式编写Bash脚本 使用Bash严格模式，可以避免很多无谓的错误。在Bash脚本开始的地方放上这一行很有用： set -euo pipefail -e：当程序返回非0状态码时报错退出 -u：使用未初始化的变量时报错，而不是当成NULL -o pipefail：使用Pipe中出错命令的状态码（而不是最后一个）作为整个Pipe的状态码1。 执行SQL脚本的Bash包装脚本 通过psql运行SQL脚本时，我们期望有这么两个功能： 能向脚本中传入 …

汽车需要上油，数据库也需要维护保养。 PG中的维护工作 对Pg而言，有三项比较重要的维护工作：备份、重整、清理 备份（backup）：最重要的例行工作，生命线。 制作基础备份 归档增量WAL 重整（repack） 重整表与索引能消除其中的膨胀，节约空间，确保查询性能不会劣化。 清理（vacuum） 维护表与库的年龄，避免事务ID回卷故障。 更新统计数据，生成更好的执行计划。 回收死元组。节约空间，提高性能。 备份 备份可以使用 pg_backrest 作为一条龙解决方案，但这里考虑使用脚本进行备 …

备份是DBA的安身立命之本，有备份，就不用慌。 备份有三种形式：SQL转储，文件系统备份，连续归档 1. SQL转储 SQL 转储方法的思想是： 创建一个由SQL命令组成的文件，服务器能利用其中的SQL命令重建与转储时状态一样的数据库。 1.1 转储 工具 pg_dump、pg_dumpall 用于进行SQL转储。结果输出到stdout。 pg_dump dbname > filename pg_dump dbname -f filename pg_dump 是一个普通的PostgreSQL客户 …

Pgbouncer是一个轻量级的数据库连接池。 概要 pgbouncer [-d][-R][-v][-u user] <pgbouncer.ini> pgbouncer -V|-h 描述 pgbouncer 是一个PostgreSQL连接池。 任何目标应用程序都可以连接到 pgbouncer， 就像它是PostgreSQL服务器一样，pgbouncer 将创建到实际服务器的连接， 或者它将重用其中一个现有的连接。 pgbouncer 的目的是为了降低打开PostgreSQL新连接时的性能影响。 …

pgBackRest主页：http://pgbackrest.org pgBackRest Github主页：https://github.com/pgbackrest/pgbackrest 前言 pgBackRest旨在提供一个简单可靠，容易纵向扩展的PostgreSQL备份恢复系统。 pgBackRest并不依赖像tar和rsync这样的传统备份工具，而在内部实现所有备份功能，并使用自定义协议来与远程系统进行通信。 消除对tar和rsync的依赖可以更好地解决特定于数据库的备份问题。 自定义 …

sysbench首页：https://github.com/akopytov/sysbench 安装 二进制安装，在Mac上，使用brew安装sysbench。 brew install sysbench --with-postgresql 源代码编译（CentOS）： yum -y install make automake libtool pkgconfig libaio-devel # For MySQL support, replace with mysql-devel on …

Fio是一个很好用的磁盘性能测试工具，可以通过以下命令测试磁盘的读写性能。 fio --filename=/tmp/fio.data \ -direct=1 \ -iodepth=32 \ -rw=randrw \ --rwmixread=80 \ -bs=4k \ -size=1G \ -numjobs=16 \ -runtime=60 \ -group_reporting \ -name=randrw \ --output=/tmp/fio_randomrw.txt \ && unlink …

通常涉及到数据迁移，常规操作都是停服务更新。不停机迁移数据是相对比较高级的操作。 不停机数据迁移在本质上，可以视作由三个操作组成： 复制：将目标表从源库 逻辑复制 到宿库。 改读：将应用 读取路径 由源库迁移到宿库上。 改写：将应用 写入路径 由源库迁移到宿库上。 但在实际执行中，这三个步骤可能会有不一样的表现形式。 逻辑复制 使用逻辑复制是比较稳妥的做法，也有几种不同的做法：应用层逻辑复制，数据库自带的逻辑复制（PostgreSQL 10 之后的逻辑订阅），使用第三方逻辑复制插件（例如 …

建议配置PostgreSQL的日志格式为CSV，方便分析，而且可以直接导入PostgreSQL数据表中。 日志相关配置项 log_destination ='csvlog' logging_collector =on log_directory ='log' log_filename ='postgresql-%a.log' log_min_duration_statement =1000 log_checkpoints =on log_lock_waits =on log_statement …

索引很有用， 但不是免费的。没用到的索引是一种浪费，使用以下SQL找出未使用的索引： 首先要排除用于实现约束的索引（删不得） 表达式索引（pg_index.indkey 中含有0号字段） 然后找出走索引扫描的次数为0的索引（也可以换个更宽松的条件，比如扫描小于1000次的） 找出没有使用的索引 视图名称：monitor.v_bloat_indexes 计算时长：1秒，适合每天检查/手工检查，不适合频繁拉取。 验证版本：9.3 ~ 10 功能：显示当前数据库索引膨胀情况。 在版本9.3与10.4上 …

配置SSH是运维工作的基础，有时候还是要老生常谈一下。 生成公私钥对 理想的情况是全部通过公私钥认证，从本地免密码直接连接所有数据库机器。最好不要使用密码认证。 首先，使用 ssh-keygen 生成公私钥对 ssh-keygen -t rsa 注意权限问题，ssh内文件的权限应当设置为 0600，.ssh 目录的权限应当设置为 0700，设置失当会导致免密登录无法使用。 配置ssh config穿透跳板机 把 User 换成自己的名字。放入 .ssh/config，这里给出了有跳板机环境下配置 …

Wireshark是一个很有用的工具，特别适合用来分析网络协议。 这里简单介绍使用Wireshark抓包分析PostgreSQL协议的方法。 假设调试本地PostgreSQL实例：127.0.0.1:5432 快速开始 下载并安装Wireshark：下载地址 选择要抓包的网卡，如果是本地测试选择 lo0 即可。 添加抓包过滤器，如果PostgreSQL使用默认设置，使用 port 5432 即可。 开始抓包 添加显示过滤器 pgsql，这样就可以滤除无关的TCP协议报文。 然后就可以执行一些操作 …

PostgreSQL是最先进的开源数据库，其中一个非常给力的特性就是FDW：外部数据包装器（Foreign Data Wrapper）。通过FDW，用户可以用统一的方式从Pg中访问各类外部数据源。file_fdw 就是其中随数据库附赠的两个fdw之一。随着pg10的更新，file_fdw 也添加了一颗赛艇的功能：从程序输出读取。 小霸王妙用无穷，我们能通过 file_fdw，轻松查看操作系统信息，拉取网络数据，把各种各样的数据源轻松喂进数据库里统一查看管理。 安装与配置 file_fdw 是Pg …

强烈建议使用使用 yum / apt 命令从 PostgreSQL 官方二进制仓库安装 PostGIS。 参考http://www.postgresonline.com/journal/archives/362-An-almost-idiots-guide-to-install-PostgreSQL-9.5,-PostGIS-2.2-and-pgRouting-2.1.0-with-Yum.html 1. 安装环境 CentOS 7 PostgreSQL10 PostGIS2.4 …

top free vmstat iostat top 显示Linux任务 摘要 按下空格或回车强制刷新 使用 h 打开帮助 使用 l,t,m 收起摘要部分。 使用 d 修改刷新周期 使用 z 开启颜色高亮 使用 u 列出指定用户的进程 使用 <> 来改变排序列 使用 P 按CPU使用率排序 使用 M 按驻留内存大小排序 使用 T 按累计时间排序 批处理模式 -b 参数可以用于批处理模式，配合 -n 参数指定批次数目。同时 -d 参数可以指定批次的间隔时间 例如获取机器当前的负载使用情况，以 …

更新：最近MongoFDW已经由Cybertech接手维护，也许没有这么不堪了。 最近有业务要求通过PostgreSQL FDW去访问MongoDB。开始我觉得这是个很轻松的任务。但接下来的事真是让人恶心的吐了。MongoDB FDW编译起来真是要人命：混乱的依赖，临时下载和Hotpatch，错误的编译参数，以及最过分的是错误的文档。总算，我在生产环境(Linux RHEL7u2)和开发环境(Mac OS X 10.11.5)都编译成功了。赶紧记录下来，省的下次蛋疼。 环境概述 理论上编译这套 …