最后的DBA

UUIDv4和v7两篇精彩文章-碰撞和性能

Fri, 29 May 2026 00:00:00 +0000

素材来源：HN UUID v4 碰撞帖、dev.to UUID Benchmark

AI率99%

太长不看
#

UUID v4 碰撞了——HackerNews 上有人真的撞了。原因是软件栈的 bug，不是数学。v4 和 v7 在碰撞安全性上没本质区别，差异在索引性能：v7 有时序，B-tree 更紧凑，写入快 35%、索引小 22%。你的 UUID v4 大概率没事，但如果你追求索引性能，换 v7 有实惠。

UUID v4 碰撞事故
#

HackerNews 上有个帖子火了——Ask HN: We just had an actual UUID v4 collision…，479 赞 347 评论。

发帖人的原话：

I know what you’re thinking… and I still can’t believe it, but… This morning, our database flagged a duplicate UUID (v4).

不是 double-insert 的 bug，不是代码写了两遍。库里只有 ~15,000 条记录，用 npm 的 uuid 包生成 uuidv4()，两个不同时间创建的行撞了同一个 UUID：

b6133fd6-70fe-4fe3-bed6-8ca8fc9386cd

UUID v4 碰撞的概率是多少？122 位随机位，2^122 ≈ 5.3×10^36 种可能，15,000 条记录下碰撞概率约 2×10^-29。理论上"不可能"。

但它发生了。

原因一：熵源不可靠
#

HN 最高赞评论（jandrewrogers）：

UUIDv4 的安全性依赖高质量熵源。硬件缺陷、软件 bug、对"高质量熵"的误解，都会让这个假设失效。检测熵源故障很贵，所以没人检查——直到撞了。

UUID v4 在高可靠系统中被明确禁止，原因是无法验证熵源质量。

原因二：npm uuid 包有已知 bug
#

uuid npm 包的 README 自己都在警告：

This module may generate duplicate UUIDs when run in clients with deterministic random number generators, such as Googlebot crawlers.

更严重的是，它的 rng() 函数内部有全局可变状态。一个评论者指出：调用 rng() 然后把结果发出去，等于覆盖了别人的随机数而且你能猜到它。

原因三：Linux 内核 /dev/random 竞态
#

另一个评论：

我在分布式系统的浸泡测试里碰到了 dup UUID。排查很久发现是 Linux 内核的一个竞态 bug——多处理器系统上，两个进程同时读 /dev/random，极低概率（~百万分之一）拿到相同的字节。

原因四：Go 的 UUID 库不检查返回值
#

早期 Go UUID 库调用随机数函数时，不检查返回值长度。“请求 N 字节，返回了 3 字节"的情况在大部分硬件上不出现，所以没人检查，直到上生产环境撞了成千上万个重复 UUID。

原因五：AMD CPU RNG 的历史缺陷
#

AMD 某些 CPU 的内置随机数生成器曾经有问题。VM 环境还会"虚拟化掉"熵——虚拟机的时间源和熵源都可能退化。

v4 和 v7 在碰撞安全性上没有本质区别，差异在前 48 位——v4 是随机数，v7 是时间戳。时序源出问题的情况你基本碰不到，随机源出问题的概率同样极低。HN 那个帖子是个有趣的特例，知道极少数人遇到了就行，不需要因此怀疑自己系统里的 UUID v4。

选 v4 还是 v7，真正该看的不是碰撞，是索引性能。

UUID v7 在 PG 16 中的性能对比
#

UUID v7 比 v4 在 PostgreSQL 里有一个实打实的优势：时序聚簇，B-tree 更友好。v4 膨胀 v7 也能膨胀，区别只是 v7 的前 48 位有时序，insert 集中在 B-tree 右侧，页分裂少。

Umang Sinha 的 benchmark 在 PG 16 Docker 容器（8 核 16GB NVMe）上做了严格的对比测试。

测试条件
#

CREATE TABLE uuid_v4_test (id UUID PRIMARY KEY, payload TEXT);
CREATE TABLE uuid_v7_test (id UUID PRIMARY KEY, payload TEXT);

参数	值
数据量	1000 万行/表
批次	每批 1 万行
客户端	Go + pq 驱动
UUID 预生成	在内存中生成好，不计时

性能结果
#

指标	UUID v4	UUID v7	提升
写入 1000 万行	5 分 35 秒	3 分 38 秒	35% 更快
表+索引总大小	3618 MB	3443 MB	5% 更小
B-tree 索引大小	776 MB	602 MB	22% 更小
单点查询	0.167 ms	0.038 ms	4.4 倍
范围扫描	8.283 ms	3.791 ms	2.2 倍

为什么差这么多
#

UUID v4 是完全随机的。新插入的 UUID 在 B-tree 索引里随机分布，导致大量页分裂（page split），索引碎片化严重。UUID v7 前 48 位是毫秒级时间戳，新生成的 UUID 天然有序——写入集中在 B-tree 的右侧，页分裂大幅减少，索引更紧凑。

索引小 22% 不是魔法，是减少了碎片。单点查询快 4 倍也不奇怪——B-tree 层级更少、缓存命中率更高。

总结
#

UUID v4 和 v7 在碰撞安全性上是一样的——都依赖熵源质量，一个用随机数填充前 48 位，一个用时间戳。碰撞是极少数人在特定环境下踩到的坑，你的环境大概率没事，这个基本判断不用变。

真正该琢磨的是索引性能。v7 的时序特性让 B-tree 更紧凑，实测写入快 35%、索引小 22%、查询快 2-4 倍。如果系统对 UUID 的写入量很大，换 v7 能省不少存储和 CPU。

PG 18 会原生支持 gen_uuid_v7()，目前可以应用层生成。不管用哪个版本，加 UNIQUE 约束总是对的。

一个 DBA 视角看 0526 安可数据库名单

Fri, 29 May 2026 00:00:00 +0000

AI率 5%

太长不看
#

5 月 26 日，信创数据库名单 2026 年第 2 号发布，23 款产品通过（8 集中式 + 15 分布式），为历次最多。最值得关注：平安、银联、移动、电信四家大甲方各自孵化的数据库首次入围。信创逻辑变了——甲方不再只是买方的角色。

批次	时间	数据库产品数	获Ⅱ级
2023#1	2023-12-26	11（集中式）	无
2024#2	2024-09-30	17（集中式6+分布式11）	GaussDB
2025#2	2025-08-22	3（集中式）	无
2026#2	2026-05-26	23（集中式8+分布式15）	达梦/崖山/GaussDB/GoldenDB

厂商	次数
达梦	3
南大通用	3
阿里云	3
瀚高	2
腾讯云	2
东方金信	2
海量数据	2
华为云	2
中兴(GoldenDB)	2
OceanBase	2
金仓	2
神通	2
虚谷	2
崖山	2
仅1次	平凯/万里/优炫/平安/移动/银联/天翼云/天谋/星环/智臾/自然原数/中移苏州

分类	厂商
大厂	华为云(GaussDB/TaurusDB/DWS)、阿里云(PolarDB/AnalyticDB)、腾讯云(TDSQL)、中兴(GoldenDB)、OceanBase(蚂蚁)
独角兽	平凯(TiDB)、崖山(深算院)、星环(ArgoDB)、天谋(TimechoDB)、智臾(DolphinDB)
大甲方	平安科技(RASESQL)、中国银联(UPDRDB)、中国移动(磐维+He3DB)、天翼云(TeleDB)
老牌信创	达梦、金仓、南大通用、神通、瀚高、虚谷、海量、东方金信、万里、优炫

开闸放水
#

这次名单一出，我的感受就四个字：开闸放水。23 款产品，历次最多。几个看点：

平安 RASESQL。 最没有想到的一家。平安集团的金融科技能力一直很强，但他们做数据库这事此前几乎没有公开信息。看到榜单上出现 RASESQL 三个字的时候我愣了好几秒。平安这种体量的金融甲方，自研数据库一旦过了国测，内部信创替代路线就多了一条。

银联 UPDRDB。 同样神秘。之前完全不知道银联在做分布式数据库。银联的交易量摆在那，能扛住自己业务的分布式数据库，技术上不会差。

阿里云 PolarDB for MySQL。 PolarDB 的 MySQL 兼容版没过是记在许多人心里的。这次过后，PolarDB 三大主线——PG 版、分布式版、MySQL 版——全过了。加上 AnalyticDB，阿里云数据库全家桶基本凑齐。

移动磐维 + 电信 TeleDB。 移动去年已经有 He3DB（中移苏州）通过国测，今年磐维是第二个产品。电信 TeleDB 首次入围。两家运营商都有自家孵化的信创数据库，各自的信创替换压力应该小不少。反倒是联通一直没有动静——可以想见联通的信创战略跟移动电信肯定不一样。

星环 ArgoDB。 星环是大数据/Hadoop 生态起家的，现在分布式数据库也过了国测。曾经顶着"国产大数据基础软件第一股"的光环，市值一度冲到 300 亿+，从数据湖到信创数据库，路线走通了。

影响
#

这次开闸放水，透露出的最重要的信号是——甲方可以自研数据库。

有什么影响？

自研成功的大甲方可以不用当待宰的肥羊
那些还没做出来的大甲方，可能会再次启动自研
大厂和独角兽在国内数据库市场上能争夺的蛋糕，少了一块

金融行业的银联、平安，电信行业的移动、电信，都成功通过了国测，等于是"研发成功"的金徽章，各单位内部应该都是喜大普奔的状态。而对于外部厂商来说，他们丢失的不只是大客户，准确一点说，丢失了绝对话语权。

“我知道你困难，也知道你不买不行，所以杀猪刀不磨了，直接换屠龙刀往死里宰”——对于成功孵化自研数据库的甲方来说，这种处境就释缓了许多，意义重大。

至于未来信创方向会怎么变动，谁都说不好。从以前的名单看应该是越来越严（上次数据库名单只过了 3 个），这次反倒意外地开闸放水。下次急剧收拢也不是不可能。不仅是联通，保险行业的太保、人保，甚至金融行业有能力的都可以考虑下场自己手搓一个数据库。

令人唏嘘
#

因为我们内核组就坐在我背后，我还算了解一些信创研发的经过。在连续送测均未通过的情况下，整个团队氛围是极其低落的，我相信不止我们是这样，许多送测通不过的团队也是这样。对于金融、电信等行业来说就是有信创要求，但是自研的产品没有过安可，在公司战略层面就没有选择，在团队层面也当然没有了存在价值。所以“过国测”这三个字含金量、影响力都非常大。还好他们过了，真心祝贺他们！RaseSQL No1！

同时可以看出，信创结果和风向不稳定，变化大，影响大。它决定了一些公司的战略，也决定了许多人的命运。我自己甚至都是这命运轮盘中的一员。

除了信创名单上的，还有许多不在名单又付出了巨大努力的单位。他们的产品可能很拉，也可能非常好。但国测就是这样严峻的分水岭，一张神秘的入场券——过与不过，在国内市场，就是两个概念。

OK，有感而发，可能会删。

参考
#

https://www.itsec.gov.cn/aqkkcp/cpgg/

当 PostgreSQL 成为 AI 的双手——Bruce Momjian 的 MCP Server 实战

Wed, 27 May 2026 00:00:00 +0000

原文：Building an MCP Server Using Postgres，Bruce Momjian，PGDay Armenia 2026，CC BY 4.0。

本文AI率80%

Bruce Momjian（PG core team，写了 20 多年发行注记的那位）最近在 PGDay Armenia 2026 做了一个演讲：Building an MCP Server Using Postgres。70 页幻灯片，信息密度极高。有理论，有实践，是一个不错的借鉴。

直接读是比较费劲的，哪怕是直接让AI解读一下估计也不知道说的是什么，我也是看了一会问了几个问题后才算看明白了。

这 70 页可以清晰地切成两层——前半部分是理论教学，后半部分是实战 demo。两层之间，关系不大。

理论层：用 Transformer 解释 RAG → MCP 的演进（Slide 1-33）
#

理论层占了近一半篇幅，从 LLM 基本原理讲到 MCP 的工作方式。Outline 很清楚：

RAG vs MCP：一句话说清
#

RAG 的流程大家都熟了：程序员决定查什么数据 → 检索结果拼到 system prompt → LLM 读完后生成回答。预编排——LLM 能看到什么，在用户提问之前就定好了。

MCP 不一样。工具描述注册给 LLM，LLM 在生成过程中自己判断要不要调工具、调哪个。动态决策——程序员只负责暴露工具，LLM 负责编排。

Bruce 用一句话总结：

RAG 只能做程序员预设的事。MCP 可以根据输出质量动态调整，可以迭代调用多个工具，还可以触发外部任务。

“是词还是 MCP”——那套向量嵌入图解
#

Slide 18-33 是理论层最核心的部分。Bruce 画了一套详细的 Transformer 内部流程图：

他的逻辑是：把每个 MCP tool 的描述文本（比如 “Return the radiation level (CPM) at 13 Roberts Road…"）用文本嵌入模型向量化，塞进 attention 层的向量空间里。然后在每一步推理时，output vector 去匹配最近似的向量——

“The closest vector might be a word or an MCP.”

这个模型对吗？
#

这是我最疑惑的地方，以下是我的浅见。

Bruce 这 15 页 slides 画得很好看，但如果当工程实现去理解，是有问题的：

① MCP tool 不需要"嵌入”。 实际工程中，tool 定义是作为文本直接写在 system prompt 里的。LLM 读到 “你有这些工具：geiger()、get_pretzel_inventory()…"，靠语义理解决定什么时候调。不需要把 tool 描述算成向量，不需要和词向量做余弦距离比较。Bruce 这套教学模型的本质是把"LLM 决策"解释成"向量最近似匹配”，这更像 retrieval 的范式而不是 generation 的范式。

② Attention 不产出"查最近似"的操作。 output = Σ(softmax(Q·K) × V)，产出的是一个加权混合后的上下文向量。没有"在词向量表和 tool 向量表里二选一"这一步。LLM 选工具的实际机制是 attention 产出 hidden state → LM head → softmax over 词表 → 输出 tool call JSON。从来没有在"词和 tool 之间二选一"，只有在整个词表上做 softmax。

③ system prompt 和 user prompt 在 attention 里没有边界。 Token 序列就是 token 序列，attention block 对所有 token 一视同仁做 Q·K 点积。不存在"system 区"和"user 区"。

所以这 33 页理论层，可以看作 Bruce 给非 AI 背景的 DBA 做的一个教学简化模型——好看、好懂，但别当架构图用。MCP 真正革命性的地方在协议标准化（统一的 tool 注册/发现/调用规范），不在向量化的 trick。

实践层：两个能跑的 demo（Slide 34-69）
#

从 Slide 34 开始，风格突变——全是代码、终端输出、硬件照片。理论层那套 Transformer 向量模型完全消失了，取而代之的是 curl、psql、Perl 脚本。

两层之间的唯一联系是"它们都在讲 MCP"，但理论层画的向量匹配机制和实战中的实现方式几乎是两套逻辑。这可能正是 Bruce 演讲的张力所在——理论层让你理解 MCP 为什么比 RAG 强，实践层告诉你现在怎么落地。

Demo 1：让 ChatGPT 读取真实世界的盖革计数器
#

Bruce 在自家院子里架了一台 GQ GMC-800 盖革计数器（测辐射的），USB 接树莓派，每 15 分钟测一次环境辐射。先看 ChatGPT 用 MCP 调用真实数据的效果：

MCP 可以调用外部工具获取实时数据——这是 RAG 做不到的。

接上硬件：

用 fastmcp 写了 Python wrapper：

from fastmcp import FastMCP

mcp = FastMCP("Geiger counter MCP server")

@mcp.tool
def geiger() -> int:
 """Return the radiation level (CPM) at 13 Roberts Road, Newtown Square, PA, USA"""
 return subprocess.check_output(
 "/var/lib/postgresql/tmp/geiger", shell=True, text=True
 )

底层是一个 Perl 脚本，往串口发 <GETCPM>> 指令，读回 4 字节 CPM 值。Apache 做 443 端口反代（OpenAI 只跟 443 通信），注册到 ChatGPT 后：

User: 13 Roberts Road 的辐射水平是多少？
GPT: 我没有这个位置的公开数据……

User: 用我的 custom app
GPT: [调用 geiger tool] → 14 CPM。正常环境背景辐射（5-25 CPM）。

User: 测五次，给我平均值
GPT: [调用 ×5] 15 16 13 15 15 → 平均 14.8 CPM

两个关键行为：

LLM 可以迭代调工具做计算——RAG 是一次性塞数据，MCP 是"调 → 拿结果 → 判断 → 再调 → 算"
用户必须显式授权——第一次问的时候 ChatGPT 没说"我有你的盖革计数器数据"，直到说 “use my custom app” 才触发 tool call。安全模型很保守

Demo 2：用 PG 做椒盐卷饼店的库存系统
#

从硬件回到软件。建一个椒盐卷饼（pretzel）库存库：

CREATE TABLE pretzel (
 quantity INTEGER CHECK (quantity >= 0)
);
INSERT INTO pretzel VALUES (0); -- 初始库存 0

MCP tool 直接用 psql 操作 PG：

@mcp.tool
def get_pretzel_inventory() -> int:
 """Return the number of unsold pretzels"""
 return subprocess.check_output(
 "psql --tuples-only -c 'SELECT quantity FROM pretzel;' -d mcp",
 shell=True, text=True
 )

@mcp.tool
def sold_one_pretzel() -> str:
 """Call this when a pretzel is sold; reduces inventory by one"""
 return subprocess.check_output(
 "psql --tuples-only -c 'UPDATE pretzel SET quantity = quantity - 1;' -d mcp",
 shell=True, text=True
 )

@mcp.tool
def baked_6_pretzels() -> str:
 """Call this when a tray of 6 pretzels is baked; increases inventory"""
 return subprocess.check_output(
 "psql --tuples-only -c 'UPDATE pretzel SET quantity = quantity + 6;' -d mcp",
 shell=True, text=True
 )

交互流程：

User: How many pretzels available?
GPT: 0 pretzels.

User: I just baked a tray → 6 pretzels
User: I sold two → 4 remaining
User: I sold four → 0 remaining

User: I sold one pretzel → ERROR! CHECK constraint 阻止了 quantity 变负数

LLM 不直接写 SQL，而是调你预先定义的受控接口。PG 的 CHECK 约束天然构成了一个安全兜底——即使 LLM 被诱导调了不该调的函数，数据库层的约束还能挡一道。

但也暴露了问题：LLM 忠实执行了 sold_one_pretzel，但不会预判"库存已经是 0 了调了会报错"。MCP 是执行层，不是推理层。

生产还差多远
#

Bruce 在最后一页坦承了当前实现的局限：

没有认证——谁都可以调你的 MCP Server
没有参数化——三个 tool 都是无参函数，现实中的 tool 需要传参数
动态 SQL 没做安全限制——工具描述声明了语义，但 LLM 可能被注入恶意内容
连接池、事务管理、频率限制——一概没考虑

两篇值得读的实践经验：

两层之间
#

回头看这 70 页幻灯片，最有趣的不是任何一个 demo，而是MCP的理论思路和动手说明MCP能做什么：

理论层用 Transformer 向量空间解释"LLM 如何在词和工具之间做选择"——这是教学模型
实践层用 psql、curl、Perl 脚本去落地——这是工程实现

而真正的 MCP 机制——tool 定义当文本塞 system prompt、LLM 靠语义理解决定调哪个、输出 tool call JSON——应该是不需要理论层那套向量嵌入模型。两层之间，Bruce 没有画出来连接线。这可能不是 bug，是 feature。

个人博客上线

Sat, 16 May 2026 00:00:00 +0000

上线啦！
#

博客终于上线了。

地址：https://lastdba.com

国内可以访问，手机访问也友好

76 篇文章，都是这几年写 PostgreSQL 的东西——案例、内功、源码、论文精读。

这次算是正式上线：换框架、换域名、换主题，从头到尾搞了一遍。

亮点
#

界面漂亮

界面简约，阅读友好，搜索功能也比较有用

框架：Jekyll → Hugo

第一版：Jekyll + minima 主题 + 2000 行 CSS

第二版：Hugo + Blowfish 主题 + 0 行 CSS

第一版其实也不错，就是自己搞UI很费劲，想到老冯之前写过一个文章关于网站架构选择的，我直接就上去白嫖了。把架构跟AI说明，让它偷学vonng.com，页面质感提升了一个档次，后面再调整调整细节就收工了。

域名：github.io → lastdba.com

买了 lastdba.com，配了 Cloudflare。GitHub Pages 绑自定义域名，免费 HTTPS 证书，全自动续。不用科学上网也可以访问了！

图片本地化

原来文章里的图片散落在各个地方——CSDN 的 CDN、GitHub PicBed、墨天轮 OSS。CSDN 有防盗链，不给看。GitHub PicBed又是外网的，国内经常加载不出来。这次让AI搞到本地路径，以后再也不怕图床跑路。跨网访问也不会有图片加载不出来的问题，very good。

上线感悟
#

其实博客网址以前也搞过，白嫖一个博客网站项目然后用GitHub Pages就可以搭建出来，域名是 liuzhilong62.github.io/blogs。但是由于个人有些质感癖（不是），效果一般般我就下线了，后面直接把github仓库当博客网址用，pages都没有搞。最近由于各种原因时间比较多，再次想起这个事情，就用hermes从头开始弄博客网站。

作为一个DBA，后端工程师，什么Jekyll，Hugo，Blowfish，css这些前端的东西我完全不懂，我只需要给Hermes目标，然后它做，它跟我说啥我也听不懂（当然也不好意思跟它说我搞不懂），基本就是"你继续"，我网页端看下效果满意就行，偶尔会"回退这个"。

说实话，换 Hugo 最大的感受不是技术上的，而是「不要重新发明轮子」。之前花了很多时间手写暗色模式、TOC、搜索，结果发现换个主题全自带，写得还不如人家好看。

另外，lastdba.com 这个域名挂上去之后，博客突然有了一种「正式感」。以前 liuzhilong62.github.io/blogs 像是个人的实验项目，现在像一个真正的网站。虽然内容没变，但感觉不一样了。

花了多少钱
#

全部费用：

项目	费用
`lastdba.com` 域名（Cloudflare，1年）	¥70
GitHub Pages 托管	¥0
Hugo 框架	¥0
Blowfish 主题	¥0
Cloudflare DNS + CDN	¥0
token	¥60
合计	¥130

这可能是性价比最高的个人网站方案了。

最后
#

有些细节可能没有打磨好，欢迎反馈bug，优化建议

后面应该会持续更新

参考
#

https://vonng.com/

案例-起库失败和sysv共享内存

Mon, 09 Mar 2026 00:00:00 +0000

问题现象
#

数据库实例RSS内存打满，日志有OOM信息，库挂了。这里不分析OOM原因。

但是起库的时候失败，从日志来看总共起库4、5次都失败：

2026-02-12 09:15:21 CST::@:[578272]: FATAL: pre-existing shared memory block (key 2048, ID 1328250881) is still in use
2026-02-12 09:15:21 CST::@:[578272]: HINT: Terminate any old server processes associated with data directory "/data".
2026-02-12 09:15:21 CST::@:[578272]: LOG: database system is shut down
2026-02-12 09:21:03 CST::@:[658824]: FATAL: pre-existing shared memory block (key 2048, ID 1328250881) is still in use
2026-02-12 09:21:03 CST::@:[658824]: HINT: Terminate any old server processes associated with data directory "/data".
2026-02-12 09:21:03 CST::@:[658824]: LOG: database system is shut down
2026-02-12 09:31:12 CST::@:[794791]: LOG: redirecting log output to logging collector process
2026-02-12 09:31:12 CST::@:[794791]: HINT: Future log output will appear in directory "/data/pg_log".
2026-02-12 09:31:37 CST::@:[801049]: FATAL: lock file "postmaster.pid" already exists
2026-02-12 09:31:37 CST::@:[801049]: HINT: Is another postmaster (PID 794791) running in data directory "/data"?
2026-02-12 09:32:34 CST::@:[814396]: FATAL: lock file "postmaster.pid" already exists
2026-02-12 09:32:34 CST::@:[814396]: HINT: Is another postmaster (PID 794791) running in data directory "/data"?

启动成功是因为DBA在起库前执行ipcrm -m xxx，然后启动成功的。

虽然快速解决问题，但是仍有很多疑问：

为什么这种场景在现实种不算太多见？
start.log起库报错有2类，分别对应什么操作和逻辑？
如果PM都不在了共享内存还可以存在吗？
这段共享内存如何定位和清理？
PG共享内存有多段，这段共享内存是哪一段？
除了ipcrm -m还有其他起库办法吗

报错分析：`pre-existing shared memory block`
#

3种共享内存
#

正常来说，PG起库后共享内存有三段。

以默认“shared_memory_type='mmap'+未使用大页”为例：

## 从PG申请的虚拟内存查看PG真实使用共享内存
cat /proc/`head -1 $PGDATA/postmaster.pid`/smaps | grep -E "\-s"

2b61b0563000-2b61b0564000 rw-s 00000000 00:04 116293664 /SYSV00001000 (deleted)
2b61b057f000-2b61b05b3000 rw-s 00000000 00:12 1501001168 /dev/shm/PostgreSQL.1193490778
2b61bbac2000-2b61fa67a000 rw-s 00000000 00:04 1500999610 /dev/zero (deleted)

如上所示，从上往下分别是SYSV起库使用的共享内存、并行计算使用的共享内存、sharedbuffers使用的共享内存。

如果sharedbuffers使用了大页，或者sharedbuffers type是SYSV而不是mmap，输出会稍微有些区别。

大页：

2aaaaac00000-2aba9ca00000 rw-s 00000000 00:0e 48453452 /anon_hugepage (deleted)
2b08f2eea000-2b08f2eeb000 rw-s 00000000 00:04 50692152 /SYSV00001000 (deleted)
2b08f2f05000-2b08f302d000 rw-s 00000000 00:12 48436142 /dev/shm/PostgreSQL.1345689218

shared_memory_type = ‘sysv’：

2b03b3ceb000-2b03b3d1f000 rw-s 00000000 00:12 1572332304 /dev/shm/PostgreSQL.2883611352
2b03bf0c2000-2b03fdc7a000 rw-s 00000000 00:04 143917075 /SYSV00001000 (deleted)

汇总如下：

PG共享内存配置	smaps共享内存段数	sharedbuffers smaps	sysv smaps
shared_memory_type=mmap，没有大页	3段共享内存	/dev/zero	/SYSV00001000
shared_memory_type=sysv，没有大页	2段共享内存	/SYSV00001000	/SYSV00001000
shared_memory_type=mmap，有大页	3段共享内存	/anon_hugepage	/SYSV00001000
shared_memory_type=sysv，有大页	不支持	不支持

那么现在问题来了，报错分析：pre-existing shared memory block时对应的哪个共享内存？

源码分析
#

源码搜报错很容易找到关键代码位置：src/backend/port/sysv_shmem.c

首先理解sysv shmem是干嘛的，以下截取自零散的readme：

We still require a SysV shmem block to
 * exist, though, because mmap'd shmem provides no way to find out how
 * many processes are attached, which we need for interlocking purposes.
 
 * As of PostgreSQL 9.3, we normally allocate only a very small amount of
 * System V shared memory, and only for the purposes of providing an
 * interlock to protect the data directory. The real shared memory block
 * is allocated using mmap(). This works around the problem that many
 * systems have very low limits on the amount of System V shared memory
 * that can be allocated. Even a limit of a few megabytes will be enough
 * to run many copies of PostgreSQL without needing to adjust system settings.

sysv shmem可以找共享内存是否是attached，mmap不能实现此功能
这段sysv shmem是用来保护datadir的；shared buffer用的是mmap（默认）不是sysv
这段sysv shmem非常小（从虚拟内存地址可以看出申请的是4K=2b61b0563000-2b61b0564000）

再看shm的状态enum：

typedef enum
{
	SHMSTATE_ANALYSIS_FAILURE,	/* unexpected failure to analyze the ID */
	SHMSTATE_ATTACHED,			/* pertinent to DataDir, has attached PIDs */
	SHMSTATE_ENOENT,			/* no segment of that ID */
	SHMSTATE_FOREIGN,			/* exists, but not pertinent to DataDir */
	SHMSTATE_UNATTACHED			/* pertinent to DataDir, no attached PIDs */
} IpcMemoryState;

主要是关注ATTACHED,FOREIGN,UNATTACHED。

sysv shmem是用来保护datadir目录的，比如常见的场景是要确认这个目录不会被跑2个实例。既然有shmem共享内存，那么因为各种奇怪原因，这个共享内存也有可能不是这个目录或者这个进程的，所有是FOREIGN状态。如果共享内存对应到datadir了，但没有进程在运行，那么应该是UNATTACHED，有进程运行那么是ATTACHED。

这时再来看PGSharedMemoryCreate函数抛出的报错：

PGShmemHeader *
PGSharedMemoryCreate(Size size,
					 PGShmemHeader **shim)
{...
 for (;;) //死循环
	{..
 shmid = shmget(NextShmemSegID, sizeof(PGShmemHeader), 0);//shmget获取shmem共享内存并返回shmid
		if (shmid < 0)
		{
			oldhdr = NULL;
			state = SHMSTATE_FOREIGN;
		}
		else
			state = PGSharedMemoryAttach(shmid, NULL, &oldhdr);//找到这段shmem共享内存的状态
 
 switch (state)//根据共享内存的状态执行不同的动作
		{ 
 ...//这里只展示了2种，shm有attach和没有attach
			case SHMSTATE_ATTACHED: //shm有attach的情况，抛出报错（也就是问题现象出现的报错）
				ereport(FATAL,
						(errcode(ERRCODE_LOCK_FILE_EXISTS),
						 errmsg("pre-existing shared memory block (key %lu, ID %lu) is still in use",
								(unsigned long) NextShmemSegID,
								(unsigned long) shmid),
						 errhint("Terminate any old server processes associated with data directory \"%s\".",
								 DataDir)));
				break;
 ...
			case SHMSTATE_UNATTACHED://shm是unattach的

				/*
				 * The segment pertains to DataDir, and every process that had
				 * used it has died or detached. Zap it, if possible, and any
				 * associated dynamic shared memory segments, as well. This
				 * shouldn't fail, but if it does, assume the segment belongs
				 * to someone else after all, and try the next candidate.
				 * Otherwise, try again to create the segment. That may fail
				 * if some other process creates the same shmem key before we
				 * do, in which case we'll try the next key.
				 */
 //代表内存段关联Data目录，且没有进程还持有这个段
				if (oldhdr->dsm_control != 0)
					dsm_cleanup_using_control_segment(oldhdr->dsm_control);
				if (shmctl(shmid, IPC_RMID, NULL) < 0)
					NextShmemSegID++; //注意这里的ShmemSegID递增循环
				break;
		}
 ...
 }
 ...
 }

可以看到shmem attached时会抛出报错。如果没有attach，会无限循环尝试清理这段共享内存并shmemsegid+1申请新的共享内存。

第一种情况对应这个故障
第二种情况对应实例崩溃仍然可以正常起库

sysv shmem
#

PG10及以后postmaster.pid，sysv_shmem相关的逻辑大改，10以后基本没有变过。本文只分析了10以后的逻辑。

pidfile.h:

#define LOCK_FILE_LINE_SHMEM_KEY	7

sysv_shmem.c，InternalIpcMemoryCreate()：

	{
		char		line[64];

		sprintf(line, "%9lu %9lu",
				(unsigned long) memKey, (unsigned long) shmid);
		AddToDataDirLockFile(LOCK_FILE_LINE_SHMEM_KEY, line);
	}

从源码可以看出，shmem信息保存在postmaster.pid文件第七行，分别写的是shmkey和shmid。

> cat postmaster.pid 
242712
/data
1772698474
8531
/tmp
0.0.0.0
 4096 143917078 # <----here
ready

什么是shmkey和shmid
#

在pg源码中是这样调用的，InternalIpcMemoryCreate()：

			shmid = shmget(memKey, 0, IPC_CREAT | IPC_EXCL | IPCProtection);

PG以shmkey/memkey为种子key，向内核申请shmem并返回唯一标识符shmid。

shmid高度依赖服务器或者说服务器内存的状态。对于PG来说，快速重启实例，前后的shmid可能会相同或者+1，这跟linux内核机制相关；服务器重启那就完全不一样。

可以这样增加理解度：无论服务器是否重启，shmkey/memkey都可以是固定值，因为毕竟是用户输入（即PG）；而在服务器重启前后，即便传入同一shmkey，获取的shmid不太可能是同一值。

PG是怎么拿shmkey的
#

PGSharedMemoryCreate()：

	/*
	 * We use the data directory's ID info (inode and device numbers) to
	 * positively identify shmem segments associated with this data dir, and
	 * also as seeds for searching for a free shmem key.
	 */
	if (stat(DataDir, &statbuf) < 0)
		ereport(FATAL,
				(errcode_for_file_access(),
				 errmsg("could not stat data directory \"%s\": %m",
						DataDir)));
...
	/*
	 * Loop till we find a free IPC key. Trust CreateDataDirLockFile() to
	 * ensure no more than one postmaster per data directory can enter this
	 * loop simultaneously. (CreateDataDirLockFile() does not entirely ensure
	 * that, but prefer fixing it over coping here.)
	 */
	NextShmemSegID = statbuf.st_ino;

	for (;;)
	{
		IpcMemoryId shmid;
		PGShmemHeader *oldhdr;
		IpcMemoryState state;

		/* Try to create new segment */
		memAddress = InternalIpcMemoryCreate(NextShmemSegID, sysvsize);
		if (memAddress)
			break;				/* successful create and attach */

		/* Check shared memory and possibly remove and recreate */

		/*
		 * shmget() failure is typically EACCES, hence SHMSTATE_FOREIGN.
		 * ENOENT, a narrow possibility, implies SHMSTATE_ENOENT, but one can
		 * safely treat SHMSTATE_ENOENT like SHMSTATE_FOREIGN.
		 */
		shmid = shmget(NextShmemSegID, sizeof(PGShmemHeader), 0);

PG通过stat获取datadir的状态，其中包含datadir的inode，PG直接将datadir.inode当作shmkey。

在PG中shmem key跟datadir的inode强相关，一般情况下shmem key=datadir inode

验证示例：

> ls -id $PGDATA
4096 /lzlcloud/pg8574/data
> cat postmaster.pid |head -7|tail -1
 4096 143917090

可以看到datadir.inode=shmkey=4096。

PG在云环境下的shmkey
#

上面说一般情况shmid=datadir.inode，实际上这在云环境中基本不是这个情况。

我们的云环境：

> ls -id /lzlcloud/pg8298/data
4096 /lzlcloud/pg8298/data
> ls -id /lzlcloud/pg8388/data
4096 /lzlcloud/pg8388/data
> ls -id /lzlcloud/pg8095/data
4096 /lzlcloud/pg8095/data

> cat /lzlcloud/pg8298/data/postmaster.pid|head -7|tail -1
 4096 971833391
> cat /lzlcloud/pg8388/data/postmaster.pid|head -7|tail -1
 4097 62128161
> cat /lzlcloud/pg8095/data/postmaster.pid|head -7|tail -1
 4098 143163441

data盘dir的inode都是4096，而shmkey是4096、4097、4098

why?

inode的问题跟磁盘的文件系统有关系：

每个文件系统有独立的inode
文件系统预留了一些inode，前几位是不能使用的。根据不同的挂载方式，我们data盘真正的inode从4096开始

也就是说datadir.inode=4096这是我们云环境磁盘挂载的默认行为。其他环境可能不一样，未深入分析。不过以相同文件系统和相同方式挂载挂载pg datadir的话，仍有可能inode数值相等。

shmkey的问题跟PG源码相关,PGSharedMemoryCreate()：

	for (;;)
	{	
 ...
 NextShmemSegID = statbuf.st_ino;
 ...
		shmid = shmget(NextShmemSegID, sizeof(PGShmemHeader), 0);
		...
		switch (state)
		{
			case SHMSTATE_FOREIGN:
				NextShmemSegID++;
				break;

本来shmkey=datadir.inode，但是由于可能申请到shmem是foreign的，所以shmkey+1再申请一次。

例如postmaster.pid文件shmkey=4097的那个实例，它起库时shmkey=4096，但是发现shmid那个内存段被其他实例使用了（就是另一个shmkey=4096的PG实例），它让shmkey+1再申请了另一个shmid共享内存段。

同理shmkey=4098的那个实例加了2次才找到空闲的shmkey对应的shmid。

shmid的关联性
#

sysv的shmid可以在起库的报错日志、postmaster.pid文件第7行、虚拟内存地址smaps中均可以找到，并通过sysv共享内存命令的ipcs命令查看和ipcrm命令清理。

示例：注意以下shmid=143917078

起库报错日志：

pg_ctl: another server might be running; trying to start server anyway
waiting for server to start....2026-03-05 16:02:19 CST::@:[262388]: FATAL: pre-existing shared memory block (key 4096, ID 143917078) is still in use

postmaster.pid文件第七行：

> cat postmaster.pid |head -7|tail -1
 4096 143917078

虚拟内存smaps：

cat /proc/`head -1 $PGDATA/postmaster.pid`/smaps | grep -E "\-s" 
2ad2b5189000-2ad2b518a000 rw-s 00000000 00:04 143917078 /SYSV00001000 (deleted)

通过shmid sysv共享内存id查看和清理：

ipcs -m -i 143917078 #清理：ipcrm -m shmid

Shared memory Segment shmid=143917078
uid=6001 gid=6001 cuid=6001 cgid=6001
mode=0600 access_perms=0600
bytes=56 lpid=242712 cpid=242712 nattch=10
att_time=Thu Mar 5 16:14:51 2026 
det_time=Thu Mar 5 16:14:49 2026 
change_time=Thu Mar 5 16:14:34 2026 

测试
#

生产问题复现
#

持有一个backend进程永不退出，kill -9 PM

> cat postmaster.pid
 4096 143917076
 
> ipcs -m -i 143917076 #shmem id
Shared memory Segment shmid=143917076
uid=6001 gid=6001 cuid=6001 cgid=6001
mode=0600 access_perms=0600
bytes=56 lpid=241567 cpid=64757 nattch=23 

> kill -stop 107648 #任意一个backend

> kill -9 64757 #postmaster或者其他的

> ipcs -m -i 143917076
Shared memory Segment shmid=143917076
uid=6001 gid=6001 cuid=6001 cgid=6001
mode=0600 access_perms=0600
bytes=56 lpid=252283 cpid=64757 nattch=1 #nattch != 0

> pg_ctl start -D $PGDATA
pg_ctl: another server might be running; trying to start server anyway
waiting for server to start....2026-03-05 16:02:19 CST::@:[262388]: FATAL: pre-existing shared memory block (key 4096, ID 143917076) is still in use
2026-03-05 16:02:19 CST::@:[262388]: HINT: Terminate any old server processes associated with data directory "/data".
 stopped waiting
pg_ctl: could not start server

nattach=1，实例无法启动。

实例奔溃正常起库
#

其实就是kill实例然后启动

> cat postmaster.pid 
 4096 143917077
 
> ipcs -m -i 143917077 #shmem id
Shared memory Segment shmid=143917077
uid=6001 gid=6001 cuid=6001 cgid=6001
mode=0600 access_perms=0600
bytes=56 lpid=154800 cpid=134329 nattch=18

> kill -9 134329 #postmaster或者其他的

> cat postmaster.pid 
 4096 143917077

> ipcs -m -i 143917077 #shmem id没有改变，shmem仍然存在
Shared memory Segment shmid=143917077
uid=6001 gid=6001 cuid=6001 cgid=6001
mode=0600 access_perms=0600
bytes=56 lpid=169360 cpid=134329 nattch=0 #nattch=0

> ipcs -m -i 143917077 #shmem id没有改变，shmem仍然存在

> pg_ctl start -D $PGDATA # 起库成功
pg_ctl: another server might be running; trying to start server anyway
waiting for server to start....2026-03-05 16:14:34 CST::@:[242712]: LOG: redirecting log output to logging collector process
2026-03-05 16:14:34 CST::@:[242712]: HINT: Future log output will appear in directory "/data/pg_log".
 done
server started

> ipcs -m -i 143917077 #残留的shmem起库时被清理
ipcs: id 143917077 not found
> ipcs -m -i 143917078 #shmemid起库时被+1
Shared memory Segment shmid=143917078
uid=6001 gid=6001 cuid=6001 cgid=6001
mode=0600 access_perms=0600
bytes=56 lpid=273571 cpid=242712 nattch=26

> cat postmaster.pid # shmkey不变，shmid+1
 4096 143917078

正常kill -9然后启动，可以正常启动，残留的shmem会在启动时被清理。shmkey不变是因为inode=4096且shmkey=4096没有被占用，shmid+1这是linux内核行为，至少说明不是使用的同一段shmem。

持有文件但不持有shmem
#

因为起库跟datadir inode相关，inode跟shmem id相关，起库本质上是在检查shmem是不是被其他进程持有，而不是文件fd是否还被其他进程持有。所以这里测试不持有共享内存但持有文件fd的进程logger。

$ cat /proc/77300/smaps | grep -E "\-s" #这是logger进程，检查它没有用共享内存
$ kill -stop 77300 #stop logger
$ kill -9 77076 #kill -9 pm
$ cat postmaster.pid #文件仍在
77076
/lzlcloud/pg8531/data
1772700343
8531
/tmp
0.0.0.0
 4096 143917080
ready 
$ ipcs -m -i 143917080 #共享内存仍在

Shared memory Segment shmid=143917080
uid=6001 gid=6001 cuid=6001 cgid=6001
mode=0600 access_perms=0600
bytes=56 lpid=77319 cpid=77076 nattch=0
att_time=Thu Mar 5 17:27:11 2026 
det_time=Thu Mar 5 17:27:15 2026 
change_time=Thu Mar 5 16:45:43 2026 

$ ps -ef|grep 77300 #进程仍在
postgres 77300 1 0 16:45 ? 00:00:00 postgresql: lzldb: logger 
postgres 135246 46622 0 17:27 pts/1 00:00:00 grep --color=auto 77300
$ pg_ctl start -D $PGDATA #起库成功
pg_ctl: another server might be running; trying to start server anyway
waiting for server to start....2026-03-05 17:27:55 CST::@:[140497]: LOG: redirecting log output to logging collector process
2026-03-05 17:27:55 CST::@:[140497]: HINT: Future log output will appear in directory "/data/pg_log".
 done
server started

logger持有data目录下的文件，但不关联共享内存，不会阻止起库

删除postmaster.pid文件起库失败
#

流程跟上面差不多：持有1个backend进程，kill -9 PM，删除postmaster.pid文件，起库。

过程不贴了，结果是起库失败，报错如下：

waiting for server to start....2026-03-06 15:29:48 CST::@:[22475]: FATAL: pre-existing shared memory block (key 4098, ID 171868173) is still in use
2026-03-06 15:29:48 CST::@:[22475]: HINT: Terminate any old server processes associated with data directory "/data".
2026-03-06 15:29:48 CST::@:[22475]: LOG: database system is shut down

可以看出，有僵尸进程持有shmem的情况下，即便删除包含shmid的postmaster.pid文件，PG仍然能找到对应的shmid。

关闭一个其他库，启动当前库
#

pg会分析2个地方shmid是否是当前的

以datadir.inode当作shmkey对应的shmid，或者shmkey++
postmaster.pid中的shmid

即便直接删除postmaster.pid，PG仍然可以知道shmem是不是被其他进程持有。但是我们可以通过datadir.inode和shmkey++的特性让他起库。

因为根据之前分析，我们云环境datadir inode都是4096，shmkey不同是因为源码有shmkey++的逻辑。所以我们可以：启动或停止一个datadir.inode=4096的PG库，让当前PG库启动时shmkey++多一个或者少一个，拿到不同的shmid。

$ kill -stop 165245 
$ kill -9 164411 #停当前库并持有一个当前库backend进程

$ pg_ctl stop -D /pg8531/data # 停一个其他库
waiting for server to shut down.... done
server stopped
$ pg_ctl start -D /pg8574/data # 启动当前库，会失败，因为postmaster.pid没有删除
rase_ctl: another server might be running; trying to start server anyway
waiting for server to start....2026-03-05 18:22:35 CST::@:[196209]: FATAL: pre-existing shared memory block (key 4097, ID 143917087) is still in use
2026-03-05 18:22:35 CST::@:[196209]: HINT: Terminate any old server processes associated with data directory "/pg8574/data".
 stopped waiting
rase_ctl: could not start server
Examine the log output.

$ mv /lzlcloud/pg8574/data/postmaster.pid{,.bak} # 删除当前库的postmaster.pid
$ pg_ctl start -D /lzlcloud/pg8574/data #再起当前库，成功
2026-03-05 18:23:09 CST::@:[207725]: LOG: redirecting log output to logging collector process
2026-03-05 18:23:09 CST::@:[207725]: HINT: Future log output will appear in directory "/lzlcloud/pg8574/data/pg_log".
 done
server started

$ ipcs -m -i 143917087 #shmid对应的sysv共享内存仍然被我们持有

Shared memory Segment shmid=143917087
uid=6001 gid=6001 cuid=6001 cgid=6001
mode=0600 access_perms=0600
bytes=56 lpid=196209 cpid=164411 nattch=1
att_time=Thu Mar 5 18:22:35 2026 
det_time=Thu Mar 5 18:22:35 2026 
change_time=Thu Mar 5 18:21:04 2026 

可以启动，当前库共享内存申请了另一块，之前那个共享内存没有被清理。这就是在云环境下关其他库启动当前库的骚操作。

这里有个小小的前提，关的其他库不仅要inode=当前库inode，还要其他库shmkey<当前库shmkey。

报错分析：`lock file "postmaster.pid" already exists`
#

这个问题比“共享内存已存在”简单多了。

起库时本身就会检查lock file、lock file中的pid，CreateLockFile():

		if (other_pid != my_pid && other_pid != my_p_pid &&
			other_pid != my_gp_pid)
		{
			if (kill(other_pid, 0) == 0 ||
				(errno != ESRCH && errno != EPERM))
			{
				/* lockfile belongs to a live process */
				ereport(FATAL,
						(errcode(ERRCODE_LOCK_FILE_EXISTS),
						 errmsg("lock file \"%s\" already exists",
								filename),
						 isDDLock ?
						 (encoded_pid < 0 ?
						 errhint("Is another postgres (PID %d) running in data directory \"%s\"?",
								 (int) other_pid, refName) :
						 errhint("Is another postmaster (PID %d) running in data directory \"%s\"?",
								 (int) other_pid, refName)) :
						 (encoded_pid < 0 ?
						 errhint("Is another postgres (PID %d) using socket file \"%s\"?",
								 (int) other_pid, refName) :
						 errhint("Is another postmaster (PID %d) using socket file \"%s\"?",
								 (int) other_pid, refName))));
			}
		}

测试就更简单，在库启动的时候再启动一次：

$ pg_ctl start -D /pg8531/data
pg_ctl: another server might be running; trying to start server anyway
waiting for server to start....2026-03-06 15:59:05 CST::@:[89145]: FATAL: lock file "postmaster.pid" already exists
2026-03-06 15:59:05 CST::@:[89145]: HINT: Is another postmaster (PID 255500) running in data directory "/pg8531/data"?
 stopped waiting
pg_ctl: could not start server
Examine the log output.

所以故障时的start.log后面几个报错是因为库已经启动了，多启动了几次。

总结
#

PG在起库时，会先开辟一个sysv shmem（不是mmap对应的share buffers）以锁定datadir。锁定是通过datadir的inode号当作shmkey通过shmget申请的，并返回shmem唯一标识符shmid。由于可能申请的shmem被其他进程使用，PG会让shmkey++无限循环指到申请到没有被人占用的shmem。postmaster.pid第七行分别保存shmkey和shmid。在云环境下通常可以看到共享PG实例的shmkey递增的现象，这是因为data盘挂载方式相同使用了相同的inode，shmkey++导致。

如果PG实例被意外干掉，shmem不会被清理，正常情况下没有僵尸进程持有共享内存，那么起库会清理这段shmem并正常起库；异常情况下僵尸进程持有共享内存，起库会失败，此时需要介入处理。

推荐的处理方式：

ipcrm -m（最推荐）
lsof找到僵尸进程并kill
重启主机

不推荐但可以起库的方式：

mv postmaster.pid+关闭一个其他PG库（其他PG库的shmkey<当前PG库）
mv postmaster.pid+重新挂载data盘并改变inode

最后回答开头的问题：

为什么这种场景在现实种不算太多见？

实例异常宕机+仍然有僵尸进程没有被清理。有些情况是异常宕机没有僵尸进程，正常起库就行了。

start.log起库报错有2类，分别对应什么操作和逻辑？

共享内存被占用的报错是因为实例异常宕机+仍然有僵尸进程；postmaster.pid存在的报错是因为起库多次

如果PM都不在了共享内存还可以存在吗？

PM都不在了共享内存可以存在，PG的进程不一定会自己跑挂或者被OS处理；但是所有进程都不在了共享内存应该不存在

这段共享内存如何定位和清理？

起库的start.log可以找到shmid，ipcrm -m $shmid命令可以清理。

PG共享内存有多段，这段共享内存是哪一段？

sysv shmem，用于保护datadir，一定存在，参考“三种共享内存”部分。与mmap下的sharebuffers是2个东西。

可以通过inode或者文件找到对应的shmem吗？

LINUX在用户态没有提供通过inode或者文件找到对应shmem的接口（这句话AI含量100%，经过多个模型交叉验证）。PG是通过datadir的inode当作种子shmkey去申请的shmem共享内存，本质上不是通过inode直接找到对应的shmem，PG对shmem共享内存使用自己的寻找机制，但不绝对对应，shkey++就是一个折衷起库逻辑。

AI时代下的DBA、写作、学习和未来

Wed, 21 Jan 2026 00:00:00 +0000

AI率：本篇文章AI率约60%，与AI battle回合约20次

推荐理由：有一些对AI ops的思考和洞察，所以推荐

AI时代的写作
#

AI对写博客、写公众号的作者来说，可能是一个致命的打击，因为AI写作实在是太简单。因为我自己就写文章，我自己对AI影响写作习惯也有很多纠结的地方，我也很难受。这里再把以前的对写作的思考拿出来：

为什么写作？

为自己，巩固知识。输出才可以加强输入，看一眼和写一遍是完全不一样的，写作的时间可能是看一遍时间的好几倍。就比如，看到一句有道理而且自己很懂的话，自己在写一遍时，你会发现这句话里面有非常多的细节。
为自己，合理利用他人偏见。主要是为了利用他人偏见让自己坚持写作以及提升内容的可信度，自己看的知识可能差不多就得了，写给公众看就要字斟句酌对他人负责。（相对的，不是真·字斟句酌）
为自己，提升知名度。这就很依赖写作水平了。
为他人/社区，传播知识。好东西要拿出来大家一起看和使用，这是Postgres开源社区的内核所在。鼓励分享，不鼓励藏着掖着，这也是我一直秉持的理念。
结交圈子。我不是为了这个来，但确实认识了一些小伙伴

人力写作已经很难了，在AI时代人力写作约等于地狱模式，就像没有目标地逆行，看不到光在哪，而人们都在往反方向走。我自己当然体验过AI解读、翻译、写成文章，但总感觉那不是我的，或者失去了训练我自己的初心，或者更深层次一点，我想感受到作品的生命力。

整个DBA圈子的文章可以用鱼龙混杂来形容，写啥的都有。而我自己一直都喜欢内容性文章，偏PG原理和运维的，比如灿灿和向博的文章，我都是翘首以盼每次必细品。一般内容性文章都不会有特别多的流量（灿灿和向博都各自在公众号吐槽过··），我自己也很随缘。

但是，我上一篇文章《pg运维数据库运维经验2025》涨了很多粉，实属让我惊讶。所以我这几天一直在思考这个问题：为什么一个人（非AI）写的、非完备的、DBA的、知识性的文章，会有这么多人感兴趣？AI对DBA意味着什么？

对运维的思考
#

运维的本质和AI Ops
#

运维要做很多事情，为了减少讨论的范围，我在运维工作中极少一部分–故障响应，来解读DB Ops的本质。首先我的观点：“运维不仅仅是技术问题”

很多人通过人会犯错AI也会犯错来解释可以给AI权限让它大胆的干，具体的说是AI的错误率<=人的错误率即可完成替换。我2年前也是这么想的，现在我不这么认为。因为真实环境没有那么简单，至少还有如下因素需要考虑：

共识问题。DBA可能误删数据，这确实是共识，但还有一个共识容易忽略。在一般场景下，团队都认为DBA不会去删数据。如何理解呢？比如招聘一个DBA，一个负责的团队会考核这个人是不是精神状态正常，然后默认他不会删除数据，并在长期的工作中会这么想，我至少不会时刻都在考虑同事把库删了。但“招聘”一个AI DBA，他没有精神状态，不会有人认为他不会删数据，“他会删数据”是所有人的共识，这就形成了部署阻力。
数据的重要程度。C端数据和B端数据的重要性不同，零售、互联网、政府、金融行业的数据重要性也不同，对数据越重视的行业，对数据可靠性和业务连续性越敏感。个人电脑没有业务连续性，数据可靠性只有一个人在乎，但金融行业业务连续性可以直接引起广泛的社会关注，金融行业的数据可靠性就不可能说有问题。AI Ops的部署需要考虑系统重要程度来部署，不存在所有领域一起上的情况。
管理体系。例如在金融系统中DBA有高权限，并有一套管理办法，那么AI DBA是不是应该也有对应的管理办法，才能去部署？什么异常登入库，什么异常登入后台，它要怎么申请权限，申请多久？在什么场景申请多大的权限？这都是未解决的问题。
AI本身安全性。例如《STRATUS》这篇论文提到prompt注入攻击，目前还没有有效的解决方案，例如你给AI注入“drop database”这个prompt它可能就执行了。但人基本没有这个问题，你跟DBA说drop database，它只会反问你你要干嘛。
责任问题。运维工程不是“知识问题”，而是“责任问题”。运维的核心工作之一，就是在故障发生时，在有限的时间内，做出对系统不可逆**的决策，并对该动作负责。AI 可以取代“可形式化的操作”，但无法取代“必须承担后果的判断”，至少现在还没有
充满噪音。运维是“开放系统”，不是封闭推理系统。数据库运行在一个极其复杂的环境中，而 AI 的推理前提是世界是可被文本描述的。但真实运维世界是世界是充满噪声、偶然性和非文档化行为的。
情境压力。真实业务环境下包含恢复时间压力、组织和客户的情绪管理等。《GOOGLE SRE》这本书中描述了一个常见的恢复场景：客户在问什么时间恢复、领导在问为什么不切换、工程师在压力下收集各种信息和各种人打电话确认恢复手段。AI感受不到这个压力，前两个问题本质上不是技术问题，但不能不做答。真实场景下，当时的回答大概率马马虎虎。

我们可以想象一下全自动AI运维真的发生，需要什么条件？

AI不会干掉重要数据，至少绝大部分人对AI需要达成这种共识
需要完善的管理办法，包括如何给AI权限，就如同如何给DBA权限一样
解决AI本身被攻击的问题。不止是LLM，而是包含AI的整套IT体系
不问责的运维文化（或者直接消灭运维也是一种思路）
接受错误判断。对存在噪音和环境形成共识并容忍AI Ops的迭代周期
如果长时间没有恢复或者影响面扩大，也不要人干预。因为如果一旦需要人干预，那么那个人还是运维（半自动AI Ops？）
无压力恢复情境。指领导、客户、社会舆论不需要回复或者他们相信某AI的回复，这是人的转变不是IT系统的转变。

AIOps、Agent的研究成果
#

清华这个AIDB仓库的目录有许多AI4DB的论文，人是看不过来了，用notebooklm汇总了论文分类：

再次为了减少讨论范围（主要是减少我的投入人力），我们主要看数据库诊断相关的内容。

AIOps在学术上有不错的进展。AIOps研究通过将机器学习、强化学习及大语言模型集成于数据库管理，涵盖参数调优、索引建议、查询优化与故障诊断等关键任务，旨在构建具备自感知与自修复能力的“自动驾驶”数据库系统，在显著提升复杂工作负载性能与运维效率的同时，推动DBA从低效的手动干预转型为高层级的架构监管者。

关于“DBA（数据库管理员）是否会被淘汰”的问题，目前的科研趋势和工业实践（尤其是自动驾驶数据库和大语言模型的应用）显示，DBA的角色正在经历一场从“手动操作者”向“高级管理者/监督者”的深刻转型，而非简单的被取代。DBA核心价值将转向管理AI运维策略、确保数据安全合规、以及处理AI无法解决的极端异常场景。

另一篇AI Ops前言综述的文章对Agent这样描述：

“这说明AI Agent并非银弹，要应用Agent不只需要模型和agent层面的进步，还需要需要整个被运维系统具备足够的支持能力比如类似Kubernetes的声明式接口、良好的可观测性、可逆的操作设计。Stratus的初步实验证明了Agent在自动运维上的潜力，但距离生产部署在性能、可靠性和安全性上仍有巨大的问题。”

开发领域因为如火如荼的vibe coding，要明显比AI在运维领域的应用快很多。我也很想有个confirm、redo的运维遥控器，问题是现在确实没有。即使我们现在幻想有一天有vibe maintaining，应该也没有几个运维会打开yolo模式。

DBA的价值
#

DBA的价值是拍板背锅侠吗
#

背书好像确实不能通过AI解决。那么DBA的价值就是拍板背锅侠吗？毕竟dba的知识远低于AI，只是AI不能拍板罢了。

瞬时上下文

“DBA 的知识远低于 AI”，这在通用知识（比如如何优化一个 SQL，或者某个配置参数的含义）上确实是事实。但 AI 缺少瞬时上下文（Runtime Context）。 AI 知道数据库原理，但它不知道你公司双十一流量激增的瞬间，那个负载均衡器后面藏着的陈年历史债。DBA 拥有的是关于“这台特定机器、这个特定业务、这些特定人”的非结构化经验。在极端故障面前，AI 给出的是“概率最高的建议”，而 DBA 给出的是“在这个特定压力下，最能保住命的那个操作”。

“混沌系统”的最后闸门

数据库是所有 IT 架构中最脆弱、最不容错的部分（代码坏了可以回滚，数据丢了公司可能就倒闭了）。AI 的逻辑是基于历史数据的推演。当出现从未见过的底层硬件坏道、极其罕见的分布式死锁，或者黑客的新型攻击手段时，AI 的“建议”往往会失效甚至造成二次伤害。“拍板”的核心不是“选哪个方案”，而是**“承担风险的对冲”。这种对极端情况的掌控力**，是目前的AI无法提供的。

信任链

DBA是信任链的维护者：例如让 AI 审计 AI，那么谁来审计 AI 的审计逻辑？在数据安全、合规和伦理层面，必须有一个拥有最高权限且可追责的人类作为信任链的终点。

我们反过来想，如果 DBA 真的只是“知识较少的拍板背锅侠”，那么企业其实早就会把 DBA 的拍板权交给SRE或者架构委员会、甚至AI等等责任主体。但现实是在真正关键的时刻，企业仍然会把电话打给“那个人”。这说明问题从来不是“谁更聪明”，而是谁能在不确定性中，为组织承担后果。DBA 是数据库这个混沌系统中，最后一个拥有止损权、责任权和信任终结权的人类。

那么拍板都是DBA说了算吗？显然不是。DBA 并不拥有“目标决策权”，而是拥有“风险否决权”——他们不能决定业务要不要冒险，但可以决定系统不能承受哪些冒险。在简单、低风险、可回滚的场景下，拍板往往由流程或系统自动完成；只有当决策进入高风险、不可逆、责任必须收敛的区间时，DBA 才会被推到台前。

Postgres DBA的特殊性
#

针对 Postgres (PG) DBA 这个特定群体，其特殊性会更加显著。

在现代技术组织中，DBA 并不天然拥有架构决策权，也不垄断索引或参数的制定。架构师可以设计方案，开发可以编写 SQL，AI 甚至可以给出看似完备的最佳实践建议。但这些决策大多发生在抽象层、设计层和概率层，它们假设系统是可回滚、可重放、可修正的。

Postgres 的特殊性在于，它将大量自由度交给使用者，而这些自由度最终都会转化为真实系统中的长期副作用：写放大、IO 模式变化、Vacuum 失衡、WAL 膨胀以及难以预测的性能退化。这些副作用无法在设计阶段完全预演，也无法被单一角色分包处理，更无法在事故发生后简单“撤回”。当系统进入不可暂停、不可重放的状态时，唯一仍需对整体结果负责的人，往往就是 DBA。

因此，Postgres DBA 的价值不在于“替别人做决定”（当然也可以啦），而在于在所有决定已经发生之后，持续管理它们在现实世界中的后果。“架构师定义理想，开发实现功能，AI 预测未来；而 DBA 守护真实。”

这个守护真实的能力是基于PG DBA拥有足够了解Postgres、足够了解系统真实环境、足够了解系统的历史和足够的即时上下文。在AI的时代，还需要再增加一个，足够了解AI。

为什么还要学习
#

这两年听到读书无用论比以往多了许多，说这种话我一般都嗤之以鼻。借此机会好好盘一盘。

数据库基础知识还有没有价值？答案是：价值更高了。我们从解释权、主动学习和为什么我还在反复看经典来解读。

1.问题的解释权

基础知识让你做到三件事：

提前识别“系统性必炸点”
把判断逻辑讲清楚
把“我拍脑袋”变成“这是系统决定的结果”

学数据库基础知识的真正意义，不是为了“多干活”，而是为了：

划清责任边界
提升话语权
让系统为你的判断背书

2.主动学习成为更稀缺的能力

在 AI 时代，知识获取的“技术壁垒”趋近于 0。主动学习能力是稀缺的。为什么“主动学习”在 AI 时代反而更稀缺？这点很反直觉，但非常现实。AI 让“被动学习”极其舒服，随问随答、无需长期投入、不必承受认知不适。但是导致的结果是，越来越多的人停留在“即时满足层”，不愿意再去学习基础知识。当所有人都在倒退时，你发现你走的更快了。

3.为什么还在反复看《The Internals of PostgreSQL》这种经典？

技术人员需要看书，是因为书不是在给答案，而是在帮我建立一个可以反复运行、不断修正的认知模型；而 AI 目前更擅长回答问题，而不是塑造这种模型。AI 很难成为这种“长期对话对象”，它的回答是不稳定的。

另一个方面，从认知经济学 + 信息论 + token 成本的视角来看书的价值。首先，你不用跟 AI battle 来 battle 去，battle 的真正成本不是钱，而是你的注意力和上下文维护能力。其次，书中的几十万字不仅不需要你输入大量的prompt，也不需要你付出过多的tokens。再次，这个书籍的知识经过了作者和读者的反复验证，是已压缩过的知识，是最容易学习的。所以，经典书籍 = 极低 token 成本下，获得高密度、被人类反复验证过的专注知识的压缩结果。

4.学习AI本身

这不需要我说了。

跟AI的battle，让我得出一个有趣的关于“为什么还要看书”的结论：

在 AI 时代，知识是廉价的，判断力才是昂贵的 => 而判断力，来自于稳定、可校准的认知模型 => 稳定的认知模型，本身是“长期高质量知识摄入”的副产品。

另一个可以佐证读书有用论的一个现实证据是，我现在这篇文章依赖于我读过的一些书、论文、其他文章和资讯，如果没有这些，这篇文章不会与各位见面。

为什么大家还爱看"人"写的文章
#

偏爱漏洞的心理
#

人类写的技术文章，难免漏洞百出，我自己看我去年写的运维经验2024，就可以找到很多漏洞。即便是前几天刚完成的运维经验2025，我也认为这篇文章是不完备的，跟AI写的东西差别很大。但是为什么读者还是喜欢这种漏洞百出的技术文章呢？

原因可能是人类不是被“信息正确性”吸引，而是被“可共情的不完美心智痕迹”吸引。从《智力简史》这边书中可知，人类的智力模型本身就包含自我试错式的探险和观察别人的行为并映射自我这两种模型，这是一种学习过程，是人类与生俱来的。我们的大脑默认会扫描文本中的的犹豫、不确定、逻辑断裂、表达不顺、情绪泄漏等等，这些在 AI 文本中被系统性地忽略。在文字的漏洞和情绪中，读者可以感受到作者的思考和情绪，而AI只是给出了结果，读者几乎不会与AI有情绪共鸣。一般来说，只有真实经历过的人，才会留下这种“不好看”的痕迹。

所以我相信很多人跟我一样，一眼纯AI的技术文章（不保证100%判断正确），一般不会有情绪读下去。但如果是人类认真写的，会认真读下去，去感受作者的感受，去抓他的不足或场景缺陷。

当然，作者也可以喂一些提示词模仿之前文章的口吻或者故意留漏洞，不过我没有认真这么做过，简单试过生成了几篇，感觉情绪带入还是比较差。后面也不想再继续深入尝试了，再试下去意义也不大。

白嫖大神的ATTENTION
#

AI文章和大神文章的核心差异不是“写得好不好”，而是经济性问答、行业领先的Attention的问题。大神写作是在替读者分配注意力，AI 写作是在避免遗漏任何可能相关的信息。这不是能力问题，而是目标函数不同。真正高价值的技术文章，不是告诉你所有正确答案，而是替你挡住 80% 你现在不该关注的东西。

大神为什么敢“删”，AI 为什么不敢？因为他们为你的理解结果承担认知责任，AI不承担你学错、用错的后果。于是大神会刻意过滤那些目前不需要注意的细节。这种过滤，本身就是专家价值。对人类来说，学习的瓶颈不是信息不够，而是注意力有限、不知道先看哪里。大神的文章直接把结果给你对你说，你就看着这个。但你面对LLM的时候，你知道该找什么东西吗？

这并不是在否定 AI 文章的价值。AI 擅长的是“在你已经知道问题边界时，快速铺开信息空间”，而大神文章擅长的是“在你尚未建立判断框架时，替你先收缩问题空间”。前者适合查漏补缺、横向扩展，后者适合建立主干认知和关键直觉。真正高效的学习方式，并不是二选一，而是先借助大神完成 Attention 对齐，再利用 AI 在被限定的空间内做放大搜索。

这不是在说AI的东西没有用，或者人类写的东西没用，而是各自有用。

AGI能解决所有问题吗？
#

驳Musk
#

最近Musk又在画大饼，看完以后我并不赞同。

共同富裕还是无用阶级？

无用阶级是尤瓦尔在《未来简史》中的观点，他认为当AI的生产力超过普通人的时候，用AI干活会替代让普通人干活。这些人就成为了无用阶级。资源会愈发集中在少数精英和大公司手中，大部分人会失业，但是失业情况目前没有有效政策可以为之兜底。这个观点刚好与马斯克式的共同富裕有出入，马斯克认为当AGI实现时，所有人都不需要担心生存、教育、医疗，生产力高到政府会给大部分人兜底。我目前支持尤瓦尔的观点。其实从身边感知性统计也可以看出来，无用阶级的人数正在上升。

高生产力可以制造乌托邦吗？

一个支持我不同意AGI乌托邦的理论来自于另一本书《进化心理学-择偶标准》。其中有一个观点令我印象深刻：出于社会分工和生物培育良好后代的考虑，男性偏爱年轻、健康的女性，女性偏爱健康、有资源的男性。这个刻在我们基因里的默认筛选，导致了人是不会平等生活的，你不想成为被淘汰的那个。所以一个不攀比、没有竞争的、资源平等的乌托邦如果能够维持下去，生产力只是必要条件之一，还有许多必须解决的社会问题容易被大众忽略。这里不是狭义的单指进化心理学，有些东西没有被仔细讨论，比如《黑猩猩政治》中的权力纷争，其实也应该被考虑。

卡尔霍恩的老鼠乌托邦实验

1972 年，动物行为学家约翰·B·卡尔霍恩John B. Calhoun）设计并详细描述了一个著名的实验环境——“宇宙 25 号”。这是一个专门为老鼠打造的实验室“乌托邦”，几乎在每一个方面都力求完美：食物、水源和筑巢材料充足；居住环境定期清洁；没有捕食者威胁；温度通过风扇与供暖保持在 20℃至 31℃之间，稳定舒适。

老鼠数量走向灭亡看起来有些疯癫，我选择只看过程部分：1)暴力增加 2)不再追求异性 3)同性行为增加 4)独处行为增加 5)男性爱打扮自己 6) 冷漠等等。当然这个实验会有一些缺陷，从《智力简史》中描述的智力模型来看，老鼠和人的智力模型还差着一个灵长类动物，它不能代表人类社会。但是至少可以看出，乌托邦会引起新的社会问题，人们不会老老实实的过日子。

基于经济学的社会

从现代经济学的角度来看，AGI 是否能够实现“共同富裕式乌托邦”，可分为两种类型来看：保留现代经济和不保留现代经济。

如果保留现代经济，AGI 可以被视为一种极端高效的“通用生产要素”。它显著降低了知识生产、决策支持、组织协调和边际劳动成本，提高了全社会的生产率上限。在这一前提下，财富分配、公共服务供给和社会保障机制，仍然依托市场、价格信号、激励机制和制度约束运行。AGI 的作用更多体现在扩大“可分配蛋糕”的规模，而非自动解决分配问题。换言之**，**共同富裕依然是政治经济学问题，而不是技术问题，AGI 只能降低实现目标的成本，却无法替代制度设计。

那么，如果不保留现代经济，而是试图绕过市场、价格与激励体系，直接依靠 AGI 实现某种“技术乌托邦”，是否可行？

答案几乎可以确定是否定的。

没有现代经济的乌托邦，在 20 世纪 60–70 年代已经被反复验证为失败。其根本原因并不在于当时“技术不够先进”，而在于信息与激励问题的结构性不可解： 即便拥有强大的集中式计算能力，也无法替代分散个体通过价格机制传递的偏好信息，更无法在长期内维持创新动力、责任约束和资源配置效率。AGI 可以提高集中决策的计算能力，但无法消除“谁为决策负责、谁承担后果、谁拥有选择权”这一经济学基本问题。

因此，AGI 并不是现代经济的替代者，而是现代经济框架下的放大器。任何脱离市场机制、激励结构和制度约束的“技术乌托邦”，无论是否引入 AGI，本质上都会重演历史上的失败路径，只是失败形式更加隐蔽、成本更高。

生产力（包括 AGI 带来的智力提升）只是乌托邦所需条件之一，而且远远不是最关键的那一个。乌托邦不是算力问题，也不是智力问题，而是人类行为在制度约束下的稳定性问题。

AI解决不了所有问题的数学基础
#

以下抄自吴军的《数学之美》：

“1900年，希尔伯特提出了许多问题，其中一个是：‘任意一个（多项式）不定方程，能否通过有限步的运算，判定它是否存在整数解’。如果对希尔伯特这个问题普遍答案是否定的，那么就说明很多数学问题其实上帝也不知道答案是否存在，因为不定方程求解问题还只是数学问题中很小的一部分。对于连答案存在与否都无法判定的问题，答案自然找不到的。正是希尔伯特对数学问题边界的思考，让图灵明白了计算的极限所在····马蒂亚塞维奇严格地证明了，除了极少数特例，在一般情况下，无法通过有限步的运算，判定一个不定方程是否存在整数解。这个问题的解决，对人类认知上的冲击，远比它在数学上的影响还要大···如果连解都不知道，就更不可能通过计算来解决他们了”

“理性状态的图灵机可以解决的问题，只是有答案的问题中的一部分··很多工程上的问题并非人工智能问题···今天，我们所要担心的不是人工智能或计算机有多么强大，更不应该觉得他们无所不能，因为他们的边界已经清清楚楚地由数学的边界划定了···世界上还有许多需要由人来解决的问题，如何利用好人工智能工具，更有效地解决属于人的问题，才是应该给予更多关注的。“

（看吧，读书有用吧，直接给你讲明白，你大概率问不出来也拿不到这么通俗易懂的答案；看吧，关注硬核技术up有用吧，我帮你筛选了，快“点关注”⭐）

总结
#

作为一个写技术文章的博主，写此类社会问题是比较少的。本来就想简单写写上一篇文章为什么有流量，结果为了解释这个现象有点把问题扩大化了😓。

本篇的局限性：

只讨论了DBA工作的很小一部分–故障恢复，没有讨论其他工作的智能化问题。
GPT太了解我了，看上去在PUA我。它确实说的很有道理，但我无法给它说的东西背书。这就有点套娃了，AI帮我确认AI不能背书，这个输出本来就无法背书。从我自己的视角来看，它的思路确实不错，金句频出。

有些Ops场景当然是容易AI化的，但通过这篇文章的讨论，在故障恢复这个领域搞AI化，难度还是有的。我从来没有放弃用AI，也从来没有放弃用人脑，我只是喜欢识别AI在什么场景下好用，什么场景下不好用，什么场景下用不了。这让文章的基调看起来对AI的未来很悲观，其实我的想法不是悲观。

这篇文章的开头你可以看到 AI率是50%，实际上我还跟几个小伙伴讨论过类似问题，也包含自己的思考，所以这篇文章真正的智力比例是：

AI率50%，其他人脑率10%，我的人脑率40%

所以这篇文章也算是”不放弃使用AI，也不放弃使用人脑“的一个典型案例了。

最后用几个问题简单表面我的观点：

为什么人们还是爱看人写的文章？心理偏好和注意力对齐

读书有没有用（不只是书）？有用，而且比以往还有用（烂书比以往更没用，知识品味比以往更重要）

AIOps会不会实现？会，但还要时间，而且并不容易。这需要学术突破和运维（含DBA）的思考和实践

DBA会不会被替代？不会，跟软件开发者一样，会经历工作模式的改变，但不会消失

留下来的DBA是哪些人？“懂DB又懂AI，不依赖AI，又不放弃判断的人”

AGI会不会实现？会

AGI会不会实现全面富裕？不会

如果想跟我讨论AI Ops或者文章中的问题，可以在各个PG群里找我，应该好找，或者给我留言也可以。

ref
#

https://github.com/TsinghuaDatabaseGroup/AIDB

https://mp.weixin.qq.com/s/urqh4NZDmkXvDllBCCdZDA

Zhao, Y., et al. (2025). “STRATUS: A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds”.Advances in Neural Information Processing Systems (NeurIPS)

https://zhuanlan.zhihu.com/p/631632685

《数学之美》

pg数据库运维经验2025

Sun, 11 Jan 2026 00:00:00 +0000

主要是技术性运维总结，主打通俗易懂和快速上手，同时也是对PG数据库运维的阶段性总结，希望对PGer有所帮助。

历史的运维经验：pg数据库运维经验2024。注意，本篇不会包含历史的运维经验的内容。

CPU
#

SQL性能问题是PG异常处理根因中最多的，这包含SQL本身性能不好，索引一般、突发并发高、执行计划突变。对于postgres这种没有完善的绑定执行计划的方案的库来说，有一个DBA团队帮助设计数据模型、数据访问方式、索引、调整执行计划等显得尤为重要，实际上可以极大缓解CPU突然打满的问题。

执行计划
#

执行计划突变是cost-base优化器的老毛病，postgres也不会例外。

DISTINCT不准确
#

案例-从distinct不准确到DISTINCT的计算原理

由于默认采样数最大是3w行，也就是说这种采样算法只要超过3w，即表比较大的时候，预估distinct很可能偏小。注意这里的数据不能有太多唯一值。

测试一张表不同采样数的差异：

表有reltuples=8亿，relpages=2kw，size=175GB，真实的某字段distinct 1亿

target statistics	pages采样比例（1）	tuples采样比例（1）	n_distinct	执行时间
50	0.00075	0.00001875	6w	2秒
100	0.0015	0.0000375	11w	5秒
1000	0.015	0.000375	103w	58秒
3000	0.045	0.001125	268w	3分01秒
10000	0.15	0.00375	675w	7分21秒

（target statistics 最大值10000）

可以粗糙的总结：n_distinct和analyze的执行时间随采样数量成倍增长。

n_distinct随采样数量增长，pages和tuples却一直都很准确。

generic plan的干扰
#

pg的执行计划要考虑generic plan。generic plan与传参是无关的，它用一些默认值计算cost，并与前五次计划的代价进行对比，谁小用谁。

案例-添加索引性能下降和generic plan

一、generic plan预估不准的问题分类

因为有5次机制对比，所以generic plan的问题可以分为2种：

前5次SQL的执行没有普遍性。跟前5次执行计划相关性大，依赖数据倾斜和前5次参数是否具有普遍性。
generic plan本身有问题。generic plan因为数据倾斜或数据均衡但无法准确计算选择率，导致generic plan本身执行效率低下

二、解决方案参考

generic plan问题在分区表上可能会出现，分区键是连续的，扫描所有分区建选择率应该为1，但generic plan为0.05，很可能导致走“全索引”扫描这种场景。

所以在优化的时候需要考虑更多：

不要建太多索引迷惑优化器
排除generic plan的干扰。用EXECUTE真实跑6次
会话级别set plan_cache_mode='force_generic_plan'; or set plan_cache_mode='force_custom_plan';对比执行计划；或者在pg16+用explain (GENERIC_PLAN)对比执行计划

语法参考：

--prepare/excute
PREPARE sql1(text) AS
SELECT COUNT(*) FROM LZL where a=$1;

EXECUTE sql1('zzz'); --跑6次再说
EXPLAIN EXECUTE sql1('zzz');

select * from pg_prepared_statements --查看prepare语句信息，只能看当前会话

--对比执行计划，设置会话参数后执行EXPLAIN EXECUTE
set plan_cache_mode='force_generic_plan'
set plan_cache_mode='force_custom_plan'
--直接查看genetic plan,16+
explain (GENERIC_PLAN) xx 

行锁导致的LWLock:Lockmanager
#

LWLock Lockmanager问题一般发生在分区表上，高并发没有分区键的SQL容易发生。而今年又发现一个新的场景：行锁导致的LWLock:Lockmanager

这不算一个很大的问题，因为更新同一行会阻塞是众所周知的。只是没有测试前我也没有想到更新同一行也会产生LWLock:Lockmanager。不算特别有价值的案例，在观察等待事件有LWLock:Lockmanager时考虑行锁即可。

idle连接数
#

PostgreSQL的性能基本随着大版本提升而稳定提升。其中PG14对快照的获取和维护所有backend的事务信息都做了大幅优化，使得14对多idle connection的提升明显：

（https://techcommunity.microsoft.com/blog/adforpostgresql/improving-postgres-connection-scalability-snapshots/1806462）

但，这不代表14以后就不需要关注idle连接数了，它仍然会消耗backend事务维护成本、上下文切换、使内存碎片化等问题，导致数据库的idle连接数越多性能越差。

一般业务连接本身是有轮询和保活的，保持一定的idle是为了不让每个请求都新建连接，那样消耗就大了去了。一般小库是不太需要关注连接数（只要别太离谱），因为CPU买的不多，系统也没那么重要，而且扩容比较容易。但是大库又不一样了。CPU数就是主机资源上限，再加也加不上去了。大库本身idle connection就很多，再增加空闲连接不一定会增加系统的吞吐量，特别是CPU已经不太够时，增加idle连接会起反向效果。

以PG15压测经验来看，以5k idle为基线，上1w个idle时，idle的维护会多使用2-5个vCPU，上2w个idle时，多使用5-10个vCPU。大致情况是这样。

idle in transaction
#

去年狠狠把长事务批判了一遍，因为长事务对PG的影响要比其他库（oracle、mysql等）要大。但这问题不大，做好告警和运维，长事务问题是可解决的。

在监控会话状态时，一般都要查看会话状态，比如active代表正在运行，代表在跑SQL，idle in transaction代表事务在空闲状态，代表事务没有在跑SQL也没有提交。所有的pg_stat_activity.state如下，pg15：

Current overall state of this backend. Possible values are:

active: The backend is executing a query.
idle: The backend is waiting for a new client command.
idle in transaction: The backend is in a transaction, but is not currently executing a query.
idle in transaction (aborted): This state is similar to idle in transaction, except one of the statements in the transaction caused an error.
fastpath function call: The backend is executing a fast-path function.
disabled: This state is reported if track_activities is disabled in this backend.

常见的state只有active,idle,idle in transaction,idle in transaction (aborted)。idle in transaction有一个误区是，它只代表当前时间没有运行sql，没有提交事务，不代表这个事务空闲了很久。不能通过事务xact_start +idle in transaction判断事务多久没跑，而应该通过state_change +idle in transaction来判断。

内存
#

内存问题非常棘手，而且今年处理了非常多，也找到了一些很好的解决方案。不过内存体系知识还是比较大，只能尽我所能尽量简化这部分知识，直达现象、结果和解决方案。

内存问题和大页
#

pg内存问题分类：

pg内存问题相关wchan：

大页对内存碎片、CG内直接内存回收都非常好的效果。

大页实际效果看压测：https://docs.paic.com.cn/#/post/84479375

大页八股文理论效果：

减少TLB的压力
减少pagetable在主内存上的大小
大页在物理上是连续的。连续的物理内存访问比不连续的物理内存访问更优
当使用大页时，page是直接映射的，不会使用多级的pte条目

不过使用大页会带来管理上的挑战：

需要提前分配大页
需要提前计算大页大小，以避免内存浪费

内存知识比较多，其他的参考Linux内存进阶。总之要记住如下几点：

优先排除os层问题再解决pg实例层问题
大页有神奇的效果，但极少数情况仍没有效果
很多小伙伴不会关注pgpgin/pgpgout/pgfree，甚至不会关心pgscank/pgscand，只会看cpu、内存用了多少。这对运维pg库来说是不够的。
没有良好的运维体系pg的内存会很不稳定

值得注意的cgroup知识
#

cgroup的知识也不少，参考之前的文章吧，这里做个简单总结。

cgroup v1有自身的缺陷：

没有统计cg pagetable
没有统计cg slab
没有统计cg hugepage（hugepage是没有charge，还不是没有算进去）
没有统计cg异步、同步回收pages
cg rss与process rss统计口径不统一
shmem统计口径比较乱

未解之谜
#

大页确实解决了很多问题，但不能解决所有内存问题。不能解决的这部分问题待研究，希望26年可以弄明白。

关注OS
#

关注OS的一切
#

学习开源库需要了解操作系统

（这句话已忘记出处）

想要运维好Postgres，了解OS的原理是十分重要的。Postres数据库就是构建在OS（特别是linux）之上，linux提供什么它用什么，postgres是linux的生态。所以想要深入理解运行原理，得先了解操作系统原理。

优先排除os层问题再解决pg实例层问题

（这句话是我说的）

一、CPU

因为postgres还用不了NUMA，无论是主机资源全给，还是CGROUP（or pod）管理cpu，都不太需要深入到操作系统层CPU原理。CPU问题看看SQL或者PG的堆栈基本够了。

二、内存

内存参考内存章节。内存问题是需要深入到OS层的。

三、进程

从操作系统查看PG进程的状态非常重要，包括但不限于要查看D、wchan、RSS、SYSCALL

四、主机状态和日志

监控主机状态、包括主机层CPU、内存、IO、网络、日志。非常重要。

难以想象“an I/O error occured while sending to the backend”这种网络IO的模糊告警跟底层存储是相关的。除了查看/var/log/message，pg层看不出来有什么。当然这个报错有可能不是这个原因，请勿曲解。

五、其他

未归类

物理读
#

postgres本身不直接暴露“真正的物理磁盘读”（Physical Disk Read）指标。pg_stat中的各种reads（比如pg_stat_database.blks_read ）都是从os cache中读。

那怎么监控物理读？

reads或者buffer allocation指标都是辅助策略，最好的办法还是监控OS。

os是postgres的生态，绝对不要单看数据库。数据库层监控不到物理读不值得PGer shame，有方案就没问题。

监控iostat以及各种五花八门的磁盘监控指标。对于云环境来说，os层的监控体系已经十分成熟了，不要浪费基于云的可观测性。

autovacuum
#

监控autovacuum process的SQL参考sql autovacuum_queue_and_progress

大库的autovacuum freeze
#

只要把参数、监控、告警配好，autovacuum freeze在绝大部分库中，都是不太需要关注的。

但是，在一些事务并发超高、数据特别大的库，仍然不可以忽略。因为autovacuum prevent wraparound可能随时都在跑，此时至少要关注如下两点：

年龄告警，及时处理并尽量避免下一次告警。不要出现快死到临头了才来着急挽救（加速方案需要看版本，比如INDEX_CLEANUP OFF,BUFFER_USAGE_LIMIT的调整）
对内存（特别是cache）的冲击。如果autovacuum跑个不停，库又特别大，对cache也有一定冲击，对内存是有影响的

原理和参数参考howstos这个图：

大表跑不动
#

大表指上百GB的表，一般有许多索引和死元组才会“跑不动”。

跑不动的主要原因是：(auto)vacuum会根据死元组，一条条的去索引上清理死索引元组。一般大表的(auto)vacuum就慢在这里，一般可以看到这个大表的死元组也比较多。更恐怖的是，这可能导致(auto)vacuum的运行速度慢于死元组生成速度，也就是(auto)vacuum永远跑不完，无限膨胀。

对于大表跑不完的场景经验：

同一表，死元组数基本与执行时间成正比
从autovacuum日志中的user time，elapsed time可以观察使用cpu时间和执行时间，即可大致推测delay sleep时间
关闭autovacuum cost-based delay，可以减少3倍执行时间（与索引大小相关，属于来源：200GB表，280GB索引）
调整某表的autovacuum cost-based delay含义是让autovacuum跑这个表更少的休息，会在更短的时间内消耗更多CPU以及扫描表时的io

如何加速？

repack。repack属于釜底抽薪型，可以快速重建表，在应急时可以使用。但repack毕竟是cli工具，每次去跑比较麻烦。
调整autovacuum的 cost-based delay参数。可1.调大cost limit alter table t1 SET (autovacuum_vacuum_cost_limit=1000); ,或者2.直接关闭delay睡眠时间alter table t1 SET (autovacuum_vacuum_cost_delay=0);。建议仅对autovacuum跑不过来的表调整。
删除不必要的索引。扫描索引并更新索引条目的时间是最久的，删除不必要的索引当然有效
分区表。推荐分区大小不大于10GB；改造为分区表是最好的方案
删除updated_time字段索引以利用HOT，以减少膨胀率

checkpoint和bgwriter
#

checkpointer不仅要打检查点，跟实例恢复的时间相关，它还会做刷脏。而bgwriter只是做刷脏。从pg 17开始一些指标转移到pg_stat_checkpointer ，这里以pg 17-为例，基本只看pg_stat_bgwriter

一、checkpoint间隔

指标checkpoints_timed：对应checkpoint_timeout参数
指标checkpoints_req：对应max_wal_size参数。

推荐以checkpoint_timeout为基本的checkpoint间隔，如果出现checkpoints_req，应该将max_wal_size调大，并配合调整刷脏参数。有FPI时也应该检查这两个指标表现。

二、刷脏指标

指标buffers_checkpoint：checkpointer刷脏数
指标buffers_clean：bgwriter刷脏数
指标buffers_backend：backend刷脏数，这应该尽量少的出现，出现说明bgwriter刷脏不够激进
指标buffers_backend_fsync：意义不明

刷脏调参目标以刷脏优先级为目标，刷脏优先级为：bgwriter刷脏 > checkpointer刷脏 > backend刷脏

checkpointer虽然可以顺手刷脏，但是checkpointer不好控制刷脏速度，即可能出现checkpointer会引起IO突刺的情况。所以bgwriter的刷脏优先级应高于checkpointer。backend刷脏自不必多说，这是backend触发的刷脏，应尽量减少这种情况。

三、bgwriter刷脏参数

bgwriter是通过“写多少停一下然后继续写的方式”来控制刷脏速度的。

参数bgwriter_delay：停多久
参数bgwriter_lru_maxpages：一次最多写多少
参数bgwriter_lru_multiplier：一次写多少=(近期buffer allocate* lru_multiplier)，但不大于lru_maxpages
参数bgwriter_flush_after：刷多少后做fsync
指标pg_buffers_alloc：可以代表共享内存buffer的分配量。（allocate是产生了实质的换入的，可以一定程度上代表内存换入pgpgin）。
指标maxwritten_clean：到达bgwriter_lru_maxpages的次数

默认的bgwriter刷脏逻辑：一次刷（新buffers数*2，但不大于100个dirty buffers），delay 200ms，每刷64个buffers后 fsync。

平时的一周期刷脏量跟近期的buffer allocation多少和bgwriter_lru_multiplier参数相关，而在高峰期时buffer allocation一般是比较高的，所以高峰期一般会触达bgwriter_lru_maxpages上限。所以可以这样理解：bgwriter_lru_maxpages用于限制高峰期刷脏上限；bgwriter_lru_multiplier用于控制低峰期不要频繁刷脏。

四、刷脏参数参考

默认最大bgwriter刷脏=100*5*8k=3.9M/s。默认bgwriter刷脏参数肯定是偏小的，如果需要调大的话应该结合shared_buffer的大小和负载来进行调整。

说了半天理论，实际可以参考如下调整：

#读写比2:8，负载较高
shared_buffers=40GB
checkpoint_timeout=20min;
max_wal_size=80GB
bgwriter_delay=20ms
bgwriter_lru_maxpages=1000
bgwriter_lru_multiplier=4

看情况再进行下一步调整。

至于效果，从实际的经验来看，不要期待单独调整bgwriter可以有好的效果。甚至bgwriter调整的过于激进可能会有反向效果。

所以，你的库没有明确定位到是checkpoint刷脏突刺或者其他刷脏的问题，那就不要动这个。仅推荐核心大库、并发高的库，在调整其他东西的时候（比如迁移时、调shared buffer时等）一并调整刷脏，当成附属调优策略。

五、刷脏参数总结

bgwriter刷脏可以总结为“三难”：

“难懂、难调、难有效果”

DB4AI
#

AI任务调度信息写入数据库
#

AI的应用已经在开发层面已经应用得非常广泛，其中一个场景是调用AI的任务会写进数据库，任务调用可能是瞬间极高的，而写入数据库的请求可能是没有并发控制的，所以会导致数据库的cpu或者其他资源使用率飙升。

这是一个AI时代背景下的一个新的数据库故障场景，careful。

vector hnsw
#

参考资料：https://postgresql.us/events/pgconfnyc2024/sessions/session/1862/slides/172/pgvector_best_practices_pgconfnyc2024.pdf

HNSW索引构建加速
#

HNSW索引在构建的时候可以非常慢，百万行数据可以慢到以小时计。

影响HNSW索引构建速度的，除了套餐的内存（和cpu）以外，还有索引构建参数，例如：

maintenance_work_mem=3g
max_parallel_maintenance_workers=2
m=12
ef_construction=100

创建HNSW可能非常折磨人，我们可以有以下手段加速创建索引：

在数据写入前建索引，其实是一个选择。虽然initial整体时间更慢，但是开发可接受慢一点，但接收不了建1个小时的索引
在数据写入后建索引优化
- SET maintenance_work_mem = '8GB'
- SET max_parallel_maintenance_workers = 8

after建索引需要注意内存问题，跟套餐内存，空闲内存强相关

注意maintenance_work_mem 是可以起到保护OS mem的作用，如果maintenance_work_mem超过了OS mem可分配内存，且表很大，则直接报错中断连接（快速报错）
```
ERROR: 53200: could not resize shared memory segment "/PostgreSQL.1390017142" to 6439348672 bytes: Cannot allocate memory
LOCATION: dsm_impl_posix, dsm_impl.c:314
```

注意创建过程中使用的内存超过maintenance_work_mem会有info提示（达到一定时间）

NOTICE: 00000: hnsw graph no longer fits into maintenance_work_mem after 886990 tuples
DETAIL: Building will take significantly more time.
HINT: Increase maintenance_work_mem to speed up builds.
LOCATION: InsertTuple, hnswbuild.c:525

HNSW索引查询速度
#

查询的召回率和性能之间需要做平衡，通过调整ef_search参数实现。

查询时除了ef_search参数影响较大外，还有一个影响查询返回速度的因素：HNSW索引是否缓存在内中。

索引不在内存中：

explain (analyze,buffers) SELECT image_id, applyNo, feature_vector <-> (select vectorsit
 FROM image_features_test2
 ORDER BY distance
 LIMIT 10;
 QUERY PLAN 
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Limit (cost=11852.80..11865.74 rows=10 width=35) (actual time=82193.073..82193.185 rows=10 loops=1)
 Buffers: shared hit=1796 read=9309
 I/O Timings: shared/local read=82108.559
 InitPlan 1 (returns $0)
 -> Limit (cost=0.00..0.02 rows=1 width=32) (actual time=0.008..0.009 rows=1 loops=1)
 Buffers: shared hit=1
 -> Seq Scan on test_0 (cost=0.00..23.60 rows=1360 width=32) (actual time=0.007..0.008 rows=1 loops=1)
 Buffers: shared hit=1
 -> Index Scan using idx_feature_hnsw on image_features_test2 (cost=11852.78..1292546.60 rows=989705 width=35) (actual time=82193.071..82193.179 rows=10 loops=1)
 Order By: (feature_vector <-> $0)
 Buffers: shared hit=1796 read=9309
 I/O Timings: shared/local read=82108.559
 Planning:
 Buffers: shared hit=1
 Planning Time: 0.130 ms
 Execution Time: 82193.279 ms

索引在内存中：

 QUERY PLAN 
----------------------------------------------------------------------------------------------------------------------------------------------------------------
 Limit (cost=11852.80..11865.74 rows=10 width=35) (actual time=20.240..20.350 rows=10 loops=1)
 Buffers: shared hit=11105
 InitPlan 1 (returns $0)
 -> Limit (cost=0.00..0.02 rows=1 width=32) (actual time=0.007..0.008 rows=1 loops=1)
 Buffers: shared hit=1
 -> Seq Scan on test_0 (cost=0.00..23.60 rows=1360 width=32) (actual time=0.007..0.007 rows=1 loops=1)
 Buffers: shared hit=1
 -> Index Scan using idx_feature_hnsw on image_features_test2 (cost=11852.78..1292546.60 rows=989705 width=35) (actual time=20.239..20.344 rows=10 loops=1)
 Order By: (feature_vector <-> $0)
 Buffers: shared hit=11105
 Planning:
 Buffers: shared hit=1
 Planning Time: 0.093 ms
 Execution Time: 20.392 ms

同一个索引，同一个执行计划，索引是否在内存中的性能差距是82193.279/20.392=4000倍！

这个差距是不可忽略的，关注HNSW索引性能时，一定要观测HNSW索引是否在内存中。SQL参考如下：

--buffercache查看hnsw是否在shared buffer中缓存
SELECT c.relname, pg_size_pretty(count(*) * 8192) as buffered, round(100.0 * count(*) / (SELECT setting FROM pg_settings WHERE name='shared_buffers')::integer, 1) AS buffer_percent, round(100.0 * count(*) * 8192 / pg_table_size(c.oid), 1) AS percent_of_relation FROM pg_class c INNER JOIN pg_buffercache b ON b.relfilenode = c.relfilenode INNER JOIN pg_database d ON (b.reldatabase = d.oid AND d.datname = current_database()) GROUP BY c.oid, c.relname ORDER BY 3 DESC LIMIT 10; 

 relname | buffered | buffer_percent | percent_of_relation 
---------------------------------+------------+----------------+---------------------
 idx_feature_hnsw_1 | 2117 MB | 91.9 | 44.5
 idx_feature_hnsw | 78 MB | 3.4 | 2.0
 pg_inherits_parent_index | 8192 bytes | 0.0 | 100.0

业务发版
#

ddl的技巧
#

online ddl工具pg-osc、pg_migrate都不支持分区表，而且工具还有一些其他问题，真实使用比较困难。所以DDL的技巧还算比较有用，可以降低锁级别、提前识别阻塞等以减少DDL阻塞和重写带来的风险。

理解这个图的关键点：

变更前的注意事项：

确保表上没有长事务——长事务会长期持有表上的锁，长事务在pg中是危害这是共识，应先处理长事务
确保表上没有autovacuum (to prevent wraparound)——autovacuum一般不会阻塞SQL，但做to prevent wraparound的除外

Autovacuum workers generally don’t block other commands. If a process attempts to acquire a lock that conflicts with the SHARE UPDATE EXCLUSIVE lock held by autovacuum, lock acquisition will interrupt the autovacuum. However, if the autovacuum is running to prevent transaction ID wraparound (i.e., the autovacuum query name in the pg_stat_activity view ends with (to prevent wraparound)), the autovacuum is not automatically interrupted.
lock_timeout=2000——即拿不到锁超过2s就不拿了，以免引发大面积阻塞

字段小改大的特例：

字段小改大一般不会重写表，但有几个例外。特别要注意int->bigint（常见主键字段）, char(n)->char(m)）
分区表索引。分区表字段小改大不会重写表，但会重建索引，而分区表重建索引一般都非常慢，很可能造成长期8级锁阻塞。这个特性是普通表没有的。

修改字段类型：

基本都会重写表，除了一些类型等价，或者属于另一种小改大的

DDL降低锁级别的注意点：

索引用CIC，分区不支持就子表CIC（记得attach index）
CIC执行分了好几个阶段。其中2、3阶段会获取share锁，阻塞dml（官方文档只说了SHARE UPDATE EXCL.（不等DML），CIC不是单纯的显式锁）
添加主键用using index，分区不支持就利用“子表加主键+父表添加主键可合并已存在的子表主键的特性”
约束用validate constraint
17以前不支持not null validate，可以用check(col1 IS NOT NULL)。这个check转not null也不会产生多余的扫描
加字段有default易失会重写，可以用非易失不重写特性先加字段，不会重写。存量数据看情况update
分区表attach时可以利用check约束减少停机时间，而添加check约束又可以用到validate constraint
create table like+attach比partition of的锁低很多（但我还是喜欢parition of）

变更后的注意事项：

记得收集统计信息（很多场景需要）

并发创建索引
#

在生产运维时，可能会碰到需要创建索引，但表又特别大，创建时间很长的情况。并发创建索引可以缩短建索引的时间。

普通表并发建索引：

并行参数：max_parallel_maintenance_workers

前提：

worker是够的，需要检查max_parallel_workers,max_worker_processes
调整maintenance_work_mem 上GB

注意事项：

对 B-tree or BRIN有效
maintenance_work_mem limit to entire utility command。跟parallel query不同，parallel query的资源限制是 per worker process

从测试结果来看，并发建索引在8个并发以后收益不明显（这个结论在不同环境可能不保真）。

分区表并发建索引：

推荐分区子表手搓并发，即一次在多个分区上创建，而不是使用原生并发，这可以减少多进程交互代价。

cached plan must not change resource
#

业务前晚新增字段后，早上业务连接报错：“cached plan must not change result type in PostgreSQL”

复现：

create table a(b varchar(10));
PREPARE p1 (varchar) AS SELECT * FROM a WHERE b=$1;
ALTER TABLE a ALTER COLUMN b TYPE varchar(20);
EXECUTE p1 ('abcd');

ERROR: 0A000: cached plan must not change result type
LOCATION: RevalidateCachedQuery, plancache.c:718

测试环境的解决办法： DEALLOCATE ALL主动丢弃prepared statement 或者， DISCARD ALL主动丢弃整个会话状态

DEALLOCATE ALL; --DISCARD ALL
PREPARE p1 (varchar) AS SELECT * FROM a WHERE b=$1;
EXECUTE p1 ('abcd');

生产环境的解决办法：

由于是业务层报错，JDBC可识别DEALLOCATE ALL,DISCARD ALL，但是业务可能没有做过。当下生产可执行如下方案：

解决办法（四选一）：

由于hikari等连接池的轮询启用连接和轮询timeout机制，可kill idle会话，报错会逐渐减少
同样是由于连接池的轮询启用连接和轮询timeout机制，可什么都不做，等连接池逐渐建立和启用新的连接
如果业务压力足够大，可考虑kill所有业务连接
轮询重启业务

不推荐：

DDL后重启应用。有效，但不要建议“所有DDL后都应该重启应用”这样的方案
autosave=conservative。有效，但会启用子事务。savepoint is set for each query, however the rollback is done only for rare cases like ‘cached statement cannot change return type’ or ‘statement XXX is not valid’ so JDBC driver rolls back and retries

jdbc配置建议：

配置jdbc事务回滚后自动重试：https://developer.aliyun.com/article/741750
其他jdbc配置参考：https://jdbc.postgresql.org/documentation/server-prepare/#corner-cases，注意有些建议是不能上生产的。

物理复制
#

查询冲突
#

查询冲突是一个非常坑的特性，它直接影响了PG从库的查询是不那么好用的。查询冲突会导致从库延迟增加，而从库的拉数SQL本身要跑一段时间是符合逻辑的，这就导致PG管理者不得不在延迟管理和长SQL管理中做出平衡。而这个特性在其他关系型数据库中是不存在的。

查询冲突要注意的隐蔽特性：

静态表同样会产生查询冲突（见-从静态表查询冲突到其原理），也就是说冲突是快照冲突，与查询的表本身的锁几乎没有关系，快照冲突是跨表的。
长查影响短查。长查把从库延迟推到max_standby_streaming_delay后，此时的短查也会被掐断。
不停的短查也会引起查询冲突。例如上个短查还没有结束，下一个短查又开始了，这两个短查逻辑可能是类似的，此时startup进程还没有来得应用日志。这在跑批中比较常见。这两个短查都持有那个需要应用的xid，可以检查pg_stat_activity.backend_xmin是否小于startup正在应用的xid

查询从库推荐的实践：

通过RTO SLO来调整max_standby_streaming_delay是一个不错的选择。当吵架到没有结果时，使用SLO来进行IT管理会救命。
短平快的业务查询与抽数、报表等长查询应该分到不同的从库，减少相互影响
从库查询SQL也是需要优化的
从库的日志应用延迟是需要监控的

逻辑复制
#

逻辑复制的坑可以说非常多了。24年有很多非常坑的案例，25年也遇到一些案例，但不算特别坑，而且主要是一些低版本pg上出现的，总体来看高版本的pg逻辑复制倾向稳定。

低版本PG+DDL/DCL语句解析较慢
#

案例-授权和walsender跑不动

PG13及之前的版本，对某些DDL、DCL语句解析较慢，可能会影响walsender延迟。这些DDL、DCL包括：

批量授权（含grant all tables）+ 安装了pathman extension（无论是否使用）
批量DDL/TRUNCATE/DCL/DROP PUBLICATION

低版本PG+多链路重复解析+flink
#

flink只能一个表一条链路，加上pg的walsender是重复解析的，一个pg库上几十条flink链路的walsender都是常见情况，而且改造困难。

而在pg11及以前，在walsender主循环中有PostmasterIsAlive()函数，导致主循环性能较差。从pg12开始WalSndLoop函数没有在主循环中频繁轮询PostmasterIsAlive()，而是将状态检查放到WalSndWait中，通过事件机制被动等待通知。这极大的缓解了CPU的争用。

如果库中有多个flink链路，而且pg版本较低，建议升级版本，可以缓解一定的walsender资源争用问题。这些可以缓解的资源问题包括：

可能会解决walsender启动时资源争用导致数据库长时间起不来的问题
可能会解决上游大量数据变动（含DDL重写）导致runtime walsender解析日志的cpu打满问题

低版本PG无法自动同步新分区
#

PG声明式分区在低版本需要注意仅能通过子表发布。pg版本>=13才支持按照父表配置发布，低于这个版本只能按分区子表的名称配置同步：

Allow partitioned tables to be logically replicated via publications (Amit Langote) § §

Previously, partitions had to be replicated individually. Now a partitioned table can be published explicitly, causing all its partitions to be published automatically. Addition/removal of a partition causes it to be likewise added to or removed from the publication. The CREATE PUBLICATION option publish_via_partition_root controls whether changes to partitions are published as their own changes or their parent’s.

也就是说，这个分区表如果是同步上游，每新增分区时，都要适配同步工具做发布，不然无法同步新分区数据。

迁移和升级
#

迁移信创和glibc升级
#

无论是信创迁移还是LINUX OS版本升级，都可能涉及glibc的升级，而glibc升级可能会非常坑。pg的排序在17以前都是完全依赖操作系统的。

pg没有办法检测glibc升级带来的兼容性问题。GNU C library每个小版本都会对locale做出改动，现实中最容易出问题的版本是glibc 2.28，因为2.28升级了大版本unicode 9.0.0(has been updated to a new upstream version from ISO which is in sync with Unicode 9.0.0)。

排序规则分了很多种，而很多环境用的是语义排序（例如en_US.utf8），语义排序也是最吃版本的。排序规则变化最常见的是引起查询索引时数据库奔溃，也还有其他不常见问题比如重复主键、分区表数据存入错误分区、merge join结果返回不一致等等。

好在pg17提供了非常安全的locale提供方式：builtin，不再依赖OS提供的glibc、ICU等provider。启用命令例如：

initdb --locale-provider=builtin --bultin-locale=C.UTF-8 dbname1

但是，

builtin虽然是个好东西但是来得太迟了。大量已投入使用的数据库实例，想转builtin的字符集可不是一件容易的事。而且，信创迁移或者OS升级可能不会将数据库升级作为强制动作。

信创迁移时，信创主机的glibc版本一般都比老的英特尔服务器glibc版本高，很可能跨了2.28这个版本。加上任务急、kpi推动、人力不足和大库，物理迁移是在所难免。所以信创物理迁移得关注glibc版本和collation导致的许多异常。

物理迁移后可以做什么？

一、官方必修方案

1.check索引，重建明显有问题的索引

2.REFRESH DATABASE COLLATION VERSION

3.检查依赖对象

4.REFRESH COLLATION VERSION

二、非官方邪修方案

我这没有做出完整的方案，只是一点思路。

1.处理分区表写入错误分区的问题

分区键是int/bigint/float，跟collation没有关系，可以不用管了

分区键是时间分区，如果是timestamp不用管了，如果是varchar等等字符类型，就看情况了

分区键是字符类型，参考“a”和“-”的排序（pgconf Collation Challenges Sorting It Out）。但要注意以下几点

如果要查数据的话，不要从父表查，可能会崩或者查不出来
没有简单的检测方案

2.处理主键/唯一键冲突

3.处理fdw排序范围异常的问题

4.未知问题

参考collation

丝滑大版本升级
#

https://gitlab.com/postgres-ai/postgresql-consulting/postgres-howtos/-/blob/main/0077_zero_downtime_major_upgrade.md?ref_type=heads

https://www.postgresql.eu/events/pgconfeu2023/sessions/session/4791/slides/439/2023.pgconf.eu%20Zero%20Downtime%20PostgreSQL%20Upgrades.pdf

一般的大版本升级方案：

pg_upgrade原地升级。不推荐，可能原地爆炸。
pgdump：适合小库，窗口期较长的库
逻辑同步+switchover（发布订阅/pg_logical/dts等）：适合小库，窗口期较短的库
物理正向同步+逻辑反向同步：适合大库，窗口期不太长的库
物理复制全量+逻辑同步增量+switchover：适合大库，窗口期极短的库

用逻辑同步同步全量数据可能是非常慢的，而用新从库原地升级本身带有不确定性，有一定的升级时间，而且也要解决反向逻辑同步的问题。“丝滑大版本升级”其实就是“物理复制全量+逻辑同步增量+switchover”。

丝滑大版本升级的主要技术：主库创建slot会返回LSN，新从库recovery_target_lsn 恢复到这个LSN，然后开启逻辑同步。

方案的大致流程：

预检查。多db（多db要考虑应用一个slot lsn）、插件、pathman、trigger、外键、unlogged表、crontab等等
物理同步。新老版本软件、对比和备份conf文件、pg_basebackup搭建低版本新库
逻辑同步准备一。主键和复制标识、创建发布；禁止业务发布DDL/DCL
新库恢复到target LSN。停新库；老库创建slot并记录LSN；新库以target LSN启动
新库大版本升级。升级、处理各种问题、环境变量切换
逻辑同步准备二。禁用trigger、外键、任务、插件等
逻辑同步。创建指定slot的copy_data=false订阅
逻辑同步后。索引损坏检查、检查日志报错并修复、重建同城远程
switchover。停业务；提升序列、启用外键、trigger、任务等
switchover。搭建反向链路（老库订阅）
switchover。业务切换

丝滑大版本升级的方案对于业务很丝滑，对于DBA很复杂。这个方案包含了逻辑迁移和物理迁移的所有缺点，做起来是比较痛苦的，以上步骤已经简化过了。该方案消耗DBA人力，对于非常重要的库可以考虑这个方案。

分区表的管理
#

Postgres分区表非常灵活，没有自增interval分区功能，而且版本多变，导致分区表运维管理问题几乎是年年发生。我相信有不少PG DBA对于新分区的各种问题还提心吊胆的。

我自己观察下来分区表的管理和使用主要有如下问题：

未使用声明式分区表。老版本仍然使用pathman分区或继承表分区，或者即便升级后仍然使用pathman分区或继承表分区。PG10开始支持声明式分区，由于早期版本有功能不足，建议至少PG12以后就仅使用声明式分区表，以减少环境的复杂性。
开发自建子表索引/主键。不通过父表默认继承而是通过SQL直接在子表建索引/主键，会导致下一次开发写SQL时可能就忘记了。这不仅会导致父子不一致，也会导致子子不一致，最终导致分区表结构面目全非。
新分区无管理策略。忘记建新分区或者用default分区。一般开发会建个几年的分区，下一次可能开发都换了一批了，没人会去管这个新分区建设。这会定时炸弹随时爆炸，或者数据写入default分区失去分区意义。
缺乏DBA的管理。是的，DBA！PG的分区表知识实在是多（参考PostgreSQL分区表），怎么基于自己的环境做管理策略和落地，需要专业DBA的主动推动。这可能是最重要的。

自己思考的分区表管理目标（copy的这个案例-20260101分区数据更新失败）：

以主表结构为标准结构，即主表面向开发，它上面应该有主键、索引、复制标识（pg版本不支持除外）
主表与子表保持一致，使用partition of创建新分区（是的，我不推荐attach）
子表与子表保持一致
提前创建新分区，分区数据量不宜过多
default分区不建议创建，如果创建必须监控其写入情况
频繁访问的表的SQL必须包含分区键，使用分区裁剪，不然改造为普通表

可观测性
#

从官方文档中基本都能看到数据库、表、索引、SQL、刷脏等等指标释义，还是比较清楚的。

其中有几个指标可能要特别注意一下，不仅解释的不是很清楚，而且常用且有理解成本。

buffers_alloc、blks_read
#

pg_stat_bgwriter.buffers_alloc： Number of buffers allocated，共享内存置换量
pg_stat_database.blks_read ：os cache读

（buffers_alloc在不同PG版本可能在不同视图中，但含义不变）

pg_stat_bgwriter.buffers_alloc是共享内存的buffer分配量，源码中叫buffer allocation。可以代表共享内存的置换量，新起的库一般这个值比较高。观察共享内存繁忙程度时，buffer allocate可能要比命中率好，命中率高可能就是小表频繁访问拉高了，allocate是产生了实质的置换的。

buffers_alloc是从cache读数后加载到新的共享内存buffer，其实也能一定程度代表os cache read吧？但是实际观察下来，buffers_alloc与blks_read含义如此相似但数值可能差异较大。为什么？没搞懂，待研究。

源码：numBufferAllocs

tup_fetched、tup_returned
#

这俩是pg_stat_database 中的指标：

tup_fetched ：索引扫描最终获取的行数，去掉了过滤条件、死亡元组、不可见行后的行。偏向于结果。
tup_returned ：索引扫描回表的行数，不管是否满足过滤条件、死亡元组、不可见行后的行。偏向于处理过程

所以，tup_returned 一般比tup_fetched 高不少。而异常高，也代表可能有优化空间，因为毕竟访问了这么多数据，实际上没有返回给客户端多少。

idx_tup_fetch 、idx_tup_read
#

这俩是pg_stat_all_indexes 中的指标：

idx_tup_read ：从索引计数的访问索引条目数，包含bitmap scan
idx_tup_fetch ：从表计数的索引扫描最终返回的行数，不包含bitmap scan

疯了

可以记住一个点：xx_tup_fetch是指经过索引回表访问后返回的最终行数，偏向于结果。

参考内容
#

postgres-ai howtos

Best practices for using pgvector

案例-20260101分区数据更新失败

PostgreSQL分区表

案例-从distinct不准确到DISTINCT的计算原理

案例-添加索引性能下降和generic plan

从静态表查询冲突到其原理

控制文件上的参数和主从参数不一致问题

https://liuzhilong.blog.csdn.net/article/details/130783036

https://techcommunity.microsoft.com/blog/adforpostgresql/improving-postgres-connection-scalability-snapshots/1806462

https://www.postgresql.org/docs/17/sql-prepare.html

https://www.postgresql.org/docs/17/sql-deallocate.html

https://www.postgresql.org/docs/release/13.0/

https://jdbc.postgresql.org/documentation/use/

https://jdbc.postgresql.org/documentation/server-prepare/#server-prepared-statements

https://www.postgresql.eu/events/pgconfeu2023/sessions/session/4791/slides/439/2023.pgconf.eu%20Zero%20Downtime%20PostgreSQL%20Upgrades.pdf

感谢25年跟高大师的battle

案例-20260101分区数据更新失败

Sun, 04 Jan 2026 00:00:00 +0000

现象
#

12月30日发现业务报错，数据无法更新：

ERROR: 55000: cannot update table "tablzl_202601" because it does not have a replica identity and publishes updates
HINT: To enable updating the table, set REPLICA IDENTITY using ALTER TABLE.
LOCATION: CheckCmdReplicaIdentity, execReplication.c:575

临时恢复
#

因为报错信息充足，没有复制标识，表是一个分区表，又是26年的分区，所以直接怀疑新分区没有主键（新表的复制标识是default，default只能用主键作为复制标识，没有主键就会无法更新）。

然后发现，父表没有任何主键和索引，25年以前的老子分区有主键和索引，26年以后的新子分区没有任何主键和索引，且所有子分区有发布。大概如下：

p_parent --无主键无索引
p_child_202511 --有主键有索引，有发布
p_child_202512 --有主键有索引，有发布
p_child_202601 --无主键无索引，有发布
p_child_202602 --无主键无索引，有发布

因为父表什么都没有，所以partition of添加子分区也会什么都没有，只有自己准备子分区的主键和索引，所以推测新分区创建的有问题，老分区新建时应该是处理过的。

另外，通过父表发布分区表是PG13才开始支持，以前不能通过父表发布，只能通过子表发布，该库版本是PG11。

Allow partitioned tables to be logically replicated via publications (Amit Langote) § §

Previously, partitions had to be replicated individually. Now a partitioned table can be published explicitly, causing all its partitions to be published automatically. Addition/removal of a partition causes it to be likewise added to or removed from the publication. The CREATE PUBLICATION option publish_via_partition_root controls whether changes to partitions are published as their own changes or their parent’s.

初步知道问题后，因为情况紧急，可以通过3个办法来临时解决：

26年新分区添加主键
26年新分区设置replica identity full
26年新分区取消发布表

因为恢复时间都差不多，所以从减少运维成本的角度，通过添加主键恢复，至少先让业务不报错。

根因分析
#

问题看似清晰，就是“没有复制标识+发布过+没有主键”导致不能更新，但是还有一些问题需要解答。

疑问一：为什么update没有更新202601的数据（新分区根本没有数据），仍然报错
#

拿到SQL文本如下：

UPDATE tablzl_202601
 SET idid = $1,...
 date_updated = now()
 WHERE mykey = $4

tablzl_202601表的分区键是created_date，SQL条件就没有分区键，所以去更新202601分区发现连个主键都没有所以就报错了。

至于检查是否有行和检查复制标识谁先，从ExecSimpleRelationUpdate可以看到逻辑，这个函数在不同的PG版本中变化极小：

/*
 * Find the searchslot tuple and update it with data in the slot,
 * update the indexes, and execute any constraints and per-row triggers.
 *
 * Caller is responsible for opening the indexes.
 */
void
ExecSimpleRelationUpdate(EState *estate, EPQState *epqstate,
						 TupleTableSlot *searchslot, TupleTableSlot *slot)
{
...
	CheckCmdReplicaIdentity(rel, CMD_UPDATE); //检查复制标识

	/* BEFORE ROW UPDATE Triggers */ //before ROW UPDATE trigger
	if (resultRelInfo->ri_TrigDesc &&
		resultRelInfo->ri_TrigDesc->trig_update_before_row)
	{
		slot = ExecBRUpdateTriggers(estate, epqstate, resultRelInfo,
									&searchslot->tts_tuple->t_self,
									NULL, slot);

		if (slot == NULL)		/* "do nothing" */
			skip_tuple = true;
	}

	if (!skip_tuple)
	{
		List	 *recheckIndexes = NIL;

		/* Check the constraints of the tuple */ //检查约束
		if (rel->rd_att->constr)
			ExecConstraints(resultRelInfo, slot, estate);
		if (resultRelInfo->ri_PartitionCheck)
			ExecPartitionCheck(resultRelInfo, slot, estate, true);

		/* Materialize slot into a tuple that we can scribble upon. */
		tuple = ExecMaterializeSlot(slot);

		/* OK, update the tuple and index entries for it */ //更新行
		simple_heap_update(rel, &searchslot->tts_tuple->t_self,
						 slot->tts_tuple);

		if (resultRelInfo->ri_NumIndices > 0 && //插入索引条目
			!HeapTupleIsHeapOnly(slot->tts_tuple))
			recheckIndexes = ExecInsertIndexTuples(slot, &(tuple->t_self),
												 estate, false, NULL,
												 NIL);

		/* AFTER ROW UPDATE Triggers */ //after ROW UPDATE trigger
		ExecARUpdateTriggers(estate, resultRelInfo,
							 &searchslot->tts_tuple->t_self,
							 NULL, tuple, recheckIndexes, NULL);

		list_free(recheckIndexes);
	}
}

ExecSimpleRelationUpdate大致过程：

检查复制标识
before ROW UPDATE trigger
检查约束（包括非分区约束和分区约束）
更新行
插入索引条目
after ROW UPDATE trigger

所以pg逻辑就是先检查复制标识，然后才是更新行等等操作。

虽然SQL条件没有分区键，但是加上分区键就会裁剪吗？答案是可能不会。

分区裁剪的版本提升：

pg10刚支持声明式分区，没有enable_partition_pruning参数，可以通过constraint_exclusion在planning阶段裁剪。所以pg10没有query process pruning
pg11支持query process pruning，Allow partition elimination during query execution (David Rowley, Beena Emerson)。但只支持绑定变量裁剪，不支持非immutable函数裁剪（包括now()）
pg14支持最终裁剪，This wins in UPDATEs on partitioned tables when only some of the partitions will actually receive updates。即支持非immutable函数裁剪

因为pg11不支持now()裁剪，如果业务SQL加now()条件不会触发裁剪，仍然会报错。但是如果业务通过绑定变量传入，是会触发裁剪的，也就不会报错。注意，这个报错指的是更新202512的数据不会在202601分区上报错，更新202601的数据该报错还是报错。

疑问二：表是20251226创建的,为什么是10月30日发现有问题
#

这个就更简单了，“没有复制标识+发布过+没有主键”是且的关系。

虽然新分区建的比较早，但发布表的时间是12月29日晚20:47

cat postgresql-12-29.csv.bak |grep "alter publication"
2025-12-29 20:48:07.730 CST,"userlzlreplication","lzldb",xxx"statement: alter publication publzl add table ""public"".""tablzl_202601"", ""public"".""tablzl_202602"",...,,,,,,,,,""

首次报错时间是12月29日晚22:26，也就是1个半小时左右以后：

 cat postgresql-12-29.csv.bak |grep "REPLICA IDENTITY"
2025-12-29 22:26:01.404 CST,"userlzlreplication","lzldb",375121,xxx,"cannot update table ""tablzl_202601"" because it does not have a replica identity and publishes updates",,"To enable updating the table, set REPLICA IDENTITY using ALTER TABLE.",,,,"UPDATE tablzl

总结
#

原因概述：如果父表没有主键，新分区partition of创建时当然也不会有主键，老的子分区通过子分区主键实现，新的子分区没有去主动创建主键，导致202601主键缺失。链路同步需要依赖主键（default）作复制标识，没有复制标识会导致无法同步给下游，也会导致发布以后update/delete语句无法正常执行。在PG 11中，update SQL本身即使包含分区键条件，也可能会去访问新分区。

运气成分：因为各种原因，这个库提前发现了这个问题。在31号我们有1天的buffer来补救所有数据库实例，至少保证1号新分区数据update别报错，不然大概率2026年1月1日多个系统将原地爆炸。

临时措施（三选一）：

26年新分区添加主键
26年新分区设置replica identity full
26年新分区取消发布表

对于复制链路的优化：

应该提前发现没有主键的表，不然直接发布的话，可能会导致业务侧更新失败

对于分区管理的策略：

PG的分区表非常灵活，而且一般开发弄不懂怎么去正确创建分区，再加上分区表在大概PG10-15之间有较多的重要新特性，加上PG分区表没有interval分区功能，分区表可能弄的乱七八糟，所以规范管理分区表显得尤为重要。分区表的特性和运维技巧见：PostgreSQL分区表

针对管理手段就不说了，

针对管理目标：

以主表结构为标准结构，即主表面向开发，它上面应该有主键、索引、复制标识（pg版本不支持除外）
主表与子表保持一致，使用partition of创建新分区（是的，我不推荐attach）
子表与子表保持一致
提前创建新分区，分区数据量不宜过多
default分区不建议创建，如果创建必须监控其写入情况
频繁访问的表的SQL必须包含分区键，使用分区裁剪，不然改造为普通表

ref
#

https://www.postgresql.org/docs/release/10.0/

https://www.postgresql.org/docs/release/11.0/

https://www.postgresql.org/docs/release/12.0/

https://www.postgresql.org/docs/release/13.0/

https://www.postgresql.org/docs/release/14.0/

src/backend/executor/execReplication.c

PostgreSQL分区表

论文精读：插件无政府状态

Sat, 03 Jan 2026 00:00:00 +0000

论文：Anarchy in the Database: A Survey and Evaluation of Database Management System Extensibility

github：https://github.com/cmu-db/ext-analyzer

pgconf：The trouble with extensions (PGConf.dev 2025)

why this paper
#

这是一篇数据库插件综述（主要是Postgres），主要讲不同数据库插件的实现方式、存在的问题和最重要的兼容性。其中最重磅的结论是：对 400 多个 PostgreSQL 扩展的评估显示，其中 16.8% 的扩展与至少一个其他扩展存在兼容性问题，且可能导致系统故障。

分析工具和结果见github；Marco Slot的ppt演讲见PGconf。

插件类别
#

插件分类
#

插件分类章节特别冗长，其实一个图就能看明白了。

6种数据库的插件：

PostgreSQL（1986）：C 语言编写，从设计之初就定位为可扩展架构。因此，PostgreSQL 拥有最为丰富多样的可扩展生态网络。
MySQL（1994）： C++ 语言编写，其最知名的特性是存储引擎插件架构。
MariaDB（2009）：作为 MySQL 的分支版本，它同样基于 C++ 开发，支持的扩展数量比原版 MySQL 更多。
SQLite（2000）：嵌入式数据库，C 语言编写，可适配各类硬件设备与操作系统环境。
Redis（2009）：内存型键值库，C++ 语言编写，其可扩展性独具特色 —— 仅支持在 DBMS key-value存储层之上运行。
DuckDB（2018）：嵌入式分析型数据库，C++ 编写，拥有快速兴起的可扩展生态系统。

灵活性和安全性
#

插件的安全性和灵活性只能二选一，pg的插件是最灵活也是最不安全的，redis是最安全也最不灵活的：

postgres的插件一般怎么实现的
#

pg总体有两种方式实现扩展：

通过handler function实现，如UDF,UDTs, external tables, storage engines, and index access methods.
通过hooks钩子实现扩展。将钩子声明为全局变量中的函数指针，如果设置了钩子，它将调用这些指针而不是自己的代码

实现方式可能是都包含的，并不排他。其他5个库的实现总体类似，但是他们都没有hooks这种形式的实现。

插件可能使用不同的方式来实现，比如funcion+types+index am，这就是可扩展性类型数量（number of extensibility types）。从figure 1可以看到有1-3中类型的扩展是最多的，而使用最多的实现方式就是function。

从table3可以看出，有92.5%的插件都在使用UDF，毕竟是面向用户的特性，开发最为方便、门槛低。最少的是客户端认证，因为这种场景本身也不多。

插件代码的copy率
#

文章还进行了一个有趣的调查研究，插件代码从build-in代码中的copy情况：

441个插件中有16.6%–73个插件含有至少1行从PG源码中copy的代码。详细分布如上图左。

为什么有这么多插件是copy的代码呢？因为

pg源码中有些是静态声明的函数，只能在本文件中调用，所以只能copy
因为插件本身的需求，函数可能需要做出一点调整，所以只能copy出来调整

而插件一般copy函数调整了多少呢？如上图右。

可以看出，原封不动copy的其实是很少的。

总之，插件代码从pg源码中copy，是因为某些原因而不得已的，整体copy率也不高。

重磅！——PG插件的兼容性
#

这是这篇文章最有趣的部分，总计对96个extension进行1对1的兼容性测试，测试发现有16.8%的两个插件是不兼容的！

测试方式：

安装。是的，安装就可能有问题了，并且作者进行了A->B,B->A两种顺序的安装和测试，所以可以看到图是不对称的
运行扩展提供的单元测试
pgbench。冒烟测试。pgbench当然很简单，不过结果很不错的话也可以说明一定问题了。

在兼容性最差的插件top20里面，也能看到很多常见的插件：

常用的插件：pg_hint_plan,vector,pg_show_plans,pgsentinel,pg_cron,pg_stat_kcache
很重的插件：citus,timescaledb

这些极其常见的插件和明星插件的兼容性可以这么差，这个结果足以惊掉下巴。

细思极恐的是，这还只是简单的捉对测试，3-10个插件的运行才应该是生产常态，而且生产环境也比论文中的三种测试方式更加复杂多变。

最后论文还提出插件兼容性较差的原因：插件使用越多的组件、扩展type、hooks，就越有可能跟其他扩展不兼容。

挑刺
#

其实还是研究的postgres

文章标题是写DBMS的，但主要还是写pg的兼容性，mysql、redis等等的兼容性只是综述带过，完全没有实验数据。（虽然综述也很有意思，可以了解到mysql和redis的插件是怎么实现的）。

另一个方面，这个文章有一种另类”总-分-总“的感觉，“ DBMS-postgres-DBMS”😅

兼容性测试不足

PG有400+插件，只测试了其中96个兼容性测试，也只有1-1的兼容性测试，不包含3个插件及以上的测试。兼容性测试不算特别全面。

结论
#

PG的插件确实很多很灵活，数量也很多，你都很难找到哪些是PG插件不支持的功能。但是插件本身几乎是“无政府状态”，插件的开发和使用都有些问题。

从兼容性结果来看，插件的兼容性是比较差的，甚至插件的安装顺序影响兼容性，多插件本身也依赖hook的执行顺序，比如2个插件都要求自己最后执行就比较尴尬了。“什么都有”不代表“什么都装”。

插件的安全问题
#

PG的插件在安全层面管理几乎是没有的，无论是插件本身不安全还是用户使用插件提权。

如果扩展包含有不安全的语言，能限制其行为的只有OS而不是DBMS
如果扩展可以访问用户空间，OS层就做不了管理了
通过查询（如UDF）实现的extension基本不会绕过ACL策略。虽然UDF更安全，但是也不是绝对安全，因为可以有含管理员权限的UDF。
单hook可能不会受到ACL的限制，因为在postgres中ACL只在planning和execution层执行。PG提供了SECURITY LABEL来限制对象（包括插件）的访问控制

软件管理的哲学思考
#

“如果扩展包含有不安全的语言，能限制其行为的只有OS而不是DBMS”

这句话本身没有毛病，但是含有“你的目录会被删除”的暗示。为了反驳一下这句话，可以这样思考。

如果你使用这款软件，那么就是信任这款软件，如同pg本身一样（但即使使用pg这款软件，也需要建立postgres这个os user，而不是直接使用root）。至于插件，可以把它当成pg软件的一部分。pg之所以被信任，能直接在生产环境安装，是因为业界有口皆碑。同样插件也是一样的，选择有口皆碑的插件，而不是胡乱使用。这本质上是postgres社区把关和插件提供方把关的区别。对于云服务商，很多插件都是不支持的，云服务商承担了插件把关的职能和背锅的责任。

版本收敛
#

pg的插件版本有这些特性：

同一个插件，不同的数据库版本会有不同的插件包
插件有不同的版本

这就导致对插件版本没有管理的话，会出现多到难以管理的软件version。针对这个问题，限制不同PG版本安装指定的某一个插件版本，是一个不错的选择。至于处于某些需求的原因需要插件升级，通过pg版本升级来实现。这样的策略相当于牺牲了一定的灵活性，来保证稳定性。我个人认为是值得的，因为升级插件这个需求本身不多，但可以减少很多软件管理问题和未知的兼容性问题。

使用插件时要考虑兼容性问题
#

既然插件兼容性不怎么样，那么管理插件变得尤为重要，我们不希望数据库返回奇怪的结果甚至跑着跑着就挂了

插件管理策略：1.安装必要插件 2.再按需创建需要的插件 3.不要装没什么人用的插件
搜索兼容性矩阵。虽然PG兼容性测试并不完美，但还是有价值的。因为论文不好直接搜兼容性矩阵，但可以“ctrl+f”搜索ext-analyzer的兼容性表格，初步判断你需要使用的插件的兼容性是否优秀。

趣闻
#

在1976年的INGRES论文中，已通过扩展实现了UDF；即使是POSTGRES，也在1986年的初始版本中转移了这个功能实现。而ORACLE 的UDF实现是ORACLE 7，release时间是1992年，比PG晚不少。

而SQL标准是1996年才包含了UDF，离INGRES的UDF过去了整20年。stone braker确实是不太注重标准的推动。

案例-行锁与LWlock-lockmanger

Sun, 21 Dec 2025 00:00:00 +0000

现象
#

数据库有大量行锁和少部分LWlock lockmanger，cpu打满，活动会话飙升。锁对应的block pid在变化，未见明显长事务阻塞。 (脑补cpu和活动会话高）

大量的锁对于的sql如下：

UPDATE lzl_record SET rc_lzl1= rc_lzl1 + $1, pc_lzl2 = pc_lzl2 + $2, rc_lzl3 = rc_lzl3 + $3 where lzl_id = $4

分析
#

SQL未见并发上涨
#

从hit和cpu的关联性看，可以从sql的hit分析。其中那个UPDATE sql占比80%左右，该sql的执行次数没有变化，但blks hit明显异常。

同时分析元数据访问，快照内均元数据表没有访问特别高的。

从现象分析看不出来SQL并发上涨，也看不出来元数据异常。SQL hit上涨暂时看不出来为什么。

LWlock lockmanager分析
#

因为SQL本身简单，lzl_record表的lzl_id字段是唯一字段，也就是通过唯一键进行更新。

现场的等待事件除了大量的显示锁以外，还有LWlock lockmanager。

但表是普通表不是分区表，且表上只有4、5个索引。

LWlock lockmanger跟没有用到fast path有关系，而简单的查询、DML可以用到fastpath

Weak relation locks. SELECT, INSERT, UPDATE, and DELETE must acquire a lock on every relation they operate on, as well as various system catalogs that can be used internally. Many DML operations can proceed in parallel against the same table at the same time; only DDL operations such as CLUSTER, ALTER TABLE, or DROP – or explicit user action such as LOCK TABLE – will create lock conflicts with the “weak” locks (AccessShareLock, RowShareLock, RowExclusiveLock) acquired by DML operations.

所以，一个不超过访问16个relation（含索引）的SELECT/DML是可以用到fastpath的，就不应该有很多LWlock lockmanager。

但是，DML肯定不能简单的用fastpath，fastpath是完全本地化处理锁，DML肯定需要校验其他会话是否持有行，需要访问共享内存。再加上SQL通过唯一字段更新还能有行锁，说明肯定更新的是同一行。

从日志上可以看到更新同一行的情况，其中一行有锁等待的更新有上万次。

压测
#

压测同一行更新产生LWLock LockManager
#

出于行锁肯定不能仅fastpath的考虑，以及LWLock LockManager会降低数据库性能的经验，压测不同场景性能情况。

#prompt
给我一个pgbench压测脚本
表结构：主键,唯一字段+唯一索引，其他字段
更新：通过唯一字段更新

压测重复更新同一行数据，也就是重复行锁更新
压测随机更新某一行数据，也就是无行锁更新

脚本略，套餐20c96g

pgbench命令如下

pgbench -h localhost -p $PGPORT -d lzldb -U dbmgr -f update_same_unique_key.sql -c 200 -j 32 -T 600 -r -S
pgbench -h localhost -p $PGPORT -d lzldb -U dbmgr -f update_random_unique_key.sql -c 200 -j 32 -T 600 -r -S

压测时的等待事件：

 --更新同一行，常见2次等待
 usename | state | wait_event | wait_event_type | cnt 
----------+--------+---------------------+-----------------+-----
 dbmgr | active | LockManager | LWLock | 105
 dbmgr | active | transactionid | Lock | 61
 dbmgr | active | tuple | Lock | 25
 dbmgr | active | [null] | [null] | 8
 dbmgr | active | WALSync | IO | 1
 
 usename | state | wait_event | wait_event_type | cnt 
----------+--------+---------------------+-----------------+-----
 dbmgr | active | transactionid | Lock | 180
 dbmgr | active | LockManager | LWLock | 18
 dbmgr | active | tuple | Lock | 1
 dbmgr | active | WALSync | IO | 1

--更新不同行，常见2次等待
usename | state | wait_event | wait_event_type | cnt 
----------+---------------------+---------------------+-----------------+-----
 dbmgr | active | [null] | [null] | 106
 dbmgr | idle | ClientRead | Client | 34
 dbmgr | idle in transaction | ClientRead | Client | 25
 dbmgr | active | WALWrite | LWLock | 21
 dbmgr | active | BufferMapping | LWLock | 7
 dbmgr | idle in transaction | [null] | [null] | 4
 dbmgr | idle in transaction | WALWrite | LWLock | 2
 
 usename | state | wait_event | wait_event_type | cnt 
----------+---------------------+---------------------+-----------------+-----
 dbmgr | active | [null] | [null] | 117
 dbmgr | idle | ClientRead | Client | 42
 dbmgr | idle in transaction | ClientRead | Client | 24
 dbmgr | active | WALWrite | LWLock | 12
 dbmgr | active | XactGroupUpdate | IPC | 1
 dbmgr | active | WALSync | IO | 1
 dbmgr | active | XactSLRU | LWLock | 1
 dbmgr | active | BufferContent | LWLock | 1
 dbmgr | active | ClientRead | Client | 1

从等待事件上可以看出差异，更新同一行会出现LWLock LockManager甚至占比较高的情况，不同行基本都是等cpu。场景1与生产情况类似。

行锁与fastpath浅析
#

lmgr readme对fastpath的解释：

Fast Path Locking
-----------------

Fast path locking is a special purpose mechanism designed to reduce the
overhead of taking and releasing certain types of locks which are taken
and released very frequently but rarely conflict. Currently, this includes
two categories of locks:

(1) Weak relation locks. SELECT, INSERT, UPDATE, and DELETE must acquire a
lock on every relation they operate on, as well as various system catalogs
that can be used internally. Many DML operations can proceed in parallel
against the same table at the same time; only DDL operations such as
CLUSTER, ALTER TABLE, or DROP -- or explicit user action such as LOCK TABLE
-- will create lock conflicts with the "weak" locks (AccessShareLock,
RowShareLock, RowExclusiveLock) acquired by DML operations.

能使用fastpath的锁的条件lmgr/lock.c：

/*
 * The fast-path lock mechanism is concerned only with relation locks on
 * unshared relations by backends bound to a database. The fast-path
 * mechanism exists mostly to accelerate acquisition and release of locks
 * that rarely conflict. Because ShareUpdateExclusiveLock is
 * self-conflicting, it can't use the fast-path mechanism; but it also does
 * not conflict with any of the locks that do, so we can ignore it completely.
 */
#define EligibleForRelationFastPath(locktag, mode) \
	((locktag)->locktag_lockmethodid == DEFAULT_LOCKMETHOD && \
	(locktag)->locktag_type == LOCKTAG_RELATION && \
	(locktag)->locktag_field1 == MyDatabaseId && \
	MyDatabaseId != InvalidOid && \
	(mode) < ShareUpdateExclusiveLock)

SELECT/DML是可以使用fastpath的，但是仅限于locktype=relation。

实际查看行锁时的锁情况：

--窗口1
begin;
update lzl1 set b='zzz' where a=1;

--窗口2
begin;
update lzl1 set b='zzz' where a=1;
--waiting


--窗口3
 select * from pg_locks where pid<>(select pg_backend_pid()) order by pid,locktype;
 locktype | database | relation | page | tuple | virtualxid | transactionid | classid | objid | objsubid | virtualtransaction | pid | mode | granted | fastpath 
---------------+----------+----------+--------+--------+------------+---------------+---------+--------+----------+--------------------+--------+------------------+---------+----------
 relation | 4267681 | 5290151 | [null] | [null] | [null] | [null] | [null] | [null] | [null] | 5/4791 | 220559 | RowExclusiveLock | t | t
 transactionid | [null] | [null] | [null] | [null] | [null] | 170706189 | [null] | [null] | [null] | 5/4791 | 220559 | ExclusiveLock | t | f
 transactionid | [null] | [null] | [null] | [null] | [null] | 170706190 | [null] | [null] | [null] | 5/4791 | 220559 | ExclusiveLock | t | f
 transactionid | [null] | [null] | [null] | [null] | [null] | 170706187 | [null] | [null] | [null] | 5/4791 | 220559 | ShareLock | f | f
 tuple | 4267681 | 5290151 | 0 | 1 | [null] | [null] | [null] | [null] | [null] | 5/4791 | 220559 | ExclusiveLock | t | f
 virtualxid | [null] | [null] | [null] | [null] | 5/4791 | [null] | [null] | [null] | [null] | 5/4791 | 220559 | ExclusiveLock | t | t
 relation | 4267681 | 5290151 | [null] | [null] | [null] | [null] | [null] | [null] | [null] | 7/562 | 253641 | RowExclusiveLock | t | t
 transactionid | [null] | [null] | [null] | [null] | [null] | 170706187 | [null] | [null] | [null] | 7/562 | 253641 | ExclusiveLock | t | f
 virtualxid | [null] | [null] | [null] | [null] | 7/562 | [null] | [null] | [null] | [null] | 7/562 | 253641 | ExclusiveLock | t | t

pg的行锁实现比较复杂，不仅有tuple锁，还需要transactionid和relation锁。其中只有locktype=relation、virtualxid能用到fastpath，其他都用不到。

对比没有行锁：

--窗口1
begin;
update lzl1 set b='zzz' where a=1;

--窗口2
begin;
update lzl1 set b='zzz' where a=2;
--waiting

select * from pg_locks where pid<>(select pg_backend_pid()) order by pid,locktype;
 locktype | database | relation | page | tuple | virtualxid | transactionid | classid | objid | objsubid | virtualtransaction | pid | mode | granted | fastpath 
---------------+----------+----------+--------+--------+------------+---------------+---------+--------+----------+--------------------+--------+------------------+---------+----------
 relation | 4267681 | 5290151 | [null] | [null] | [null] | [null] | [null] | [null] | [null] | 5/4792 | 220559 | RowExclusiveLock | t | t
 relation | 4267681 | 5290151 | [null] | [null] | [null] | [null] | [null] | [null] | [null] | 5/4792 | 220559 | AccessShareLock | t | t
 transactionid | [null] | [null] | [null] | [null] | [null] | 170706214 | [null] | [null] | [null] | 5/4792 | 220559 | ExclusiveLock | t | f
 virtualxid | [null] | [null] | [null] | [null] | 5/4792 | [null] | [null] | [null] | [null] | 5/4792 | 220559 | ExclusiveLock | t | t
 relation | 4267681 | 5290151 | [null] | [null] | [null] | [null] | [null] | [null] | [null] | 7/563 | 253641 | AccessShareLock | t | t
 relation | 4267681 | 5290151 | [null] | [null] | [null] | [null] | [null] | [null] | [null] | 7/563 | 253641 | RowExclusiveLock | t | t
 transactionid | [null] | [null] | [null] | [null] | [null] | 170706212 | [null] | [null] | [null] | 7/563 | 253641 | ExclusiveLock | t | f
 virtualxid | [null] | [null] | [null] | [null] | 7/563 | [null] | [null] | [null] | [null] | 7/563 | 253641 | ExclusiveLock | t | t

fastpath=f的也就少了2、3个。2个会话持有的transactionid锁是肯定用不到fastpath了。

总结使用fastpath锁机制的场景（且）：

锁等级<=3，即SELECT/DML语句
locktype=relation。pg的行锁还至少需要transactionid和tuple锁，所以这俩用不到fastpath
relation数少于16个（一般分区表全分区访问就超了）

总结
#

1.行锁是因是果，是行锁的问题还是数据库性能下降SQL跑的慢了出现行锁？

行锁是因。sql执行次数没有变化，但是sql的传参从离散变成集中，即更新同一行的情况明显增加。从压测数据来看更新同一行会出现行锁和LWLock LockManager的等待。

2.sql执行次数没有上涨，SQL性能是否下降？

SQL性能其实是下降了，但是索引肯定没有走错，只是因为反复更新了同一行。

解决方案：

从业务层了解SQL是某接口开关调用后讲调用次数更新到表里。如果是同一接口反复调用，是可能出现反复更新同一行的情况的。所以，减少同一接口反复调用或者更大批次的更新数据库，预计可以减缓这个问题。

论文精读：DBAIOps

Sun, 21 Dec 2025 00:00:00 +0000

论文：DBAIOps: A Reasoning LLM-Enhanced Database Operation and Maintenance System using Knowledge Graphs

repo：https://github.com/weAIDB/DBAIOps/

什么是DBAIOps
#

1.why DBAIOps：

人力运维非常耗时
人力运维难以扩展
人力运维常期困于重复的故障
文档+RAG模型不准确（没有DBA经验集成或有限制的局限性）

总之，人力运维和现有方案都一般般，所以推出了DBAIOps——结合大模型推理和知识图谱的运维系统，实现类DBA的诊断能力。

2.数据库故障分析方案对比：

预设规则方案：传统方案，比较死板
机器学习方案：本质上是基于规则的，有许多类似的限制；依赖训练数据，会造成较低的生成能力，一般适合特点问题常见的诊断。
基于LLM方案：使用一般文档和LLM（例如基于决策树），容易给出一般结果
LLM+RAG方案：搜索基于分片的top-k临近知识，结果不准确

3.对比了以上方案后，可以看出结合了图知识、DBA经验、LLM的DBAIOps的优势：

结合DBA经验
保留原始关系
支持新的根因定位和解决方案
可扩展

overview
#

左侧是架构，右侧是示例。

offline做的是DBA经验嵌入neo4j，嵌入后的图模型叫ExperienceGraph，图的边代表异常现象或者metric的关系。嵌入后的异常模型称为AnomalyModel。

online做的是异常分析、检索、生成报告。其中AnomalyProcessor提取标准故障信息和AnomalyModel信息，然后通过ExperienceRetriever检索图；最后RootCauseAnlyser调用LLM生成分析报告。

从右侧的示例可以看到，通过图相关性找到LOG FILE SYNC关联的LOG WRITE性能、IO性能；通过REDO ALLOCATION可以找到表结构变更和DDL。

运维经验的图模型
#

不同于基于规则或者基于文档chunk的RAG，ExperienceGraph是编码了运维经验异构信息的图模型。图包含三个元素：（顶点、带方向的边，边上的关系）。

根据运维经验的特性，DBAIOps对其中顶点进行了分类：

trigger vertex：用于检测数据库异常，是异常分析的入口。例如LOG FILE SYNC就是入口顶点
metric vertex：数据库运行时的metric。如果是离线知识，指的应该是运维案例里的metric（如果有的话）
experience vertex：编码了领域特定的运维经验，涵盖异常的含义及处置方法。比如LOG FILE SYNC超过60ms代表提交过于频繁或者其他参数需要调整。
tool vertex：收集和分析异常指标的可执行脚本
tag vertex：图顶点的语义类别。比如并发事务Concurrent Transactions涉及多种顶点，tag vertex可以加强跨案例的关联性
auxiliary vertex：解释指标的含义

对边的分类：

containment edge：Trigger Vertex-Experience Vertex
relevance edge：Trigger Vertex-Metric Vertex
diagnosis edge：Experience Vertex -Metric Vertex
sysnonym edge：只出现在Tag Vertices-Tag Vertices之间，表示语义上同义，比如physical_read and disk_read; shared_pool and shared_buffer

以示例来分析运维经验图模型：

LOG FILE SYNC有多种TAG，TAG跟Experience、metric、tool关联。能看出来关联性非常强，它代表了人类DBA对LOG FILE SYNC的理解和运维经验。

图的构建
#

手搓图是不靠谱的，现有的ML生成图可能生成没关系的关系，所以提出了半自动的图生成方案。

图的初始化：这一部分是手动生成的，根据规则来定义trigger vertices。trigger vertices一旦生成，其关联的metric vertex、experience vertex等会自动生成。这部分有点像人类DBA指导创建知识草图，总的框架不能动，不能生成一些稀奇古怪的东西。
图的存放：就是放到Neo4J里；另外，不同的数据库类型通过tag来标记，这样很多知识是通用的，也避免了重复构建图。
图的增强：生成更多的边
图的更新：DBAIOps支持增量更新。这里的更新不仅指新增新的vertex，也包括去掉老的vertex

异常模型
#

metric
#

metric的来源有很多，包括运行信息（CPU %，吞吐等日常监控）、日志、trace等等，再加上相关性的差异，还需要从中取出关联性较强的metric。所以将metric分成了2类：

立即收集的metric：运行信息、日志、trace
后续收集的metric：周期、delta等metric，需要的时候再生成，比如AWR/ASH数据

在metric和异常相关性上，不同于基于基线的关联方式，DBAIOps采用每种异常都基于特定的metric组合。

最后通过一个公式来判断是否确实发生异常：

两阶段图演化
#

数据库异常很少孤立发生，一个性能问题可能同时触发或恶化其他问题。然而，预构建的知识图谱中不同异常模型 (如 LOG_FILE_SYNC 和 REDO_ALLOCATION) 之间的连接往往松散，共享的经验片段稀疏且碎片化。这导致传统方法难以发现跨模型的复合根因，如 I/O 瓶颈与内存压力的组合问题。

为解决这一挑战，DBAIOps 提出了自动 “图演化” 机制，动态发现并连接不同异常模型间的相关经验片段，使知识图谱从初始的稀疏结构逐步演化为密集互联的网络，从而支持更全面的根因分析。

第一阶段-Graph Inference and Proximity Discovery (图推理与邻近发现)：通过图查询语言 (Cypher) 收集和聚合相关指标，基于可配置阈值遍历相关节点和边，构建关联网络。例如LOG_FILE_SYNC 延迟，从顶点出发，遍历最多 3 跳的关联节点。在 LOG_FILE_SYNC 和 REDO_ALLOCATION 模型间建立连接，因为它们都与 I/O 相关的并发问题有关。通过多次迭代，知识图谱逐渐演变为更密集的结构，使诊断能考虑更多潜在因素和复合原因。
第二阶段-Adaptive Abnormal Metric Detection (自适应异常指标检测)：在图扩展路径上识别真正异常的指标。通过自适应检测函数（ADF），结合指标波动性、动态基线偏差等维度计算综合异常分数，依据异常评分结果，决定是否需要进一步扩展知识图谱结构，为后续 LLM 的根因推理筛选出精准的异常指标子集。

生成分析报告
#

图搞定后，就需要prompt喂给LLM来生成想要的报告，一个合理的prompt也可以提升报告的准确性。

异象有5种成分，这5种成分作为prompt给LLM：

Anomaly：异常描述（“CPU usage spiked to 95% at 16:00 on 2023-10-05”）
Condition：异常触发条件（“exceeds 90% for >5 min”）
Metrics
Experience：提供正常负载值，或者最近的维护任务
Output：描述报告的组成的。有异常验证（需要继续分析的）、根因分析、恢复方案、汇总、SQL文本

自己的一点想法：

最近的维护任务很有用，维护任务一般来说关联性是比较大的，故障分析也不是能是简单的技术分析。不过谁去更新这个维护任务、哪些要更新哪些不更新应该是问题。

output中前几个都好理解，最后一个SQL文本可谓神来一笔。在生产环境中，抛开硬件故障，数据库的运行状态跟SQL是强相关的，我个人认为可以无脑抓SQL，抓出来再说因果关系的问题。从运维工作的角度来讲，故障都需要跟开发共同排查，那么SQL文本基本是必抓取的。

评估
#

不同工具、方式下，生成的分析报告的效果对比：

可以看出来很强了。特别要注意的是，DBAIOps特别强调了中型大模型的分析效果就已经很好了。这个还是比较重要的，DeepSeek-R1 671B裸跑就不差，但是成本不是一个级别的。

挑点刺
#

1.不能完全叫Ops，只是有故障分析功能。Ops内容是很多的，故障分析只是冰山一角。

2.图的分类和图的示例对不上号。定义的tag vertex和edge跟示例的差别比较大。

示例中的vertex作用很大，但是没有定义这些边的类型：tag vertex-tool vertex、tag vertex-experience vertex、tag vertex-metric vertex。而应该存在的边，看上去基本都没有，只有一个sysnonym edge。

应该列举出来示例中没有说明的部分，不然看的云里雾里的。

3.两阶段图演化的效果有点怪：

w/o ADF代表没有第二阶段图演化（自适应异常指标检测）

w/o ADF代表没有第一阶段图演化（图推理与邻近发现）

w/o ADF代表两个阶段都没有的图演化

这里少了两阶段都有的图演化，有的话就更能说明两阶段图演化的效果。

4.根因有些少：

上面几个圈起来的应该是比较常见的（我只看了oracle、postgres），但是暂时没有这些根因。

pg的根因有点少，刷脏一般不算太大的问题，刷脏根因本身，大概率排到众多根因的后面了。

总结
#

我个人非常喜欢的点：

1.GraphRAG在故障诊断方面，应该会比vector RAG好。

（GraphRAG原始论文：From Local to Global: A GraphRAG Approach to Query-Focused Summarization）

SS代表vector RAG，TS代表源文本摘要，C0/C1/C2/C3代表不同知识粒度的GraphRAG。从这个图可以简单得出结论：GraphRAG更适合多预料复杂场景，多角度分析，但在精准度上其实不一定比vectorRAG好

2.半自动的图生成方案

图生成是半自动的，trigger vertex手搓，其他可以自动生成。例如LOG FILE SYNC就是trigger vertex。故障的入口确实可以做出明显的异常点，这就是入口，PG也是一样的，任何故障应该也是一样的，符合人类对故障的理解逻辑。

.自动图演化

加强某些vertex的关联性，是有意义的，Performance of DBAIOps** Variants表格可见一斑

4.自动基线调整

在《可观测性工程》中对AIOps有这么一段话：

AI只有在存在清晰可辨的模式并且可以识别不断变化的基线来进行预测时才能提供帮助——目前还没有这种AIOps

DBAIOps在我的眼中

清晰可辨的模式= DBAIOps中的图，它包括了故障模型、异常关系、监控数据和日志

不断变化的基线= DBAIOps中的自适应异常指标检测

总之，比随意chunk故障知识、拍一个基线、vector近似搜索的RAG模型要进步很多了。

我的年终总结2025

Sun, 21 Dec 2025 00:00:00 +0000

As a DBA
#

作为一个DBA，在问题分析方面我非常相信第一性原理与信息论。DBA需要非常了解这套系统，了解postgres，才能从原理上解释异象。比如上半年花了很多精力去了解linux内存，去探索内存问题的本质和解决方案。同时，今年在系统运维层面更进了一步，不再仅关注技术层面的问题和处理，而更关注提供解决方案，它应该包含postgres数据库技术维度、系统维度和管理维度的思考。

简单分类了一下云DBA的工作：

很多Ops论文都只是说故障处理，实际上故障处理应该不到运维实际工作量的5%，而且无论是学术还是实际，anamaly ops本身效果也不好，所以我不是很看好AIOps能帮DBA大忙这件事。请注意DBA运用AIOps和DBA运用AI是两码事。

其实这个图一般般，因为没有包含领导任务，领导任务肯定是大头

然后看了下23、24年的年记，可以简单给出我这个dba的工作年度总结：

2023年全面学习postgres
2024年全面运维postgres
2025年负责1510情绪价值

非常讽刺的是，去年有一个结论“dba在给领导们提供1510情绪价值”，今年就陷进这个结论实践了。多的也不想说，总之是很累，心力交瘁。希望明年会有改善。

READING
#

今年比去年看的书更多了（从20+到30+本），反倒是写的什么读书笔记之类的更少了。写东西确实麻烦，很费精力，而我也更喜欢看书的感觉。今年看的书相比于去年，明显pg技术类的减少，技术综合类的增多，甚至开始看心理学、经济学和哲学。总之是狩猎更广，不是仅限于数据库本身了。同时小说也更少了，小说像零食一样，越发对此类没有营养的内容没兴趣。

今年的书单总体分为IT系统类、经济学、科普类、心灵类、小说类，还是像去年一样凭个人喜好排个先后顺序。

IT系统类书单：

1.《SRE Google运维解密》：DBA并不是SRE，不过其工作含有对系统稳定性的目标，这跟DBA是有类似之处的。本书中有些云环境或者管理方面的内容，确实获益匪浅，例如对SLA、系统工程、运维压力、工作琐事、角色轮换、“相信团队而不是相信某一个技术专家”等等内容，非常精彩。前段时间还听到DBRE–Database Reliability Engineer这个概念，比DBA都符合我现在的工作定位。总之是一本好书，现代运维必读之书。

.《奔跑吧 Linux内核入门篇》：运维开源数据库，必须了解操作系统。我研究linux内存的书之一

2.《深入理解Linux进程与内存》：我研究linux内存的书之一

2.《深入理解Linux内核》：我研究linux内存的书之一

5.《可观测性工程》：传统监控和传统运维的模式和缺陷，可观测性本质又是什么，还是比较有帮助的。

经济学书单：

《微观经济学》：神作，作者德隆·阿西莫格鲁。我理解为人生必读读物，这本书是我笔记做的最好的一本书。不仅了解经济，也进一步了解这个社会。里面有些观点我印象深刻，比如

证明为什么市场是一个无形的手，使社会剩余价值最大化，任何调整都会减少社会剩余价值。
什么情况下市场是无效的，无效的有：外部性、公共资源、公共池塘。
女性的职场收入比男性低，其中一个原因是女性要生育，生育期间不能参与生产。
学历的作用是信息传递。也就是一定程度上保真这个人的生产价值
企业的进入和退出是市场正常的信号，不代表紊乱
公平与效益的权衡是一个课题

2.《国家为什么会失败》：神作，作者德隆·阿西莫格鲁。一句话可以总结这本书：国家为什么成功？因为有破坏性创新。德隆·阿西莫格鲁是24年诺贝尔经济学得主，获奖理由是 “对制度如何形成以及如何影响繁荣的研究”。更难得的是，这本书相比于其他经济学著作更容易让人理解。经济学首推神作。

3.《理性乐观派》：说是比肩《人类简史》，那肯定是差一截了。但是内容性不差，也更偏经济学。里面有些观点非常新颖，比如：

现代经济使富人更富，但贫者并未愈穷
自给自足就是贫穷
人类与动物的区别是物物交换（在人类简史里面是认知革命）
收入越多会越幸福，这是事实
贸易在社会地位中的提升，是因为海洋贸易的兴起。因为陆地贸易不稳定，非常容易被掠夺。

4.《股票大作手回忆录》：好像学到了什么好像又啥也没学到。好看还算是好看。

.《博弈论》：说实话，我觉得一般。内容是不多的，也很浅显，主要是经济学老提到博弈论，所以就翻开评鉴一下。

6.《国富论》：非常晦涩，不是给正常人看的，内容性非常强。亚当·斯密一定是个天才，难以想象是什么脑子写出来的。对我来说难度太高，没看完放弃了。

科普类书单：

1.《A BREIF HISTORY OF INTELLIGENCE》：神作，AI时代必读物，这本书被我翻到陈旧，到处都是笔记。解构人类的大脑，理解什么是智力，理解AI是怎么来的。我给满分！我现在只要看到一个动物，首先会想它是什么智力级别···

2.《浪潮之巅》：作者吴军。每个IT工作者都应该看的一本书。讲述IT大公司的沉浮，你可以了解到ORACLE、GOOGLE、仙童、贝尔实验室、甚至融资方面的基础知识。每个公司都有自己的基因，这个基因几乎是不可改变的，也决定了公司的文化和特点。程序员必读。

3.《纳瓦尔宝典》：有很多有用的观点，比如对边际效益的看法。还有更重要的是，里面推荐了我今年最喜欢的书之一——《微观经济学》。以及推荐了改变我习惯的冥想。

4.《如何管理一家软件公司》：作者是弗兰克・斯洛特曼 (Frank Slootman)，一位带领三家软件公司 (ServiceNow、Data Domain、Snowflake) 成功实现 IPO 的硅谷传奇 CEO。很不错的书，从IT公司管理者的角度看待公司发展、员工管理、执行力、决策以及决策失误等等。非常推荐。

5.《银发经济学》：作者大前研一。从日本老龄化问题窥探中国老龄化问题和机遇。天朝的人口结构隐患严重，差不多要到暴雷的时候了，在这个时代下，非常推荐一读。

6.《第四次浪潮》：作者大前研一。主要是讲日本没有赶上IT科技浪潮，仍然是老工业在支撑国民经济，看上去有些嫉妒韩国和中国。我个人很喜欢作者直接喷首相的态度，哈哈。

7.《清单革命》：讲解西医手术前的清单检查的必要性，看似简单的步骤可以极大的提升手术成功率。这本书对我的工作有很大的影响，我确实把清单这个概念带入了工作，我也把数据库运维当成一次外科手术，清单是提高手术成功率的简单又必要的手段。

《人月神话》：“加人”不能使系统工程项目时间线性减少，但也不能通过这个简单的排斥“加人”，因为大型系统工程确实需要很多人协作完成。是不错的书，但是说程序员必读，感觉有点过了。

9.《数学之美》：作者吴军。也挺不错的书，技术总有他的数学基础，这本书通俗易懂地讲述数学之美。

10.《麦肯锡结构化思维》：任何问题都应该结构化拆解，我遇到新的问题我会这么思考。有用的书。

11.《菊与刀》：几年前的囤货没有看所以掏出来看的。写一个二战后的老美对日本的看法，可以窥探一些日本的文化，比如改良的儒家文化，无“仁”，亏欠心理等等。有个缺点是有点太久远了，现在的日本很大程度上不是以前那个样子。

12.《黑天鹅》：黑天鹅指没有预测到的奇异事件。黑天鹅事件总是会发生的，没有100%预测准确这种事情。同时里面还说到分类，我自己联想了一下《结构化思维》《the world I see》的内容，“人类理解事物的本质是对事务分类”，但是分类总会将一些东西分得尴尬甚至分不下去，黑天鹅事件从分类那一刻起就存在了。是一个值得注意的思考，比较有意思。

13.《专业主义》：作者大前研一。非常一般，不推荐

心灵类书单：

1.《欲望的演化》：进化心理学，神作

2.《最优解人生》：在不同的人生阶段，体验正确的事、物，即便是错过后的再体验，也不会有那个时候体验的感受了。人生读物，非常推荐。

3.《十分钟冥想》：主要是讲冥想的重要性，以及怎么去冥想。我就是通过这本书学会的冥想。当我第一次完成冥想时我就爱上了冥想，它给我一种把我带到外太空，然后又回到地球上的感觉。更重要的是，它确实可以减压。冥想已经成为了我生活的一部分。

4.《操纵心理学》：还可以

5.《悉达多》：不明所以，rubbish

6.《生命之书》：纯心灵鸡汤，rubbish

小说类书单：

1.《局外人》：神作。难以描述的真实感，感觉自己就像个局外人。

《yellow face》：很有趣的书，讲的是一个美国白人剽窃一个已故黄种人作家的未发布的作品去发布，甚至笔名都很chinese，当粉丝知道她是白人时，可以感受到有多尴尬。趣味性地探讨种族偏见，像看美剧一样神奇，高潮迭起引人入胜。非常推荐。

3.《昨日的世界》：作者茨威格。一个作家眼中的奥地利、欧洲、一战二战。以另一个角度回到那个动乱的欧洲，很不错的书。

4.《挽救计划》：科幻小说，越发不喜欢看科幻小说了。这本还可以，假如你在外星探索时船员死光光了，你刚好又遇到了一个友好的外星人，你该如何跟他交流···

5.《一个陌生女人的来信》：作者茨威格。不好看，就第一篇新奇一点，其余两篇没有兴趣好好读

6.《撒旦探戈》：不明所以，诺贝尔文学奖亦有差距

博客和公众号
#

公众号的名字一直都很纠结，本来也没什么心思维护，就随便用了几个名字。今年看了个纪录片-最后的棒棒，感触颇多。其实DBA这个行业跟棒棒一样在发生巨变，所以干脆就改成“最后的DBA”了。这个名字还算朗朗上口，也能代表一些时代背景和哲思，看起来是个不错的名字。

由于投入工作的时间很多，本来写东西的时间就不多，再加上今年的运维方式也在不断变化，我的作息怎么调整都调不出一个好的时间段安排，甚至最后投入了一些资金，自己的时间也没见增加，为此恼火了好一阵。现在回过头一看，今年才发了12篇文章，甚至上半年一篇都没有。

很不满意。😠

也不知道是水平高了还是系统真的稳定了，能深入研究的案例似乎变少了。不过这也不算什么大问题，今年还把解读论文当成一种文章类型，我自己感觉效果还可以，能学到不少东西，没有那么故步自封闭门造车。AI去解读论文肯定是快的，但是我自己感觉有2个问题

是否真的理解了。我感觉没有，跟自己去读一遍不是一个概念。自己去读不仅可以了解的更深入，还可以发现一些奇奇怪怪的细节
水不了文章。如果我一个prompt就可以解读论文，那我感觉传播意义不大，现在不用AI的人应该没有了吧

当然不是所有的论文都去一字一句的读，毕竟效率太低了，我只会选一些我感觉还不错有必要逐帧解读的，拿出来细品。

简单总结今年的文章：

数量过少
质量稍有提升，并且是有用的东西(有几篇我个人非常满意)
探索了新的方式

最后
#

今年是忙碌的一年，有不好也有好的回忆，有很多重要的事情没有完成，明年应该做出较大的改变。写这个年记还是挺有意思的，回头看看前几年的自己在干嘛，也是有趣的事情。

去年定的2025年OKR：

一些东西继续–失败
想想怎么做产出–失败
掌握一个其他赛道–半成功
PG···没想好还要怎么做–失败
想办法重拾健身–失败

2025年计划：

一些东西继续
关注自己的心理和身体健康，明年年度巡检告警低于今年
关注文章的阅读量，维护公众号
探索DB AI OPS，明年向自己汇报
向上管理，不可以投入过多时间到工作上
假期旅游而不是卷
读书不低于30本，不可仅关注数量

从collation mismatch异常到其原理

Sat, 13 Dec 2025 00:00:00 +0000

问题现象
#

物理迁移信创后pg log偶有报错，版本是pg15：

WARNING: 01000: collation "zh_CN.utf8" has version mismatch
DETAIL: The collation in the database was created using version 2.17, but the operating system provides version 2.28.
HINT: Rebuild all objects affected by this collation and run ALTER COLLATION pg_catalog."zh_CN.utf8" REFRESH VERSION, or build RaseSQL with the right library version.
LOCATION: pg_newlocale_from_collation, pg_locale.c:1660

前景：物理切换的时候做了失效索引重建和refresh database collation version。

虽然物理迁移后libc版本升了，但是做了索引重建的，索引现在是有效的，而且db中的collation version已经与OS libc一致。

所以，

为什么会报错？

报错哪里触发的？

报错有什么影响？

怎么解决？

问题分析
#

为什么会报错？
#

数据库内部的collation主要看3块：db、列、索引。前两个都是默认collation，索引的collation才是真collation。

先检查database的collation，db的都是en_US.UTF8，且已经refresh database collation过了，所以“collation “zh_CN.utf8” has version mismatch”这个报错不应该在db层抛出。

然后再查看字段没有特殊指定的默认collation：

select attrelid,attname,attcollation from pg_attribute where attcollation not in (0,100,950,951);
 attrelid | attname | attcollation 
----------+---------+--------------
(0 rows)

0表示没有collation，default oid=100,C oid=950,POSIX oid=951；“zh_CN.utf8"肯定不会是这四个。

最后再查看索引没有特殊指定的collation

select * from (select indexrelid ,unnest(indcollation) coll from pg_index) i where coll not in (0,100,950,951);
 indexrelid | coll 
------------+------
(0 rows)

排除db、字段、索引，那么只能是一种情况：业务层指定排序规则

select col1 from (values ('a'), ('A'), ('啊'), ('阿')) AS l(col1) order by col1 collate "zh_CN.utf8";
WARNING: 01000: collation "zh_CN.utf8" has version mismatch
DETAIL: The collation in the database was created using version 2.17, but the operating system provides version 2.28.
HINT: Rebuild all objects affected by this collation and run ALTER COLLATION pg_catalog."zh_CN.utf8" REFRESH VERSION, or build RaseSQL with the right library version.
LOCATION: pg_newlocale_from_collation, pg_locale.c:1660
 col1 
------
 阿
 啊
 a
 A

这个zh_CN.utf8的version就跟实际的不一致：

 select collname,collversion,pg_collation_actual_version(oid) from pg_collation where collname ='zh_CN.utf8';
 collname | collversion | pg_collation_actual_version 
------------+-------------+-----------------------------
 zh_CN.utf8 | 2.17 | 2.28

不仅zh_CN.utf8不一样，所有都不一样（除了几个没有version说法的coll）

所以很有可能是业务自己指定了一个排序规则"zh_CN.utf8”，但是库中的coll version与OS不一致，才抛出了报错。

源码理解
#

通过报错信息是很好定位到源码位置的，主要关注2个函数：pg_newlocale_from_collation和CheckMyDatabase。

`pg_newlocale_from_collation`缓存和检查`pg_collation`
#

pg_newlocale_from_collation是pg10才有

/*
 * Create a locale_t from a collation OID. Results are cached for the
 * lifetime of the backend. Thus, do not free the result with freelocale().
 *
 * As a special optimization, the default/database collation returns 0.
 * Callers should then revert to the non-locale_t-enabled code path.
 * In fact, they shouldn't call this function at all when they are dealing
 * with the default locale. That can save quite a bit in hotspots.
 * Also, callers should avoid calling this before going down a C/POSIX
 * fastpath, because such a fastpath should work even on platforms without
 * locale_t support in the C library.
 *
 * For simplicity, we always generate COLLATE + CTYPE even though we
 * might only need one of them. Since this is called only once per session,
 * it shouldn't cost much.
 */
/* locale_t指非ICU。该函数是为backend cache一个locale_t类型的collation OID
* the default/database collation returns 0。其中default表示使用db的collation
*/
pg_locale_t
pg_newlocale_from_collation(Oid collid) //注意传入的是collation的oid，不是拿所有pg_collation
{
...
	/* Return 0 for "default" collation, just in case caller forgets */
	if (collid == DEFAULT_COLLATION_OID) //有三个特殊的coll：
		return (pg_locale_t) 0; //default oid=100,C oid=950,POSIX oid=951

...
	if (cache_entry->locale == 0)
	{
...
		collversion = SysCacheGetAttr(COLLOID, tp, Anum_pg_collation_collversion,
									 &isnull); //从pg_collation中拿数据字典中的version
		if (!isnull)
		{
...
			actual_versionstr = get_collation_actual_version(collform->collprovider, collcollate); //通过get_collation_actual_version获得实际的version
...
			collversionstr = TextDatumGetCString(collversion);

			if (strcmp(actual_versionstr, collversionstr) != 0) //对比数据字典中的version和实际的version，不同就抛出报错
				ereport(WARNING,
						(errmsg("collation \"%s\" has version mismatch",
								NameStr(collform->collname)),
						 errdetail("The collation in the database was created using version %s, "
								 "but the operating system provides version %s.",
								 collversionstr, actual_versionstr),
						 errhint("Rebuild all objects affected by this collation and run "
								 "ALTER COLLATION %s REFRESH VERSION, "
								 "or build PostgreSQL with the right library version.",
								 quote_qualified_identifier(get_namespace_name(collform->collnamespace),
															NameStr(collform->collname)))));
		}
...
	return cache_entry->locale;
}

主要是通过coll oid检查这个coll在pg_collation数据字典的version和实际的version是否一致，如果不一致就抛出报错。

`CheckMyDatabase`缓存和检查`pg_database`
#

CheckMyDatabase已经存在很久了，它要做很多db方面的检查。不过在pg15增加了检查db version的逻辑

/*
 * CheckMyDatabase -- fetch information from the pg_database entry for our DB
 */
static void
CheckMyDatabase(const char *name, bool am_superuser, bool override_allow_connections)
{
...
	/* Fetch our pg_database row normally, via syscache */
	tup = SearchSysCache1(DATABASEOID, ObjectIdGetDatum(MyDatabaseId));
...
	default_locale.provider = dbform->datlocprovider; //default就是db的

	/*
	 * Default locale is currently always deterministic. Nondeterministic
	 * locales currently don't support pattern matching, which would break a
	 * lot of things if applied globally.
	 */
	default_locale.deterministic = true; //字节序敏感的

	/*
	 * Check collation version. See similar code in
	 * pg_newlocale_from_collation(). Note that here we warn instead of error
	 * in any case, so that we don't prevent connecting.
	 */
	datum = SysCacheGetAttr(DATABASEOID, tup, Anum_pg_database_datcollversion,
							&isnull); //从pg_database中拿datcollversion
	if (!isnull)
	{
		char	 *actual_versionstr;
		char	 *collversionstr;

		collversionstr = TextDatumGetCString(datum);

		actual_versionstr = get_collation_actual_version(dbform->datlocprovider, dbform->datlocprovider == COLLPROVIDER_ICU ? iculocale : collate); //通过get_collation_actual_version获得实际的version
...
		else if (strcmp(actual_versionstr, collversionstr) != 0) //对比db datcollversion和实际的version，不相等则抛出warning
			ereport(WARNING,
					(errmsg("database \"%s\" has a collation version mismatch",
							name),
					 errdetail("The database was created using collation version %s, "
							 "but the operating system provides version %s.",
							 collversionstr, actual_versionstr),
					 errhint("Rebuild all objects in this database that use the default collation and run "
							 "ALTER DATABASE %s REFRESH COLLATION VERSION, "
							 "or build PostgreSQL with the right library version.",
							 quote_identifier(name))));
	}
...
}

CheckMyDatabase函数会对比数据字典pg_database中的datcollversion和实际的version。

函数差异
#

在pg14及之前，对比collation的逻辑只有1个:会话首次缓存对应collation时，调用pg_newlocale_from_collation访问pg_collation数据字典中的对应的那个collation的version，对比真实的version
在PG15及以后，因为在pg_database表中新增了datcollversion字段，所以新增了一个检查db collation version的逻辑：会话首次访问pg_database中的db时，调用CheckMyDatabase检查pg_database中对应的那个db的datcollversion，对比真实的version

为什么仅refresh database后报错不多
#

refresh database collation version后，不会触发pg_database的coll version不一致的warning，但是也不能排除pg_collation的coll version不一致的情况。为什么仅refresh database后，报错就少量这么多，难道pg_collation的coll version就不会被加载了?

select c.coll,count(*) from (select unnest(indcollation) coll from pg_index ) c group by c.coll;
 coll | count 
------+-------
 950 | 37 --C
 0 | 2841 --不存在collation
 100 | 723 --default

真实环境中，用的最多的还是default，一般也没人去指定collation，没有指定就是default，default就是db的默认collation。

这里要回来再次关注pg_newlocale_from_collation函数。函数刚开头是这样的：

pg_locale_t
pg_newlocale_from_collation(Oid collid)
{
	collation_cache_entry *cache_entry;

	/* Callers must pass a valid OID */
	Assert(OidIsValid(collid));

	/* Return 0 for "default" collation, just in case caller forgets */
	if (collid == DEFAULT_COLLATION_OID)
		return (pg_locale_t) 0;
...

当collid==DEFAULT_COLLATION_OID==100时，直接return，不再执行下面的真实version的判断，也就不会抛出warning。这个逻辑是合理的，因为db coll version已经在登入db时校验过了，如果有问题，那么肯定已经在session层抛出过一次warning了。

另外，即便是传入可能的值collid=37，对应的C也没有version的说法。

所以，refresh database后，绝大部分场景下，只要是用数据库内部的排序（非表达式排序和指定索引排序），就不会抛出报错了。

测试
#

这里仅测试是否有refresh warning，不测试索引corrupt或者库跑崩。

#查看libc版本
getconf GNU_LIBC_VERSION

源主机版本 glibc 2.17
目标主机 glibc 2.28
pg版本 pg15+

测试：刷db不刷新pg_collation，仅db coll version改变
#

select datname,datlocprovider,datcollate,datctype,datcollversion from pg_database 
 datname | datlocprovider | datcollate | datctype | datcollversion 
------------+----------------+-------------+-------------+----------------
 lzldb | c | en_US.UTF-8 | en_US.UTF-8 | 2.17
 
select collname,collprovider,collversion,pg_collation_actual_version(oid) from pg_collation where collname ~ 'en_US.utf8';
 collname | collprovider | collversion | pg_collation_actual_version 
------------+--------------+-------------+-----------------------------
 en_US.utf8 | c | 2.17 | 2.28

alter database lzldb refresh collation version;
NOTICE: 00000: changing version from 2.17 to 2.28
LOCATION: AlterDatabaseRefreshColl, dbcommands.c:2399
ALTER DATABASE

再次查看pg_collation和pg_database

 collname | collprovider | collversion | pg_collation_actual_version 
------------+--------------+-------------+-----------------------------
 en_US.utf8 | c | 2.17 | 2.28

 datname | datlocprovider | datcollate | datctype | datcollversion 
------------+----------------+-------------+-------------+----------------
 lzldb | c | en_US.UTF-8 | en_US.UTF-8 | 2.28

跟官方文档的描述一致，refresh database collation version只是在刷db的默认collation，pg_collation本身是不会变的

测试：刷db不刷新pg_collation，指定表达式排序报warning
#

如开头分析，表达式排序会报warning，略

测试：刷db不刷新pg_collation，新建指定collation的索引报warning
#

测试1：建索引时指定collation

 collname | collversion | pg_collation_actual_version 
------------+-------------+-----------------------------
 zh_CN.utf8 | 2.17 | 2.28
 
 > create index idx11 on tt(a collate "zh_CN.utf8");
WARNING: 01000: collation "zh_CN.utf8" has version mismatch
DETAIL: The collation in the database was created using version 2.17, but the operating system provides version 2.28.
HINT: Rebuild all objects affected by this collation and run ALTER COLLATION pg_catalog."zh_CN.utf8" REFRESH VERSION, or build PostgreSQL with the right library version.
LOCATION: pg_newlocale_from_collation, pg_locale.c:1664
CREATE INDEX

测试2：建表时指定字段默认collation，建索引时不指定

\c lzldb --重连一个session
You are now connected to database "lzldb" as user "postgres".
create table ttt(a varchar(10) collate "zh_CN.utf8");
CREATE TABLE

> create index idxttt on ttt(a);
WARNING: 01000: collation "zh_CN.utf8" has version mismatch
DETAIL: The collation in the database was created using version 2.17, but the operating system provides version 2.28.
HINT: Rebuild all objects affected by this collation and run ALTER COLLATION pg_catalog."zh_CN.utf8" REFRESH VERSION, or build PostgreSQL with the right library version.
LOCATION: pg_newlocale_from_collation, pg_locale.c:1664
CREATE INDEX
Time: 7.904 ms

字段默认collation和建索引指定collation本质是一个东西，都是为了指定索引的collation。他们都可以报warning。

测试：刷db不刷新pg_collation，已建指定collation的索引不报warning
#

场景为原库已经有索引指定collation zh_CN.utf8，跟db的不一样，refresh db刷不到。但是到新库后vendor的coll version肯定是变了。

select collname,collprovider,collversion,pg_collation_actual_version(oid) from pg_collation where collname ~ 'zh_CN.utf8';
 collname | collprovider | collversion | pg_collation_actual_version 
------------+--------------+-------------+-----------------------------
 zh_CN.utf8 | c | 2.17 | 2.28

不用表达式排序的话，可以用到索引，但是不能使用索引排序

> set enable_seqscan =off;
SET
> EXPLAIN ANALYZE SELECT a FROM tt ORDER BY a LIMIT 1000;
 QUERY PLAN 
----------------------------------------------------------------------------------------------------------------------------------------
 Limit (cost=6667.80..6670.30 rows=1000 width=33) (actual time=44.928..45.145 rows=1000 loops=1)
 -> Sort (cost=6667.80..6892.81 rows=90004 width=33) (actual time=44.926..45.021 rows=1000 loops=1)
 Sort Key: a
 Sort Method: top-N heapsort Memory: 127kB
 -> Index Only Scan using idxtt on tt (cost=0.42..1732.98 rows=90004 width=33) (actual time=0.029..15.434 rows=90004 loops=1)
 Heap Fetches: 4

已建指定collation的索引，使用到的时候不报warning

这个问题的总结
#

refresh database和refresh collation的warning是session级。在每个会话中，对于每个db或每个collation只报一次。

仅refresh database，很有可能不会再报warning，但是存在创建指定collation索引、运行指定表达式collation SQL时报warning的情况。

数据字典中的coll version只是为了在db层追踪collation provider version是否发生改变。试想一下没有数据字典中的coll version，那么db可能都无法返回warning告知“你的排序规则提供商升级了版本，你的数据排序可能有问题，你需要检查一下了”（当然不止是排序）。

这个问题的解决方案
#

corrupt的索引已经重建过，db也refresh过，只是没有refresh collation。数据字典中的coll version不一致，问题不算太大，只是提示而已，至于还有其他什么隐秘又奇怪的坑，参考more章节。

这个问题的解决方案：

第一步：检查是否还有依赖

SELECT pg_describe_object(refclassid, refobjid, refobjsubid) AS "Collation",
 pg_describe_object(classid, objid, objsubid) AS "Object"
 FROM pg_depend d JOIN pg_collation c
 ON refclassid = 'pg_collation'::regclass AND refobjid = c.oid
 WHERE c.collversion <> pg_collation_actual_version(c.oid)
 ORDER BY 1, 2;

如果有返回，最好重建依赖的对象；没有的话遵循第二步：

方案一：不动。warning不多也可以不动
方案二：仅refresh collation zh_CN.UTF8。来一个解决一个
方案三：所有collation都refresh一遍。哪怕业务有增量使用表达式或索引指定collation，也不会报warning

more
#

glibc升级相关的精华总结
#

locale是一个非常坑的领域，glibc升级导致的collation的问题也非常多，参考ref资料，汇总一些比较重要的东西：

pg_collation是从OS命令locale -a取的；provider基本都是glibc，所以要看glibc的version。

在pg_collation中"C"和"posix"的collprovider都是c，看着跟“C.UTF8”等一样，其实不是的。“C.UTF8”的provider是glibc，有version，一般是unicode码点排序或unicode语义排序；“C"和“POSIX”是等价的，是POSIX 标准定义的最基础的locale，由libc实现，不在locale -a中，没有version，直接以字节序排序。

collation问题的根源：数据库要的是数据库生命周期内locale定义永远不变，但是OS提供商特别是GNU C library每个小版本都会对locale做出改动，而且这是合法的。

GNU C library每个小版本都会对locale做出改动，现实中最容易出问题的版本是glibc 2.28，因为2.28升级了大版本unicode 9.0.0(has been updated to a new upstream version from ISO which is in sync with Unicode 9.0.0)。

pg没有办法检测glibc升级带来的兼容性问题。索引损坏检查不是all check，同时索引也只是一方面。物理复制或upgrade后，即使重建索引，也不能排除因为collation version的问题，某天库跑崩了的情况。

数据异常包括：主键重复，依赖排序的约束，范围分区表数据写入错误分区，mergejoin等排序操作等等

字符类型依赖collation，不依赖collation的数据类型：

bytea
tsvector gin indexes
pg_trgm indexes
numeric data types: int, bigint, numeric, float, …
custom data types like geometry (PostGIS)
timestamp

ASCII排序比较常见但不符合人类理解，即不符合语义。符合语义的国际排序标准一般都是unicode标准。

基于unicode的排序规则也分了好2种：码点排序、UCA（Unicode Collation Algorithm）

UCA基于DUCET（Default Unicode Collation Element Table），DUCET表本身在不同版本间可能发生排序变化。举个栗子，en_US.UTF8是UCA排序，相当于语义排序，版本升级会改变排序规则。C.UTF8是码点排序，码点确认后不会改变，不会改变排序规则。

PG 17+提供了非常安全的locale提供方式：builtin，不再依赖OS提供的glibc、ICU等provider。启用命令例如

initdb --locale-provider=builtin --bultin-locale=C.UTF-8 dbname1

17仅支持C, C.UTF-8，C是字节序排序（约等于ASCII排序），C.UTF-8是unicode码点排序；18多一个PG_UNICODE_FAST ，也是unicode码点排序，跟C.UTF-8稍有区别。

因为数据库必须保持排序稳定不变，业务自定义排序只有推给业务层实现，例如表达式排序就是语义明确的，而且不影响数据库本身对collation的选择。如果哪天pg也支持build-in en_US.utf8的话，再考虑build-in的语义排序。

物理迁移后可以做什么
#

假设数据库是en_US.utf8，provider c，已经做了跨libc版本的物理迁移，应该做如下操作:

一、官方必修方案

1.至少要重建有问题的索引。安装amcheck插件，用bt_index_check函数

SELECT bt_index_check('idx1'::regclass, true);

2.refresh database version，(pg15+)

ALTER DATABASE name REFRESH COLLATION VERSION

3.检查有没有其他依赖的对象，有的话得看情况处理了

SELECT pg_describe_object(refclassid, refobjid, refobjsubid) AS "Collation",
 pg_describe_object(classid, objid, objsubid) AS "Object"
 FROM pg_depend d JOIN pg_collation c
 ON refclassid = 'pg_collation'::regclass AND refobjid = c.oid
 WHERE c.collversion <> pg_collation_actual_version(c.oid)
 ORDER BY 1, 2;

处理完以后，再

4.refresh collation version，(pg10+)

ALTER COLLATION name REFRESH VERSION

二、非官方邪修方案

我这没有做出完整的方案，只是一点思路。

1.处理分区表写入错误分区的问题

分区键是int/bigint/float，跟collation没有关系，可以不用管了

分区键是时间分区，如果是timestamp不用管了，如果是varchar等等字符类型，就看情况了

分区键是字符类型，参考“a”和“-”的排序（pgconf Collation Challenges Sorting It Out）。但要注意以下几点

如果要查数据的话，不要从父表查，可能会崩或者查不出来
没有简单的检测方案

2.处理主键/唯一键冲突

3.处理fdw排序范围异常的问题

4.未知问题

ref
#

https://wiki.postgresql.org/wiki/Locale_data_changes

https://wiki.postgresql.org/wiki/Collations

pgconf Collation Challenges Sorting It Out

PFCONF Collations from A to Z

http://www.unicode.org/reports/tr10/tr10-34.html

https://sourceware.org/glibc/wiki/Release/2.28

https://www.postgresql.org/docs/18/sql-altercollation.html

https://www.postgresql.org/docs/18/sql-alterdatabase.html

https://www.postgresql.org/docs/17/locale.html#LOCALE-PROVIDERS

CXL和PolarDB-CXL

Sun, 30 Nov 2025 00:00:00 +0000

论文：Unlocking the Potential of CXL for Disaggregated Memory in Cloud-Native Databases

SIGMOD best paper：https://sigmod.org/sigmod-awards/sigmod-best-paper-award/

CXL和PolarDB-CXL
#

CXL的概念
#

CXL：开放的行业标准，由 CXL 联盟 (2019 年由英特尔、AMD、ARM 等科技巨头创立) 制定的高速互连规范。它代表了计算架构的演进方向。目前刚演进到CXL 4.0

特性	CXL 1.0/1.1	CXL 2.0	CXL 3.0/3.1	CXL 4.0 (最新)
发布时间	2019 年 3 月 / 9 月	2020 年 10 月	2022 年 8 月 / 2023 年 11 月	2025 年 11 月
基础协议	PCIe 5.0 (32 GT/s)	PCIe 5.0 (32 GT/s)	PCIe 6.0 (64 GT/s)	PCIe 7.0 (128 GT/s)
最大带宽	1TB/s	1TB/s	2TB/s	4TB/s+
拓扑规模	点对点 / 简单星型	单交换机 (≤32 节点)	多级 Fabric (4096 节点)	超大规模 Fabric

据我搜索的资料中，摘取两个比较影响深刻的对CXL的描述：

内存即服务
近内存计算和扩展

CXL switch：是交换芯片，物理硬件。很多厂商在做工业化实现，论文中特指产商是XConn Tech的产品 CXL 2.0 switch。需要注意的是，截止2025年11月22日，XConn这家只有CXL 2.0 switch，没有3.0的产品，市面上是有支持3.0+标准的交换芯片的产品panmnesia CXL 3.2 Fabric Switch

polarCXLMem：据论文所说是“首个基于CXL-switch的分离式内存系统”。但是论文中提到“we leverage the world’s first CXL switch[50]”也就是特指Xconn tech CXL 2.0 switch，然后再提到“PolarCXLMem is the first CXL-switch-based disaggregated memory”。这句话可以理解为两种含义：

首个基于CXL switch的分离式内存系统
首个基于Xconn tech CXL 2.0 switch的分离式内存系统

polardb-cxl：其实论文中没有这个概念，但是行业在用这个词。这个词代表“integrate PolarCXLMem into the multi-primary version of PolarDB,known as PolarDB-MP”，相当于“PolarDB-MP的CXL升级版”。论文中反复使用这么长一段话，但是始终没有用polardb-cxl这个词。为了方便起见，本文中使用polardb-cxl这个词代表其本质含义。

RDMA vs CXL
#

PolarDB-MP用的是RDMA架构，PolarDB-CXL是CXL架构：

（https://medium.com/@anan.mirji/cxl-switch-vs-rdma-a-technical-comparison-for-high-performance-interconnects-6aaa031cde31）

RDMA架构是跨主机的分布式互联架构，CXL架构这是单主机的扩展互联架构。

核心差异

维度	RDMA 架构	CXL 架构
拓扑结构	多主机 + 网络交换机的分布式架构	单主机 + CXL 交换机的扩展架构
通信介质	网络（InfiniBand/RoCE）	PCIe 总线（CXL 基于 PCIe 物理层）
核心组件	RDMA NIC（专用网卡）	CXL Controller、CXL Switch
资源归属	跨独立主机的 “远程资源”	主机架构内的 “扩展资源”

CXL的优势
#

CXL相较于RDMA的优势：

低延迟：CXL通过PCIe连接主机或者设备上的内存；而RDMA 需要在InfiniBand与PCIe 之间进行协议接口转换

指令支持：CXL提供了原生的 load/store指令，使CPU能像访问本地内存一样直接操作远程CXL设备内存；而RDMA需要从远端内存读到本地内存，在本地处理后再回写到远端内存。

简化应用：RDMA需要特殊的接口和驱动，需要专业人员设计复杂的程序；而CXL提供透明的内存空间极大简化应用设计

内存融合：CXL 3.0支持物理硬件级内存融合

polardb-mp存在的问题和CXL能提供的价值：

CXL说MP的问题：

内存页是4-16K的，就算只需要很少的数据传输，也必须在本地内存和共享内存间传输数据，这导致了读写放大。
维护本地内存需要额外的内存开销，这降低了吞吐
恢复非常花时间
RDMA远好于TCP/IP，但在高并发下有 “门铃寄存器隐式竞争” 和 “缓存颠簸”问题
数据库本身要维护共享内存

CXL带来的好处：

消除“共享内存-本地内存”的层级内存结构，也消除了层级结构的维护消耗和读写放大问题。因为CXL load/store本地内存足够快，所以允许直接store所有的buffer pages
以缓存行（64B）为最小CPU缓存和主存的传输单位，而不是polardb-MP的4K
节约主存。主存（DRAM）的成本非常高，大约占服务器/机架成本的40-50%
简化系统设计。在现有系统上最小化改造，对于商业数据库的稳定性来说很重要。
PolarRecv：基于CXL做的立即恢复的系统。在数据库crash后，data和metadata都还在CXL上，可以直接在CXL memory上读到一致性状态，所以恢复非常快。（这看起来跟pg的page cache缓存可以帮助crash后快速启动有类似处）

DRAM vs RDMA vs CXL：

在数据量较少时，RDMA比CXL延迟高不少，数据大一点RDMA的延迟就稍微好点。本地访问内存DRAM要略好于通过CXL访问。

总体来说，CXL内存访问的延迟略高于DRAM但好于RDMA。

对于CXL延迟高于DRAM，论文这样解释“database buffer pool operations are more sensitive to bandwidth than latency”，对于数据库内存来说，带宽比延迟重要。

自研机架
#

自研的物理原型机架。左边的机架集成了两个支持 CXL 交换机的集群，每个集群均连接至内存设备与主机；右边的机架集成了1个CXL 交换机，连接至内存设备和主机。

PolarCXLMem
#

CXL 2.0 switch支持内存池但驱动没有完全支持，所以PolarCXLMem还是设计了CXL的内存分配和使用，不是完全透明的。PolarCXLMem经过一些处理，将CXL memory分成了多租户的模式，不同的主机节点分配不同的CXL内存区域。

PolarCXLMem的特点：

节点有各自的CXL内存区域，不同的节点不会交叠CXL内存
buffer pool仍在数据库启动后就分配（由上图中的CXL mem manager分配），运行状态不会改变内存分配区
cxl mem中的内存单位结构是block，block会存储page的数据和page的元数据，这些元数据包括：id代表页id，lock state代表页是否有被update锁定，prev/next是LRU双链，lsn为page的最新日志序列号。
free list/in-use list用来做LRU的

疑问：pg的pageheader有lsn、起始空闲空间指针、prune xid等等，polardb-cxl的页头又是什么结构呢？

PolarRecv
#

PolarDB-MP是基于RDMA设计的，数据页在本地写入即可，分离式共享内存中没有最新版本的数据页。这导致主机crash后需要扫描和应用所有redo log文件（论文中说是redo不是wal）或一点点共享内存中的页。

而CXL switch有独立的电源，即便主机宕机，最新的数据还在CXL内存中。所以PolarRecv利用这一点来极大的提高主机宕机后数据库的恢复速度。

但是，虽然CXL switch内存透明又持久，crash后直接使用还是需要处理以下问题：

LRU list可能在crash时是不一致的
B-tree SMO（B-tree结构变化），例如索引分裂时，可能在crash时是不一致的
页在更新时crash，可能是不一致的
redo log buffer用的本地DRAM，当redolog还没有刷盘时crash，CXL中的buffer pool中的page lsn可能大于redolog文件中的lsn，这直接违反了ARIES原则

PolarRecv设计的对应策略：

用mutex来保护LRU结构，mutex锁的状态代表LRU是否在crash时被修改，如果是的话，LRU需要重建，如果不是则直接使用CXL内存中的LRU。
B-tree SMO时会有一个mini-tranaction保护索引页，这个mini-tranaction是对应于page锁的两阶段锁。当mini-transaction提交时才会flush到redolog。所以在恢复过程中发现索引页有写锁，从redologs中恢复。
polarcxl的读写锁是放在cxl内存中的。如果写锁还在，说明crash时update在中间状态没有完成。此时老实从redolog文件中读取page而不是在cxl内存中读取不一致的page。
recovering过程中，首先会拿到redolog中最大LSN，然后检查CXL内存中page的锁和LSN，如果cxl内存中page的LSN大于最大LSN，那就用redolog中的信息去重建page而不是用CXL内存中版本。

内存融合
#

因为PolarCXLMem是基于CXL 2.0 switch设计的，CXL 3.0才支持内存融合，所以还是要做内存融合的设计。因为每个节点的buffer pool都是隔离式地放在PolarCXLMem中，CXL 2.0的内存融合通过对DBP的元数据管理来实现，每个buffer pool都只存页的CXL内存地址而不是页本身。

看懂上图需要注意区分CXL memory，dbp和本地buffer ：

CXL memory是物理硬件，CXL mem本身
dbp是CXL中开辟出来的区域用于管理内存融合服务
本地 metadata buffer包含了本地buffer的元数据和CXL的部分

另外还需要了解，对于每个buffer pool中的page都有两个标志：

invalid：其他节点写入页后，当前节点需要invalidate本地cpu cache
removal：page从in-use list转移到free list，所有节点都要设置removal标志

内存融合page的访问流程：

1.请求的页不在本地page metadata buffer中，

1.1 从freelist中分配新的meta record，并通过rpc给内存融合服务提供invalid、removal地址

请求的页在本地page metadata buffer中，

2.1先检查removal flag，若removal被设置，代表内存融合服务已经回收了该page，需要通过RPC请求内存融合服务的新内存地址

2.2然后检查invalid flag，invalid flag被设置，代表页被其他节点修改，需要invalidate cpu cache以确保一致性

融合一致性：

因为CXL 2.0没有内存融合，cpu cache不会被自动更新。polarcxl通过页级锁来实现多节点并发写入控制。

节点读写page需要拿到读写锁。当一个节点正在写入page时，其他节点不能获得读写该page。当节点写完后，还需要

当前节点将cpu cache lflush到CXL mem中，以确保CXL mem是最新版本的page
设置invalid flag，以确保其他节点不去读其cpu cache的老版本page

内存融合小节：

CXL 2.0本身支持不太完整的内存融合，导致数据库层还是需要设计内存融合方案。内存页通过CXL地址访问，而不是像RDMA方案一样本地/远程访问整个page。本地CPU cache需要数据库层来刷新以确保节点访问数据的一致性，这是硬性限制。这也导致了跨节点更新仍然是排他页级锁（RDMA方案也是排他页级锁）。

性能评估
#

多节点读写
#

一个192 vC的主机上放12个实例进行的压测，对比RDMA（PolarDB-MP）和CXL（PolarDB-MP with PolarCXLMem）的性能：

点查：

范围查询：

读写：

点查：点查的读放大问题最严重，CXL的带宽消耗比RDMA小3-4倍。当节点达到3个时，RDMA的带宽已经被占满，再增加节点不会有任何带宽上的提升。
范围查询：范围查询的读放大问题没有那么严重，只是在节点大于4时达到带宽上限11GB/s，而CXL还可以随节点线性增长。
读写：表现与范围查询类似，只是差异再小一点

PolarRecv恢复时效
#

vanilla指一般方案，应该是指类似pg从本地cache或disk中读取（也有可能是polar redo）
RDMA-based指polardb-mp有些数据可以从分离式共享存储中读取
PolarRecv指从大部分数据从CXL中继续读，少部分patial page需要从redo文件中恢复

论文中论述恢复时效其实分为2个阶段：起库/recovery和负载达到crash前的水平。只读不需要recovery，只要有数据就能起库承接负载。当有写入时，就需要做恢复，此时继续从CXL内存读数的优势就体现出来了。1分钟、2分钟、4分钟的恢复时效，还是有差距的，差距可能就是业务几乎无感和有感的区别。

共享数据更新
#

分布式数据库性能PK的焦点就是对共享数据的更新。在Polardb-mp性能暴打taurus-mm后，Polardb-cxl也暴打了Polardb-mp：

0%的 shared data的情况下，RDMA-based就访问local buffer就行了，Polardb-CXL只是把CXL当成内存池使用。即便如此，CXL-based还是性能更好，主要是之前说的，RDMA-based方案有读写放大和带宽上限问题。

从上的性对比图可以看出来Polardb-CXL明显好于Polardb-MP，数据是非常清晰的。但是要注意，当shared data>60%时，Polardb-CXL性能提升不明显了，主要原因如下：

页级锁成为瓶颈
随着锁竞争加剧，进程会进入sleep状态，频繁的上下文切换也加剧了资源争用

总结
#

PolarDB-CXL优点：

消灭了RDMA的“本地-远程”层级内结构设计
解决了RDMA的读写放大问题
提供基于CXL的内存池
PolarRecv基于CXL持久内存，数据库崩溃恢复速度更快
压测显示polardb-mp cxl性能优于polardb-MP RDMA

PolarDB-CXL缺点：

跨节点更新仍然是页级锁，在共享数据更新的场景下，仍是性能瓶颈的主因
CXL 2.0 switch看起来有点老了，在论文发表的时候已经有支持3.2的交换设备了，在2025年11月也发布CXL 4.0标准。可以预测未来应该有基于更新CXL标准的交换设备的数据库出现。
论文质量其实没有MP这篇高，主要是围绕CXL 2.0 switch物理硬件做的解决方案，跟PoalrDB-MP论文中有大量的数据库层面的设计还是有区别的

简评ORACLE,MYSQL,PG的逻辑复制

Sun, 30 Nov 2025 00:00:00 +0000

postgresql逻辑复制
#

（https://www.pgconf.asia/JA/2017/wp-content/uploads/sites/2/2017/12/D2-A7-EN.pdf）

PostgreSQL把所有逻辑解析相关的事情全部放在数据库中的复制槽进行管理，大包大揽。早期版本的逻辑复制支持的还不太好，近期的几个大版本中，逻辑复制是主要的功能提升之一。 PG方案的优势：

非常灵活，把逻辑解码接口提供给用户，有多种类的解析方式
用户可根据需求订阅所需要的数据

PG方案的劣势：

知识点多学习成本相对MYSQL要高很多。仅仅是基础知识点：发布、订阅、walsender、复制槽、output plugin等等，我相信很多人没有弄明白他们概念和关系
干最累的活挨最毒的打。逻辑解析的问题全部暴露在数据库中，wal积压、大事物、长事务、reorder事务排序、权限问题、流式传输等等都是PG要考虑的问题

mysql的binlog
#

(https://blog.fasterinfo.top/6243.html)

mysql把所有解析出来的逻辑数据放在本地——binlog文件中，方案简单。mysql的binlog约等于PostgreSQL开启全表逻辑复制并写入本地。 MYSQL方案的优势：

简单粗暴，mysql不把逻辑解码接口直接暴露给用户，而是把已解析出来的文件直接给到用户，用户不需要关心怎么解析的，直接读binlog文件即可
生态成熟。个人认为mysql生态成熟跟binlog有较大关系，在互联网时代PG的逻辑复制还很弱，而binlog十分简单，下游解析binlog把数据放到其他平台已成为一种常见方案

MYSQL方案的劣势：

数据必须全部解析，不可定制化订阅数据，灵活性差
两阶段提交。由于mysql主从强依赖binlog，又导致binlog数据在提交的时候必须全部落盘到binlog file，一次提交必须写两份（或者两种）日志——binlog和redolog，日志双写是mysql永恒的痛点之一。

oracle的逻辑复制
#

（https://www.oracle-scn.com/oracle-goldengate-integrated-capture/）

oracle本身是有逻辑DG的功能的，但基本上没见有人用过，这里只聊logminer 。oracle数据库本身提供了logminer这样的接口来解析日志（如OGG集成模式），逻辑复制链路管理本身完全没有，依赖第三方工具来创建和管理复制链路 ORACLE方案的优势：

只提供解析接口，没有复制链路管理，对于数据库本身来说非常省心
充值就有方案。把强大的OGG直接买下来，不要说我ORACLE没有提供逻辑复制解决方案，我们不仅有，而且很强大、认可度高。

ORACLE方案的劣势：

依赖第三方软件管理复制链路

总之，PG的逻辑复制是大包大揽什么都做，非常有开源精神、技术精神。MYSQL的方案简单粗暴但好用，有点“一步到位”的意思。ORACLE属于给个接口后就什么都不管，全部给第三方管理，但对于客户来说是有成熟的解决方案的。

论文精读|PolarDB-MP|2024 SIGMOD最佳工业论文

Sun, 30 Nov 2025 00:00:00 +0000

论文：PolarDB-MP: A Multi-Primary Cloud-Native Database via Disaggregated Shared Memory

SIGMOD best paper：https://sigmod.org/sigmod-awards/sigmod-best-paper-award/

前言和摘要
#

开篇提出问题：主从库的写入吞吐受主库限制。shared-nothing架构是可扩展的多主集群，可以解决单主受限问题，但是该架构因分布式事务的开销而出现性能瓶颈。最近基于共享存储的云原生多主数据库出现，但该架构在高冲突场景下，有冲突解决代价高和数据融合效率低的问题。

所以，提出的问题的是：单主主从架构、shared-nothing架构、共享存储云原生多主架构，都有各自的问题。

本篇论文提议PolarDB-MP，它是结合了分离式共享内存与共享存储的新型多主云原生数据库。（an innovative multi-primary cloud-native database ，多主云原生数据库已经有了，所以得是新型）。

PolarDB-MP的基本特点：

所有节点都能平等访问全部数据，从而使事务能够在单个节点上独立处理，无需使用传统的分布式事务机制。
共享存储：PolarStore and PolarFS，或者其他兼容性共享存储方案
构建在分离式共享内存之上
通过RDMA远程直接内存访问实现低延迟通信
LLSN（局部逻辑序列号，Local Logical Sequence Number）。用于为不同节点生成的预写日志建立部分有序关系（partial order）**，**并配合定制化恢复策略，确保系统在异常恢复时的一致性与高效性。
核心组件PMFS（Polar Multi-Primary Fusion Server多主融合服务器）负责：
- Transaction Fusion（事务融合）——负责事务排序与可见性管理
- Buffer Fusion（缓冲区融合） —— 提供分布式共享缓冲机制
- Lock Fusion（锁融合）—— 用于跨节点并发控制

分类
#

分类主要是为了看清polardb-mp的历史位置，也是为了理解”第一的定语“:

PolarDB-MP is the first multi-primary cloud-native database that utilizes disaggregated shared memory and shared storage for transaction coordination and buffer fusion

竞品黑点
#

shared-nothing产品：对于这类产品没有一个个提黑点，只是一句话带过：事务在跨多分区访问时，分布式事物需要显著的额外开销。

oracle：

昂贵的分布式锁管理
昂贵的网络开销
比较依赖精致的机器（alien tech）
难以上云，或者上云后比云原生数据库的TCO成本（包含维护、人力成本）更高

AWS Aurora-MM：

采用乐观事物模型，事务冲突时有较高的事物中止率
某些场景下，4节点吞吐低于单节点

华为 Taurus-MM：

悲观事物模型。依赖页存储和日志重放来保证缓存一致性，在并发控制和数据同步方面存在较高的开销。
50% shared data 读写场景下，8节点只有1.5倍的单节点性能提升

oracle这里的黑点主要是看着有道理的口嗨，Aurora-MM和Taurus-MM是有原厂商引述的：

Aurora-MM “某些场景下，4节点吞吐低于单节点”
Taurus-MM “50% shared data 读写场景下，8节点只有1.5倍的单节点性能提升”

事务融合
#

事务融合概述
#

多主如何保证一致性数据视图？

快照隔离是常见的MVCC实现方式。快照隔离有一个特性是，查询或者事务必须在执行期间保持自己的一致性数据视图（consistent data view）。但是在多主架构中，因为远端的数据更新，本地无法保证一致性数据视图。

为了解决这个问题，一般的多主共享存储架构，会引入全局事务的机制（AuroraMM or Taurus-MM）。而在PolarDB-MP中提出了创新技术–PMFS中的事务融合技术。每个节点只维护本地事务信息，通过RDMA被其他节点访问。与全局事务相反，事务融合是去中心化的。

本地事物和TIT表
#

polardb-mp的每个节点都会有一小部分内存来存储本地的事务信息（可以被其他节点通过RDMA访问）。这些本地事务信息存储在transaction Information Table (TIT)中。

TIT表的内容：

事务对象指针
由全局时间戳协调器(TSO)分配的事务提交时间戳CTS（commit timestamp）
version，代表同一slot中的不同事务（事务对象指针不是指向一个事务？？？）
ref，标识这个事物是否被其他事物等待释放锁（应该是Plock或者Rlock）

事务是如何进行的
#

当事务开始时，本地事务id(应该就是txid了）会被分配，TIT slot会存放这个事务对象指针、ref初始化为0、CTS初始化为CSN_INIT。

Polardb-mp用全局事务ID标识一个事务，全局事务ID=（node_id, trx_id, slot_id, version）。全局事务ID是不包含CTS的，如果要知道事务的提交顺序，比如构建事务可见性视图时，就需要通过全局事物ID，经过RDMA，去目标节点找到CTS（类似pg中的pg_xact_commit_timestamp()函数通过事务id从本地文件找到对应的事务提交时间）。

如果trx_id是pg中事务ID的话，那么node_id,trx_id就可以标识事务的全局唯一性了，或者node_id,slot_id,version在某种程度上也可以（未复用slot id的情况下，比如某个时刻可以标识唯一事物id），当然多出来的信息组合起来也唯一。毕竟这些信息是polardb-mp实现事务融合的关键。

每个事务都会通过全局事务ID和CTS来构造可见性视图。可见性视图的概念跟pg是一致的，当前read view可读read view前已提交事务的数据行，且为最新版本行。

访问远端的CTS
#

因为CTS在本地（TIT or本地文件系统上）的缘故，所以获得读取事务的CTS是一个有意思活：

1.1 如果一个行的CTS是CSN_INIT/CTS_INIT，即事务仍然活跃，那么返回最大CTS表示其对所有事务不可见，除了自己。

1.如果一个行的CTS不是CSN_INIT/CTS_INIT，即事务已提交，且在本地的TIT中，那么直接返回CTS

2.如果一个行没有CTS，通过行的g_trx_id获取CTS

2.1 如果事务属于本地节点（ g_trx_id有node id），那么从本地文件系统读到本地TIT

2.2 如果事务不属于本地节点，那么从远端文件系统读到远端TIT，通过RDMA去访问

3.1 如果slot.version != g_trx_id.version，那么事务一定提交了，那么该行一定被所有事务可见（准确来说应该是一定被当前及以后的read view可见，但是理论上TIT slot不会把活动事务访问的row给刷下去，所以是所有事务可见），返回最小CTS表示其对所有事务可见

3.2 如果slot.version = g_trx_id.version，参考1.1、1.2

polardb-mp的事务可见性理念跟pg很相似，只是pg用的是txid而不是CTS表示事务新旧，也不需要考虑远程访问。

行更新事务
#

除此之外，行更新也很像：

polardb-mp更新行的时候，除了更新数据本身，还需要：

更新行的全局事务ID（g_trx_id）（如果是行上更新，那么就改造了pg的行头）
更新行的CTS。（这里没有说是行头还是文件系统，如果类似pg，那么应该是文件系统上的commit_ts目录上。polar未证实）

提问事务融合（没看懂的）
#

g_trx_id是行的元数据，写入磁盘的。如果节点减加，需要更新数据行g_trx_id中的node_id吗？如果不需要，下次读取出来应该加载到哪个节点？

一个新行的CTS存储在本地节点A，如果一个其他节点B又更新了这个行，新的CTS在A还是B节点？

assigned a read view, which consists of its own g_trx_id and the current CTS。只读事务在构建读视图时，也会分配g_trx_id吗？

毫无疑问，类似track_commit_timestamp参数一定是强制打开的

如果有大量的写在A节点，读在B节点，B节点的读会通过RDMA访问A节点的TIT对应的数据，是不是会产生大量的网络IO？那么是不是需要在考虑读写分离时，或者多节点写入和读取时，应该考虑这个问题？不知道原文能不能回答这个问题–“多主架构天生就需要在节点间同步大量的数据和消息，以支撑关联多节点的并发访问。随着网络技术的发展（InfiniBand，RDMA）和商业化落地，网络瓶颈变得不那么重要。”

全局时间戳可能成为分布式系统的瓶颈，PolarDB-SCC是基于共享存储的时间戳，看上去性能不错。时间有限，先按下再说。

内存融合
#

内存融合引述
#

polardb-mp的每个节点都可以更新任何数据页，这会导致大量的数据转移。Buffer Fusion’s distributed buffer pool (DBP)就是为了解决这个问题。每个节点都有本地内存池LBP，属于DBP的子集。

内存融合是如何进行的
#

LBP有两个新的东西用以存放页的元数据：

valid：是否被其他节点更新
r_addr：指针，指向DBP上的page

从LBP访问page时，当前节点需要先检查page是否是有效的，如果无效，需要通过r_addr去访问dbp。当dbp中存放page的新的版本后，内存融合会让所有远端的page失效。在LBP中，脏page会在后台周期性地或释放Plock锁后刷到DBP中。

page访问的步骤：

1.1 如果page在LBP且valid，直接访问。

1.2 如果page在LBP且invalid，经过RDMA访问DBP

2 如果page既不在LBP也不在DBP，从共享存储读取

3 page从一个node加载到LBP，并注册到DBP中

PolarDB内存融合的关键组件是分离式共享内存。看上去是一个/组物理硬件或者其上集成后的完整组件，游离于计算节点之外。这部分跟传统分布式系统的内存有很大的不同。

跟事务融合也有不同，事务融合需要访问相同架构的远端节点，内存融合不需要访问相同架构的远端节点，而是单独访问分离式共享存储这个组件。

提问内存融合（没看懂的）
#

分离式共享内存像游离于标准主机之外的组件，所以它到底是个什么玩意儿？

锁融合
#

锁融合中锁的类型
#

内存融合是为了解决节点怎么访问远端数据，锁融合是为了解决并发访问控制。

内存融合有两种锁：

page-locking (PLock)：类似latch，控制原子访问和内部结构一致性。单节点page访问没有Plock。
row-locking (RLock)：负责跨节点的事务控制，遵循两阶段锁协议

PLock访问流程
#

（论文没有说锁融合发生在哪，因为Plock是页上的栓锁，页的融合发生在共享内存上，所以我先假设锁融合也发生在共享内存上，因为这样容易理解一点）

1 在更新/读取page前，通过本地锁管理器检查本地节点是已持有对应的X/S Plock（或更高级别的锁）

1.1如果有，原地执行操作

1.2 如果没有，通过Lock fusion拿到PLock

2 锁融合在响应前先检查冲突，如果冲突存在则请求等待

3 当PLock被一个节点释放，会通知锁融合，锁融合更新Plock的状态，并通知其他节点继续执行自己的操作

Plock lazy releasing
#

根据上面PLock访问流程，一个Plock在本地执行完操作后会被立即释放。这可能不是最优解，根据时间局部性原理——“一个数据或指令在某一时刻被访问，那么在短期内，它很可能会被再次访问”。lazy releasing就是为了最小化Plock锁的RPC访问负载。

原理很简单，Plock在本地节点使用后不会被立即释放，而是等ref为0时才释放。

当其他节点需要PLock时，锁融合还会发送谈判信息干预本地节点一直持有锁，本地必须与锁融合通信而不是自主处理PLock。锁融合采用“先进先出”的策略解决跨节点锁归属权问题，同样直到本地节点的ref=0时，其他节点才可以拿到锁。

lazy releasing是有效的分布式锁解决方案，为了平衡本地锁优化和全局锁分配。

RLock概述
#

RLock是通过全局事务ID来判断的（跟pg类似）。根据事务融合的内容，全局事务ID包含了节点id、事务id、slot id、version。所以，本地节点读取行时直接就可以拿到行上所需要的锁信息，知道锁在哪（node id），知道锁是否活跃。

判断事务活跃也有2个好玩的点：

从事务融合访问远端的CTS的流程来看，事物的CTS是有效值或事物在TIT中属于同一slot但不是同一version，说明事物肯定提交了，所以不需要再检查是否活跃。源事务不活跃当然就不等待锁，直接运行。
pg中会有最小活跃事物ID的概念，在polardb-mp中也存在。如果行上的事务ID小于全局的最小活跃事务ID，那么源事务肯定也提交（或回滚）了。

Rlock是如何进行的
#

本地行本地处理即可，只有冲突的时候会在锁融合中处理，跨节点行锁才需要RLock。”The transaction ID in the row functions as a lock indicator. So this protocol only supports exclusive (X) lock. The shared (S) lock on a row is not supported in PolarDB-MP, but it’s acceptable“ ，真冲突的排他锁才需要RLock，共享锁不需要RLock。

1 T30从共享存储中读取行，从行的元数据（g_trx_id)就可以知道事物活跃且事务在哪个节点

2 T30远程调整T10的事物ref

3 T30发送等待状态给锁融合服务

4 锁融合添加等待信息到wait info table中

5 T10执行结束，通知Lock Fusion

6 Lock Fusion检查wait info table，然后通知T30可以继续执行了

提问锁融合（没看懂的）
#

“when attempting to update a row, it must already hold an X PLock lock on the page containing the row”

update还要持有page的PLock排他锁，也就是说同一page上的update是相互阻塞的，这会影响并发吧？本地应该不会有这种行为，pg是没有update场景的page排他的。

在Logs ordering and recovery章节有这么两句话：“Thanks to the PLock design, only one transaction can update a page at a time"，“When a page is updated across two nodes, one node pushes its updated page to the DBP before releasing the PLock,allowing the next node to retrieve it from the DBP.”

是的，在跨节点数据更新时，有页级排他锁。

PMFS小结（锐评）
#

PMFS（Polar Multi-Primary Fusion Server）是PolarDB-MP多主分布式系统实现的核心组件。其中，全局事务ID设计巧妙，它转化了pg的事务ID为包含节点信息、事务id和事务融合中的slot和version信息并放在行头。这样做有几个好处：

直接访问行就知道行的版本新旧情况
直接访问行就知道行是哪个节点更新的
直接访问行就知道是否可能存在跨节点锁
利用最小活动事务以减少冲突判断
利用全局事务ID信息，实现分布式获取事务提交时间CTS

另外

PMFS中的内存融合和锁融合看上去高度依赖共享内存组件
RDMA的应用时刻存在

日志的顺序
#

partial order
#

首先，wal在每个节点上都生成，且不需要任何并发控制机制，各自往共享存储中写。每个节点的LSN对于各自的节点而言是顺序的，但是多节点就不能体现wal记录在全局的顺序性。

但是，需要在写入时体现wal记录的全局顺序吗？

从论文来看，大部分情况是不需要的。

只有1种情况需要保证写入时的全局顺序性，那就是跨节点更新同一个page时。

但是，根据PMFS锁融合机制，跨节点更新同一page是排他的。锁融合就可以保证跨节点page更新的顺序了。

恢复的顺序
#

由于跨节点写入的LLSN来自多个节点很可能不是顺序的，恢复时就需要按顺序进行恢复。全量读取wal记录再按LLSN排序是一个简单的方案，但是大量的排序非常消耗资源。

polardb-mp提出了分段排序LLSN，每段称为chunk，chunk的边界称为LLSN bound。polardb-mp可保证LLSN bound一定小于下一个bound，然后在chunk内排序LLSN即可。

提问日志的顺序（没看懂的）
#

”utilizing redo (write-ahead) logs for data recovery and undo logs for rolling back uncommitted changes“

polardb-mp有undo日志文件？这个undo是干嘛的？

LLSN没有看出来有什么特别的，论文也没有详细说明它的结构，LSN看上去都够了，maybe全局事务id那有些区别。

评估
#

只读都是本地的，所以加节点吞吐提升是线性的。如果读写/只写的数据都分区得好，不跨节点，也几乎是线性的。

问题就在于读写/只写节点间共享数据的情况，非常考验分布式数据库的性能。

论文直接拿华为的taurus-mm来对比。结论就是：polardb跨多节点写数据性能确实要好不少。

吹毛索疵
#

文章有2个地方提到Taurus-MM在8节点共享数据下的性能提升，但是数据有歧义：

The eight-node cluster only improves the throughput by 1.8× compared to the single-node version in the read-write workload with 50% shared data.

the throughput of Taurus-MM ’s eight-node cluster is approximately 1.8× that of a single node under the SysBench write-only workload with 30% shared data, illustrating the trade-offs and challenges in optimizing multi-primary cloud databases

一会30% shared data，一会50% shared data，不是很严谨。原文Taurus MM是50%：

总结
#

好像没什么好总结的，看章节前言和摘要和PMFS小结 就行。

案例-从distinct不准确到DISTINCT的计算原理

Sun, 19 Oct 2025 00:00:00 +0000

问题现象
#

统计信息的n_distinct不准确

这个问题在多个库中出现，例如：

表有2亿行数据，真实DISTINCT有800w，统计信息中的DISTINCT只有4w。

问题分析
#

采样模型
#

默认default_statistics_target=100，即采集30000 pages中的30000行数据。

analyze verbose tablzl1;
INFO: 00000: analyzing "public.tablzl1"
LOCATION: do_analyze_rel, analyze.c:332
INFO: 00000: "tablzl1": scanned 30000 of 22963751 pages, containing 1061942 live rows and 3953 dead rows; 30000 rows in sample, 812872389 estimated total rows
LOCATION: acquire_sample_rows, analyze.c:1340

注意 “scanned 30000” 和 “30000 rows in sample”

distinct预估算法
#

distinct的预估算法analyze.c:

			/*----------
			 * Estimate the number of distinct values using the estimator
			 * proposed by Haas and Stokes in IBM Research Report RJ 10025:
			 *		n*d / (n - f1 + f1*n/N)
			 * where f1 is the number of distinct values that occurred
			 * exactly once in our sample of n rows (from a total of N),
			 * and d is the total number of distinct values in the sample.
			 * This is their Duj1 estimator; the other estimators they
			 * recommend are considerably more complex, and are numerically
			 * very unstable when n is much smaller than N.
			 *
			 * In this calculation, we consider only non-nulls. We used to
			 * include rows with null values in the n and N counts, but that
			 * leads to inaccurate answers in columns with many nulls, and
			 * it's intuitively bogus anyway considering the desired result is
			 * the number of distinct non-null values.
			 *
			 * We assume (not very reliably!) that all the multiply-occurring
			 * values are reflected in the final track[] list, and the other
			 * nonnull values all appeared but once. (XXX this usually
			 * results in a drastic overestimate of ndistinct. Can we do
			 * any better?)
			 *----------
			 */
			int			f1 = nonnull_cnt - summultiple;
			int			d = f1 + nmultiple;
			double		n = samplerows - null_cnt;
			double		N = totalrows * (1.0 - stats->stanullfrac);
			double		stadistinct;

n*d / (n - f1 + f1*n/N)

n = 样本行数（扫描的行数）
d = 样本中发现的distinct值的数量
f1 = 样本中只出现一次值的数量
N = 表的总行数

算法论文：https://hugepdf.com/download/download-extended-version-of-this-paper_pdf

论文看起来比较费劲，下面做一些假设来理解这个disticnt算法：

1.假设全是出现一次值，且表很大n«N，即f1=d，n/N=0

d*d / (d - d + d*0)=d*2/0，这应该是-1了.

2.假设全是出现一次值，且表很小n=N，即f1=d，n/N=1

n*d / (n - d + d*1)=d，即采集的distinct数，也等于采集的行数

3.假设采集样本中没有只出现一次值，即f1=0，

n*d / (n - f1 + f1*n/N)=n*d / (n)=n*d / (n)=d ，也就是采样中的distinct数.

如果一个列均是插入几条同样的值，然后再插入几条同样的值，比如：

11,2,2,2,2,3,3,3,..

3.1且表小，3w行采集全部采完，真实distinct=10000（假设），预估distinct=d=10000

3.2且表大，采样中有重复出现的值，也有出现一次值（因为某个重复数据只采到一条），即n=30000,n/N=0，

n*d / (n - f1 + f1*n/N)=n*d / (n - f1)=30000*d/(30000-f1)，也就是采样中的distinct数越大，预估的distinct越大；采样只出现一次值数越大，预估的distinct越大

总结：

distinct预估跟采样中的distinct数、只出现一次值数直接相关
如果只出现一次值数=0，那么采样越多，预估的distinct越大

验证
#

由于默认采样数最大是3w行，也就是说这种采样算法只要超过3w，即表比较大的时候，预估distinct很可能偏小。注意这里的数据不能有太多唯一值。

测试一张表不同采样数的差异：

表有reltuples=8亿，relpages=2kw，size=175GB，真实的某字段distinct 1亿

target statistics	pages采样比例（1）	tuples采样比例（1）	n_distinct	执行时间
50	0.00075	0.00001875	6w	2秒
100	0.0015	0.0000375	11w	5秒
1000	0.015	0.000375	103w	58秒
3000	0.045	0.001125	268w	3分01秒
10000	0.15	0.00375	675w	7分21秒

（target statistics 最大值10000）

可以粗糙的总结：n_distinct和analyze的执行时间随采样数量成倍增长。

n_distinct随采样数量增长，pages和tuples却一直都很准确。

解决
#

由于表特别大，可以考虑改造分区表或根据实际SQL进行优化

还可以调整收集阈值，默认阈值default_statistics_target=100，即3w个pages中的3w条数据。

临时方案：

set default_statistics_target=3000;
analyze tab1;

长期方案：

alter table tab1 alter column col1 set STATISTICS 3000;

注意：

列的收集阈值优先级最高，大于default_statistics_target参数
收集阈值最大为10000
表的收集阈值为最大的列阈值：

	/*
	 * Determine how many rows we need to sample, using the worst case from
	 * all analyzable columns. We use a lower bound of 100 rows to avoid
	 * possible overflow in Vitter's algorithm. (Note: that will also be the
	 * target in the corner case where there are no analyzable columns.)
	 */
	targrows = 100;
	for (i = 0; i < attr_cnt; i++)
	{
		if (targrows < vacattrstats[i]->minrows)
			targrows = vacattrstats[i]->minrows;
	}
	for (ind = 0; ind < nindexes; ind++)
	{
		AnlIndexData *thisdata = &indexdata[ind];

		for (i = 0; i < thisdata->attr_cnt; i++)
		{
			if (targrows < thisdata->vacattrstats[i]->minrows)
				targrows = thisdata->vacattrstats[i]->minrows;
		}
	}

如果执行analyze发现收集多了或者少了，可以看下pg_statistic是不是有设置字段stattarget

select attrelid::regclass,attname,attstattarget from pg_attribute where attrelid = 'tab1'::regclass and attstattarget not in (-1,0);

总结
#

对于大表，字段非唯一但distinct值比较高（符合真实场景），采样算法会低估distinct值，且跟采样比例正相关。默认的采样比例对于大表来说偏小，可以调大，但是最大也大不到哪去。

案例-添加索引性能下降和generic plan

Sat, 13 Sep 2025 00:00:00 +0000

问题现象
#

前晚添加索引，第二天早上cpu打爆，sql容易定位，问题sql就1条。该sql跑了30多s，但是昨天跑3s左右，所以要看下前后执行计划变化。

执行计划只贴关键部分。

加索引前的执行计划：

 -> Nested Loop (cost=19.92..2259694.20 rows=265822 width=33)
 -> Index Scan using uk_lzl_task on lzl_task t (cost=0.29..20007.99 rows=195 width=24)
 Filter: ((created_by)::text = 'LIUZHILONG62'::text)
 -> Append (cost=19.63..11337.15 rows=14842 width=57)
 -> Bitmap Heap Scan on lzl_202501 cc_1 (cost=19.63..3053.69 rows=1467 width=66)
 Recheck Cond: ((task_no)::text = (t.task_no)::text)
 Filter: ((created_date > '2025-01-07 09:00:00'::timestamp without time zone) AND (created_date < '2025-09-03 12:56:44.973'::timestamp without time zone))
 -> Bitmap Index Scan on lzl_202501_task_no_idx (cost=0.00..19.27 rows=1594 width=0)
 Index Cond: ((task_no)::text = (t.task_no)::text)
 -> Bitmap Heap Scan on lzl_202502 cc_2 (cost=21.67..3066.85 rows=1604 width=66)
 Recheck Cond: ((task_no)::text = (t.task_no)::text)
 Filter: ((created_date > '2025-01-07 09:00:00'::timestamp without time zone) AND (created_date < '2025-09-03 12:56:44.973'::timestamp without time zone))
 -> Bitmap Index Scan on lzl_202502_task_no_idx (cost=0.00..21.27 rows=1605 width=0)
 Index Cond: ((task_no)::text = (t.task_no)::text)
 -> Index Scan using lzl_202503_task_no_idx on lzl_202503 cc_3 (cost=0.43..1362.61 rows=1637 width=57)
 Index Cond: ((task_no)::text = (t.task_no)::text)
 Filter: ((created_date > '2025-01-07 09:00:00'::timestamp without time zone) AND (created_date < '2025-09-03 12:56:44.973'::timestamp without time zone))
 -> Index Scan using lzl_202504_task_no_idx on lzl_202504 cc_4 (cost=0.43..604.64 rows=1795 width=56)
 Index Cond: ((task_no)::text = (t.task_no)::text)
 Filter: ((created_date > '2025-01-07 09:00:00'::timestamp without time zone) AND (created_date < '2025-09-03 12:56:44.973'::timestamp without time zone))
 -> Index Scan using lzl_202505_task_no_idx on lzl_202505 cc_5 (cost=0.43..445.30 rows=1450 width=56)
 Index Cond: ((task_no)::text = (t.task_no)::text)
 Filter: ((created_date > '2025-01-07 09:00:00'::timestamp without time zone) AND (created_date < '2025-09-03 12:56:44.973'::timestamp without time zone))
 -> Index Scan using lzl_202506_task_no_idx on lzl_202506 cc_6 (cost=0.43..583.94 rows=1675 width=56)
 Index Cond: ((task_no)::text = (t.task_no)::text)
 Filter: ((created_date > '2025-01-07 09:00:00'::timestamp without time zone) AND (created_date < '2025-09-03 12:56:44.973'::timestamp without time zone))
 -> Index Scan using lzl_202507_task_no_idx on lzl_202507 cc_7 (cost=0.43..633.45 rows=1973 width=56)
 Index Cond: ((task_no)::text = (t.task_no)::text)
 Filter: ((created_date > '2025-01-07 09:00:00'::timestamp without time zone) AND (created_date < '2025-09-03 12:56:44.973'::timestamp without time zone))
 -> Index Scan using lzl_202508_task_no_idx on lzl_202508 cc_8 (cost=0.43..619.43 rows=1720 width=56)
 Index Cond: ((task_no)::text = (t.task_no)::text)
 Filter: ((created_date > '2025-01-07 09:00:00'::timestamp without time zone) AND (created_date < '2025-09-03 12:56:44.973'::timestamp without time zone))
 -> Index Scan using lzl_202509_task_no_idx on lzl_202509 cc_9 (cost=0.42..893.03 rows=1521 width=56)
 Index Cond: ((task_no)::text = (t.task_no)::text)
 Filter: ((created_date > '2025-01-07 09:00:00'::timestamp without time zone) AND (created_date < '2025-09-03 12:56:44.973'::timestamp without time zone))

created_date时间范围，找1年的数据，前晚变更加的索引是created_date。

加索引后的执行计划：

 -> Hash Join (cost=63.37..23740.82 rows=191 width=33)
 Hash Cond: ((cc.task_no)::text = (t.task_no)::text)
 -> Append (cost=0.00..23376.98 rows=114435 width=58)
 Subplans Removed: 28
 -> Index Scan using idx_lzltab_202501_created_date on lzltab_202501 cc_1 (cost=0.43..1450.59 rows=8958 width=66)
 Index Cond: ((created_date > $1) AND (created_date < $2))
 -> Index Scan using idx_lzltab_202502_created_date on lzltab_202502 cc_2 (cost=0.43..1822.73 rows=7405 width=66)
 Index Cond: ((created_date > $1) AND (created_date < $2))
 -> Index Scan using idx_lzltab_202503_created_date on lzltab_202503 cc_3 (cost=0.43..1430.03 rows=7917 width=57)
 Index Cond: ((created_date > $1) AND (created_date < $2))
 -> Index Scan using idx_lzltab_202504_created_date on lzltab_202504 cc_4 (cost=0.43..2412.44 rows=11041 width=56)
 Index Cond: ((created_date > $1) AND (created_date < $2))
 -> Index Scan using idx_lzltab_202505_created_date on lzltab_202505 cc_5 (cost=0.43..2260.73 rows=13381 width=56)
 Index Cond: ((created_date > $1) AND (created_date < $2))
 -> Index Scan using idx_lzltab_202506_created_date on lzltab_202506 cc_6 (cost=0.43..3930.10 rows=17832 width=56)
 Index Cond: ((created_date > $1) AND (created_date < $2))
 -> Index Scan using idx_lzltab_202507_created_date on lzltab_202507 cc_7 (cost=0.43..3878.77 rows=21786 width=56)
 Index Cond: ((created_date > $1) AND (created_date < $2))
 -> Index Scan using idx_lzltab_202508_created_date on lzltab_202508 cc_8 (cost=0.43..4736.72 rows=22033 width=56)
 Index Cond: ((created_date > $1) AND (created_date < $2))
 -> Index Scan using idx_lzltab_202509_created_date on lzltab_202509 cc_9 (cost=0.42..627.09 rows=1893 width=56)
 Index Cond: ((created_date > $1) AND (created_date < $2))
 -> Hash (cost=63.03..63.03 rows=27 width=24)
 -> Bitmap Heap Scan on ai_outbound_call_task t (cost=2.99..63.03 rows=27 width=24)
 Recheck Cond: ((created_by)::text = ($3)::text)
 -> Bitmap Index Scan on idx_ai_call_task_c (cost=0.00..2.99 rows=27 width=0)
 Index Cond: ((created_by)::text = ($3)::text)

新的执行计划从task_no索引变成走created_date索引，nl变成hash join。cost从2259694减少到23740，减少100倍。但是，实际执行时间增加了10倍左右。

问题定位
#

从3个问题来带入分析定位：

为什么优化人员建议了created_date索引？
为什么走到了新的索引？
为什么新的执行计划执行时间很长但预估rows很小？

为什么优化人员建议了created_date索引？
#

如果直接把pg日志中参数回填到sql文本，执行计划其实是好的那一个，也就是跑3s的走task_no索引的plan。优化人员也这么跑了，发现还可以。但是生产环境却不是这个执行计划。

即使强制不让走task_no索引，优化器选择全表扫描都不去走create date索引：

 Hash Cond: (((cc.task_no)::text || ''::text) = (t.task_no)::text)
 -> Append (cost=0.00..2794425.58 rows=22238757 width=57)
 -> Seq Scan on lzltab_202501 cc_1 (cost=0.00..193060.05 rows=1585238 width=66)
 Filter: ((created_date > '2025-01-08 11:00:00'::timestamp without time zone) AND (created_date < '2025-09-04 08:31:43'::timestamp without time zone))
 -> Seq Scan on lzltab_202502 cc_2 (cost=0.00..178567.54 rows=1480969 width=66)
 Filter: ((created_date > '2025-01-08 11:00:00'::timestamp without time zone) AND (created_date < '2025-09-04 08:31:43'::timestamp without time zone))
 -> Seq Scan on lzltab_202503 cc_3 (cost=0.00..191073.34 rows=1583356 width=57)

这就很奇怪，自己怎么跑都走不到created_date烂索引，生产环境又是怎么走到created_date的？

联想到有绑定变量，有可能会是generic plan。

generic plan的特性：

当force_custom_plan =auto时，对比generic plan和avg(前五次硬解析的执行计划的代价)，如果generic plan更小就用generic plan，后续不再进行硬解析；否则每次都硬解析（见源码choose_custom_plan）
generic plan长什么样子跟绑定变量本身是多少没有关系

使用绑定变量传值很容易复现：

PREPARE sql1(timestamp without time zone,timestamp without time zone,text) AS
SELECT COUNT(*)
xxxxxxx...;

=# EXECUTE sql1('2025-01-08 11:00:00','2025-09-04 08:31:43','LIUZHILONG62'); 
 count 
-------
 12016
(1 row)

Time: 367.220 ms
=# EXECUTE sql1('2025-01-08 11:00:00','2025-09-04 08:31:43','LIUZHILONG62'); 
 count 
-------
 12016
(1 row)

Time: 254.386 ms
=# EXECUTE sql1('2025-01-08 11:00:00','2025-09-04 08:31:43','LIUZHILONG62'); 
 count 
-------
 12016
(1 row)

Time: 235.343 ms
=# EXECUTE sql1('2025-01-08 11:00:00','2025-09-04 08:31:43','LIUZHILONG62'); 
 count 
-------
 12016
(1 row)

Time: 234.110 ms
=# EXECUTE sql1('2025-01-08 11:00:00','2025-09-04 08:31:43','LIUZHILONG62'); 
 count 
-------
 12016
(1 row)

Time: 233.570 ms
=# EXECUTE sql1('2025-01-08 11:00:00','2025-09-04 08:31:43','LIUZHILONG62'); 
 count 
-------
 12016
(1 row)

Time: 70678.344 ms (01:10.678) --第6次执行时间明显变长


=# select * from pg_prepared_statements\gx --pg14支持pg_prepared_statements
generic_plans | 1
custom_plans | 5

前5次硬解析用custom_plans跑出来都很快，第6次用到generic_plan，走的created_date，即为生产的故障计划，非常慢。

所以优化建议里用created_date是有些问题，但是替换变量为具体值后explain出来的执行计划是对的，而生产环境业务用绑定变量跑，跑到了generic plan，故障就此出现。

为什么新的执行计划执行时间很长但预估rows很小？
#

故障执行计划有个问题，预估的cost太小，rows太少

 -> Index Scan using idx_lzltab_202501_created_date on lzltab_202501 cc_1 (cost=0.43..1450.59 rows=8958 width=66)
 Index Cond: ((created_date > $1) AND (created_date < $2))

这从业务逻辑上看这有点不正常，因为create_date条件已经跨了多个分区，created_date是分区键，那么where created>=xx <=yy一定是连续的，在子分区上的选择率应该始终为1，rows应是子分区行数，应该是几百万而不是几千。

刚开始以为是统计信息的问题，但统计信息是比较准确的，202501的历史分区数据没有什么变动。

既然是generic plan需要从generic plan预估代价入手翻源码。cost要难一点，看rows的预估逻辑要相对简单些，也容易定位。

static double
calc_rangesel(TypeCacheEntry *typcache, VariableStatData *vardata,
			 const RangeType *constval, Oid operator)
{
...
		else
		{
			/* with any other operator, empty Op non-empty matches nothing */
			selec = (1.0 - empty_frac) * hist_selec;
		}
	}

	/* all range operators are strict */
	selec *= (1.0 - null_frac);

range_select=(1-null率)*直方图选择率，range直方图选择率看range命中的直方图对应的选择率再加个命中的MCV即可。不过这个案例不用算这些。

因为generic plan不看直方图：

/*
 * rangesel -- restriction selectivity for range operators
 */
Datum
rangesel(PG_FUNCTION_ARGS)
{
...
	/*
	 * If we got a valid constant on one side of the operator, proceed to
	 * estimate using statistics. Otherwise punt and return a default constant
	 * estimate. Note that calc_rangesel need not handle
	 * OID_RANGE_ELEM_CONTAINED_OP.
	 */
	if (constrange)
		selec = calc_rangesel(typcache, &vardata, constrange, operator);
	else
		selec = default_range_selectivity(operator);
...
}

calc_rangesel就是上面那个有常量值传入的选择率计算，else就是默认选择率函数default_range_selectivity，不传入常量

/*
 * Returns a default selectivity estimate for given operator, when we don't
 * have statistics or cannot use them for some reason.
 */
static double
default_range_selectivity(Oid operator)
{
	switch (operator)
	{
 ...
		case OID_RANGE_CONTAINS_ELEM_OP:
		case OID_RANGE_ELEM_CONTAINED_OP:

			/*
			 * "range @> elem" is more or less identical to a scalar
			 * inequality "A >= b AND A <= c".
			 */
			return DEFAULT_RANGE_INEQ_SEL;
	}
}

range的默认选择率define：

/* default selectivity estimate for range inequalities "A > b AND A < c" */
#define DEFAULT_RANGE_INEQ_SEL	0.005

返回生产环境计算rows

 select reltuples::bigint*0.005 from pg_class where relname='lzltab_202501'\gx
-[ RECORD 1 ]------
?column? | 8958.350

这跟实际的rows估算值8958相等：

idx_lzltab_202501_created_date on lzltab_202501 cc_1 (cost=0.43..1450.59 rows=8958 width=66)

所以新的执行计划估算不准确是因为generic plan使用了默认的选择率。

问题总结
#

为什么要有generic plan以及软解析的问题
#

把generic plan看成是DEFAULT estimate plan还更容易理解一点

为什么generic plan好像总是有问题？

理出以下思维链：

generic plan是为了减少硬解析，即使用软解析如果不是每次执行都是硬解析，那么可以不传入具体参数直接使用执行计划如果不传参直接用执行计划，那么需要提前生成执行计划

提前生成执行计划的方式：

不传参执行计划（generic plan）
用前几次传参生成的执行计划（pg没有这种东西）

如果使用generic plan，有可能是不准确的，比如

1.数据倾斜（如某个mcv极高，如where a=1，但a=1非常多），这极度依赖传入参数本身是啥，但generic plan不传参，所以执行计划不可能准确
2.数据均衡但无法准确计算选择率（如where a>$1 and a<$2），如果不知道range没人能计算出选择率，但generic plan不传参，所以执行计划不可能准确

如果前几次传参执行计划（pg没有这种东西），有可能也是不准确的，比如

数据倾斜，前几次传参没有普遍性，前几次传参极大的影响了后续固定的执行计划是什么

generic plan预估不准的问题分类
#

因为要5次对比，所以generic plan的问题可以分为2种：

前5次SQL的执行没有普遍性。跟前5次执行计划相关性大，依赖数据倾斜和前5次参数是否具有普遍性。
generic plan本身有问题。generic plan因为数据倾斜或数据均衡但无法准确计算选择率，导致generic plan本身执行效率低下

优化方案
#

从这个案例看下来，generic plan问题在分区表上可能会出现，分区键是连续的，扫描所有分区建选择率应该为1，但generic plan为0.05，很可能导致走“全索引”扫描这种场景。

所以在优化的时候需要考虑更多：

不要建太多索引迷惑优化器
排除generic plan的干扰。用EXECUTE真实跑6次
会话级别set plan_cache_mode='force_generic_plan'; or set plan_cache_mode='force_custom_plan';对比执行计划；或者在pg16+用explain (GENERIC_PLAN)对比执行计划

语法参考：

--prepare/excute
PREPARE sql1(text) AS
SELECT COUNT(*) FROM LZL where a=$1;

EXECUTE sql1('zzz'); --跑6次再说
EXPLAIN EXECUTE sql1('zzz');

select * from pg_prepared_statements --查看prepare语句信息，只能看当前会话

--对比执行计划，设置会话参数后执行EXPLAIN EXECUTE
set plan_cache_mode='force_generic_plan'
set plan_cache_mode='force_custom_plan'
--直接查看genetic plan,16+
explain (GENERIC_PLAN) xx 

查询冲突：从静态表查询冲突到其原理

Sat, 13 Sep 2025 00:00:00 +0000

问题现象
#

现象
#

一个静态历史表，没有任何更新，在同城从库跑SQL稳定触发查询冲突：

ERROR: 40001: canceling statement due to conflict with recovery
DETAIL: User query might have needed to see row versions that must be removed.
LOCATION: ProcessInterrupts, postgres.c:3197
Time: 30534.973 ms (00:30.535)

为什么一个静态表查询冲突是一个值得关注的问题
#

我的理解中静态表是不应该发生冲突的（这个理解错了，后面会解释）。

官方文档 Conflict cases include:

Access Exclusive locks taken on the primary server, including both explicit LOCK commands and various DDL actions, conflict with table accesses in standby queries.
Dropping a tablespace on the primary conflicts with standby queries using that tablespace for temporary work files.
Dropping a database on the primary conflicts with sessions connected to that database on the standby.
Application of a vacuum cleanup record from WAL conflicts with standby transactions whose snapshots can still “see” any of the rows to be removed.
Application of a vacuum cleanup record from WAL conflicts with queries accessing the target page on the standby, whether or not the data to be removed is visible.

LOCK,DDL,drop tablespace ,drop database肯定没有。

vacuum，这也没有，这可以从pg_stat_all_tables.last_autovacuum和wal vacuum record可以看出来

官方文档的解释就到此为止了，我自己仔细排查了一下确认没有以上情况。

利用现有知识可能还有其他场景干掉从库查询的所持有快照的xmin。例如页内修剪会干掉page中行上的xmin，如果下游的查询的快照还依赖这些xmin，这理论上也会发生查询冲突。但是，page是属于一个表的，只查一个表只能持有这个表上的快照以及表上的xmin，所以，理论上A表的页内修剪，应该不会发生B表上的查询冲突（这个理解错了，后面会解释）。

pg官方文档对查询冲突场景的解释比较糊，没有很好的解释静态表发生冲突的场景和原因。加上自己联想的场景，也不应该有查询冲突。但我发现这个场景似乎在很多库上都有，所以得看下咋回事。

原因分析
#

因为是startup把查询掐掉的，所以看startup进程的pstack即可找到查询冲突函数

$ pstack 212012
#0 0x00002b283f63d783 in __select_nocancel () from /lib64/libc.so.6
#1 0x00000000008fcf5a in pg_usleep (microsec=<optimized out>) at pgsleep.c:56
#2 0x0000000000787905 in WaitExceedsMaxStandbyDelay (wait_event_info=134217762) at standby.c:208
#3 ResolveRecoveryConflictWithVirtualXIDs (waitlist=0x2398a50, reason=reason@entry=PROCSIG_RECOVERY_CONFLICT_SNAPSHOT, wait_event_info=wait_event_info@entry=134217762, report_waiting=report_waiting@entry=true) at standby.c:276
#4 0x0000000000787b33 in ResolveRecoveryConflictWithVirtualXIDs (report_waiting=true, wait_event_info=134217762, reason=PROCSIG_RECOVERY_CONFLICT_SNAPSHOT, waitlist=<optimized out>) at standby.c:333
#5 ResolveRecoveryConflictWithSnapshot (latestRemovedXid=<optimized out>, node=...) at standby.c:329
#6 0x00000000004c8ffe in heap_xlog_clean (record=0x2366978) at heapam.c:7764
#7 heap2_redo (record=0x2366978) at heapam.c:8917
#8 0x0000000000519e55 in StartupXLOG () at xlog.c:7411
#9 0x000000000072f211 in StartupProcessMain () at startup.c:204
#10 0x00000000005286b1 in AuxiliaryProcessMain (argc=argc@entry=2, argv=argv@entry=0x7ffeb7e39d70) at bootstrap.c:450
#11 0x000000000072c369 in StartChildProcess (type=StartupProcess) at postmaster.c:5494
#12 0x000000000072eb54 in PostmasterMain (argc=argc@entry=3, argv=argv@entry=0x232edb0) at postmaster.c:1407
#13 0x00000000004892cf in main (argc=3, argv=0x232edb0) at main.c:210

XLOG_HEAP2_CLEAN
#

void
heap2_redo(XLogReaderState *record)
{
	uint8		info = XLogRecGetInfo(record) & ~XLR_INFO_MASK;

	switch (info & XLOG_HEAP_OPMASK)
	{
		case XLOG_HEAP2_CLEAN:
			heap_xlog_clean(record);
			break;

当redo是XLOG_HEAP2_CLEAN时，才会进入这个下一个函数heap_xlog_clean

pg 18已经没有XLOG_HEAP2_CLEAN这个东西了（15左右其实就没有了，这篇文章就只看13和18两个版本），但是可以在heapam_xlog.h中找到define

//pg13
#define XLOG_HEAP2_CLEAN		0x10
#define XLOG_HEAP2_FREEZE_PAGE	0x20
#define XLOG_HEAP2_CLEANUP_INFO 0x30

//pg18
 * There's no difference between XLOG_HEAP2_PRUNE_ON_ACCESS,
 * XLOG_HEAP2_PRUNE_VACUUM_SCAN and XLOG_HEAP2_PRUNE_VACUUM_CLEANUP records.
 * They have separate opcodes just for debugging and analysis purposes, to
 * indicate why the WAL record was emitted.
 */
#define XLOG_HEAP2_PRUNE_ON_ACCESS		0x10
#define XLOG_HEAP2_PRUNE_VACUUM_SCAN	0x20
#define XLOG_HEAP2_PRUNE_VACUUM_CLEANUP	0x30

把pg18的源码掏出来，主要是因为pg13（当前生产库的版本）对这几个xl_info 的CLEAN宏定义一点解释没有，我看不懂。由于18这段宏换了个更容易理解的名字，而且加上了注释，我们可以从18的源码来理解13，看看这个wal record是干什么的。

这3个opcodes本质上都是为了PRUNE产生的wal record。从名字上看PRUNE ON ACCESS看着像访问产生PRUNE，另外两个跟VACUUM动作相关。

用pg_waldump查看wal record的时候，rmgr: Heap2 CLEAN remxid这种record每几秒钟就生成几条，而且filenode差异很大，且跟静态表毫无关系：

$ pg_waldump 00000001000012FE00000001 |tail -200|egrep -i heap2
pg_waldump: fatal: error in WAL record at 12FE/F34F138: invalid resource manager ID 50 at 12FE/F34F168
rmgr: Heap2 len (rec/tot): 61/ 3520, tx: 0, lsn: 12FE/0F346ED0, prev 12FE/0F346EA0, desc: CLEAN remxid 1983744188, blkref #0: rel 1663/88121/1083807 blk 617606 FPW
rmgr: Heap2 len (rec/tot): 66/ 66, tx: 0, lsn: 12FE/0F34BC60, prev 12FE/0F34BC30, desc: CLEAN remxid 1984090598, blkref #0: rel 1663/88121/504681 blk 1447147

这个就跟我们的现象有点匹配了：没有vacuum动作但是有PRUNE，可以走到后续heap_xlog_clean ResolveRecoveryConflictWithSnapshot等查询冲突主函数上去。

PRUNE动作产生rmgr: Heap2 CLEAN remxidwalrecord后面会测试复现。

先把源码撸完。

ResolveRecoveryConflictWithSnapshot
#

void
ResolveRecoveryConflictWithSnapshot(TransactionId latestRemovedXid, RelFileNode node)
{
	VirtualTransactionId *backends;

	/*
	 * If we get passed InvalidTransactionId then we do nothing (no conflict).
	 *
	 * This can happen when replaying already-applied WAL records after a
	 * standby crash or restart, or when replaying an XLOG_HEAP2_VISIBLE
	 * record that marks as frozen a page which was already all-visible. It's
	 * also quite common with records generated during index deletion
	 * (original execution of the deletion can reason that a recovery conflict
	 * which is sufficient for the deletion operation must take place before
	 * replay of the deletion record itself).
	 */
	if (!TransactionIdIsValid(latestRemovedXid))
		return;

	backends = GetConflictingVirtualXIDs(latestRemovedXid,
										 node.dbNode);

	ResolveRecoveryConflictWithVirtualXIDs(backends,
										 PROCSIG_RECOVERY_CONFLICT_SNAPSHOT,
										 WAIT_EVENT_RECOVERY_CONFLICT_SNAPSHOT,
										 true);
}

查询冲突有几个类型，其中ResolveRecoveryConflictWithSnapshot人如其名就是跟快照冲突了，

其中GetConflictingVirtualXIDs是找到哪些backends跟快照冲突。ResolveRecoveryConflictWithVirtualXIDs主要是解决冲突，时间限制。

GetConflictingVirtualXIDs
#

GetConflictingVirtualXIDs是判断是否vxid backend发生查询冲突的关键函数，要稍微用点脑力。关键函数解读所需要的基础知识：

limitXmin就是latestRemovedXid，也就是wal中的 CLEAN remxid，也就是需要被清理的xid（remxid我理解为remove xid）。/*limitXmin is supplied as either latestRemovedXid, or InvalidTransactionId*/
PGPROC是当前进程信息，有backend id，databas id，锁信息等等很多东西
PGXACT是当前进程持有的快照的事务信息，信息没有那么多，最关键的就是xmin——当前进程运行的最小xid
c中||的规则是：只要有一个操作数为真（非零），结果就为真（1）
TransactionIdIsValid即xid!=0，0完全没有意义

关键函数GetConflictingVirtualXIDs解读：

VirtualTransactionId *
GetConflictingVirtualXIDs(TransactionId limitXmin, Oid dbOid)
{
	...
	for (index = 0; index < arrayP->numProcs; index++) //所有本地进程循环处理
	{
		int			pgprocno = arrayP->pgprocnos[index];
		PGPROC	 *proc = &allProcs[pgprocno]; //进程的PGPROC
		PGXACT	 *pgxact = &allPgXact[pgprocno]; //进程的PGXACT

		/* Exclude prepared transactions */
		if (proc->pid == 0) //prepared transaction没有进程持有，处理不了
			continue;

		if (!OidIsValid(dbOid) || //要注意全局的表，全局表的dbOid=0是invalid的，满足条件
			proc->databaseId == dbOid) //只处理当前database。跨库是另一码事了，根本不会事务冲突。
		{
			/* Fetch xmin just once - can't change on us, but good coding */
			TransactionId pxmin = UINT32_ACCESS_ONCE(pgxact->xmin); //pgxact->xmin即是当前进程持有事务的最小xid，UINT32_ACCESS_ONCE只是为了保护原子操作，取xmin逻辑不变

			/*
			 * We ignore an invalid pxmin because this means that backend has
			 * no snapshot currently. We hold a Share lock to avoid contention
			 * with users taking snapshots. That is not a problem because the
			 * current xmin is always at least one higher than the latest
			 * removed xid, so any new snapshot would never conflict with the
			 * test here.
			 */
			if (!TransactionIdIsValid(limitXmin) || //limitXmin=0还能出现？至少latestRemovedXid不可能有，我想不到有什么场景会出现wal日志写入无效xid
				(TransactionIdIsValid(pxmin) && !TransactionIdFollows(pxmin, limitXmin))) //TransactionIdIsValid(pxmin)也没有什么用。!TransactionIdFollows(pxmin, limitXmin)表示只要pxmin<=limitXmin即可
			{
				VirtualTransactionId vxid;

				GET_VXID_FROM_PGPROC(vxid, *proc);
				if (VirtualTransactionIdIsValid(vxid))
					vxids[count++] = vxid;
			}
		}
	}

最关键的是!TransactionIdFollows(pxmin, limitXmin)

所以这段判断是否存在查询冲突的代码，最主要判断逻辑是：

主库清理的remxid>=从库查询的快照持有的最小xid，即冲突。
只掐掉当前db的；没有db的全局系统表就不管了会无脑掐

所以即使被清理的主库表和从库查询的表不相干，也会冲突！！！

页内修剪
#

发生冲突的逻辑理完了，但wal CLEAN 怎么来的还没有弄清楚，这就需要先看下PRUNE怎么产生的。

README.HOT关于什么时候产生prune和defragment的描述– When can/should we prune or defragment?

The currently planned heuristic is to prune and defrag when first accessing a page that potentially has prunable tuples

prune和defragment确实是2个概念，但是很有可能一起做了。

prune指更新line pointers使HOT链更短，但不会释放空间
defragment指回收prune后page上已死的line pointers和行所占用的空间

We cannot prune or defragment unless we can get a “buffer cleanup lock” on the target page; otherwise, pruning might destroy line pointers that other backends have live references to, and defragmenting might move tuples that other backends have live pointers to

page是"buffer cleanup lock"的，才会产生prune或者defragment

The worst-case consequence of this is only that an UPDATE cannot be made HOT but has to link to a new tuple version placed on some other page, for lack of centralized space on the original page.

其中一个典型场景是，HOT更新到了page外（容易测试）

space reclamation happens during tuple retrieval when the page is nearly full (<10% free) and a buffer cleanup lock can be acquired. This means that UPDATE, DELETE, and SELECT can trigger space reclamation, but often not during INSERT … VALUES because it does not retrieve a row.

SELECT/UPDATE/DELETE扫描行的都可能发生空间回收动作，INSERT不会，因为INSERT不会扫描行。

显然prune or defragment后对应的xid应该回收了，从readme就可以看出来通过HOT更新可以复现prune or defragment，然后产生CLEAN walrecord。见[测试：update产生页内修剪](## 测试：纯update产生页内修剪)

测试
#

以下测试只观察到冲突产生或者有CLEAN walrecord或者有页上lp的更新，不区分到底是prune还是defragment。很多场景应该是一起触发两者，区分两者有点费劲，maybe以后再说。这里主要是看CLEAN walrecord等有没有。

会用到的sql：

--sql for test
--heap_page_items
select t_ctid,lp,
case lp_flags 
when 0 then '0:LP_UNUSED' 
when 1 then 'LP_NORMAL' 
when 2 then 'LP_REDIRECT' 
when 3 then 'LP_DEAD' 
end as lp_flags,
t_xmin,t_xmax,t_field3 as t_cid, raw_flags, info.combined_flags,substring(t_data,0,40) 
from heap_page_items(get_raw_page('lzl',0)) item,
LATERAL heap_tuple_infomask_flags(t_infomask, t_infomask2) info 
order by lp;

--heap header 
select * from page_header(get_raw_page('lzl',0));

--bt_page_items
SELECT itemoffset, ctid, itemlen, nulls, vars, dead, htid, tids[0:2] AS some_tids FROM bt_page_items('idxlzl',1);

--create table
create table lzl(a char(2000));
create index idxlzl on lzl(a);
insert into lzl values('z');
update lzl set a=md5(random()::text); --非hot
update lzl set a='z'; --hot

--触发索引扫描
set enable_seqscan =off;
set enable_indexonlyscan=off;

--开启rr事务获取快照不释放，方便观察
BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ;

测试：异表查询冲突
#

primary	standby
create table lzl(a bigint primary key);
insert into lzl values(1);
	BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ;
	select 1;
update lzl set a=2;
	不阻塞
vacuum lzl;
	#3 ResolveRecoveryConflictWithVirtualXIDs (waitlist=0x277c340, reason=reason@entry=PROCSIG_RECOVERY_CONFLICT_SNAPSHOT, wait_event_info=wait_event_info@entry=134217762, report_waiting=report_waiting@entry=true) at standby.c:276 #4 0x0000000000787b33 in ResolveRecoveryConflictWithVirtualXIDs (report_waiting=true, wait_event_info=134217762, reason=PROCSIG_RECOVERY_CONFLICT_SNAPSHOT, waitlist=) at standby.c:333 #5 ResolveRecoveryConflictWithSnapshot (latestRemovedXid=, node=…) at standby.c:329 #6 0x00000000004c8ffe in heap_xlog_clean (record=0x273a258) at heapam.c:7764

结论：只要查询产生，就会有快照，有快照就会有快照xmin，即使查询的表毫不相干，也可以发生查询冲突

测试：vacuum产生页内修剪
#

会修剪，会冲突。示例略，跟本案无关

测试：update产生页内修剪
#

--HOT，更新到页外defragment
--一个8k的heap page，存储的行数是4-2xx条。这里规划了行大小，生成4条数据保证HOT，下一条更新即触发页外更新
create table lzl(a char(2000));
create table idxlzl on lzl(a);
insert into lzl values('z');
update lzl set a='z'; --hot
update lzl set a='z'; --hot
update lzl set a='z'; --hot

--heap page 4条数据，且HOT:
 t_ctid | lp | lp_flags | t_xmin | t_xmax | t_cid | raw_flags | combined_flags | 
--------+----+-----------+----------+----------+-------+----------------------------------------------------------------------------------------------------------+----------------+----------
 (0,2) | 1 | LP_NORMAL | 34954161 | 34954162 | 0 | {HEAP_HASVARWIDTH,HEAP_XMIN_COMMITTED,HEAP_XMAX_COMMITTED,HEAP_HOT_UPDATED} | {} | \x501f000
 (0,3) | 2 | LP_NORMAL | 34954162 | 34954163 | 0 | {HEAP_HASVARWIDTH,HEAP_XMIN_COMMITTED,HEAP_XMAX_COMMITTED,HEAP_UPDATED,HEAP_HOT_UPDATED,HEAP_ONLY_TUPLE} | {} | \x501f000
 (0,4) | 3 | LP_NORMAL | 34954163 | 34954164 | 0 | {HEAP_HASVARWIDTH,HEAP_XMIN_COMMITTED,HEAP_UPDATED,HEAP_HOT_UPDATED,HEAP_ONLY_TUPLE} | {} | \x501f000
 (0,4) | 4 | LP_NORMAL | 34954164 | 0 | 0 | {HEAP_HASVARWIDTH,HEAP_XMAX_INVALID,HEAP_UPDATED,HEAP_ONLY_TUPLE} | {} | \x501f000
(4 rows)

--索引条目仅一个：
 itemoffset | ctid | itemlen | nulls | vars | dead | htid | some_tids 
------------+-------+---------+-------+------+------+-------+-----------
 1 | (0,1) | 48 | f | t | f | (0,1) | [null]

--再更新一条，触发页外更新
update lzl set a='z'; --page已满，hot不了了

--hot链改变。lp改变
 t_ctid | lp | lp_flags | t_xmin | t_xmax | t_cid | raw_flags | combined_flags | 
--------+----+-------------+----------+----------+--------+--------------------------------------------------------------------------------------+----------------+---------------------------
 [null] | 1 | LP_REDIRECT | [null] | [null] | [null] | [null] | [null] | [null]
 (0,2) | 2 | LP_NORMAL | 34954165 | 0 | 0 | {HEAP_HASVARWIDTH,HEAP_XMAX_INVALID,HEAP_UPDATED,HEAP_ONLY_TUPLE} | {} | \x501f00007a20202020202020
 [null] | 3 | 0:LP_UNUSED | [null] | [null] | [null] | [null] | [null] | [null]
 (0,2) | 4 | LP_NORMAL | 34954164 | 34954165 | 0 | {HEAP_HASVARWIDTH,HEAP_XMIN_COMMITTED,HEAP_UPDATED,HEAP_HOT_UPDATED,HEAP_ONLY_TUPLE} | {} | \x501f00007a20202020202020
(4 rows)

--索引条目仅一个，没变：
 itemoffset | ctid | itemlen | nulls | vars | dead | htid | some_tids 
------------+-------+---------+-------+------+------+-------+-----------
 1 | (0,1) | 48 | f | t | f | (0,1) | [null]

再次更新，row没有写到下个页，而是在本页发生页内修剪后写入本页，这样减少了一个页的访问。

wal产生CLEAN remxid ，也说明可以发生查询冲突：

rmgr: Heap2 len (rec/tot): 62/ 62, tx: 0, lsn: 3DB/F8017348, prev 3DB/F8017310, desc: CLEAN remxid 34954177, blkref #0: rel 1663/5893914/5893920 blk 0
rmgr: Heap len (rec/tot): 2070/ 2070, tx: 34954178, lsn: 3DB/F8017388, prev 3DB/F8017348, desc: HOT_UPDATE off 4 xmax 34954178 flags 0x10 ; new off 2 xmax 0, blkref #0: rel 1663/5893914/5893920 blk 0

结论：update语句可产生页内修剪，可产生查询冲突

测试：hintbit回写产生页内修剪？
#

primary	standby
wal_log_hints=on
truncate table lzl;
insert into lzl values(‘z’);
	BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ;
	select * from lzl;
delete from lzl where a=‘z’;
checkpoint;
select * from lzl;
–wal中生成FPI_FOR_HINT
	–未发生查询冲突

standby的pageinspect：

 t_ctid | lp | lp_flags | t_xmin | t_xmax | t_cid | raw_flags | combined_flags | substring 
--------+----+-----------+----------+----------+-------+------------------------------------------------------------------------------+----------------+-------------------------------------------------
 (0,1) | 1 | LP_NORMAL | 34954229 | 34954230 | 0 | {HEAP_HASVARWIDTH,HEAP_XMIN_COMMITTED,HEAP_XMAX_COMMITTED,HEAP_KEYS_UPDATED} | {} | \x501f00007a202020202020202020202020202020202020
(1 row)

结论：wal log hint只是同步hintbit，不会对xmin/xmax产生影响，wal也不会有CLEAN等东西的产生，所以hintbit回写不会查询冲突。

测试：查询产生页内修剪
#

查询正常不会修剪，但page被填满会：https://www.modb.pro/db/1683648157451362304

填满page测试pruning：

--还是刚才的表，4条记录且HOT，几乎填满
insert into lzl values('z');
update lzl set a='z'; 
update lzl set a='z'; 
update lzl set a='z'; 

--此时的page：
 t_ctid | lp | lp_flags | t_xmin | t_xmax | t_cid | raw_flags | combined_flags | 
--------+----+-----------+----------+----------+-------+----------------------------------------------------------------------------------------------------------+----------------+---------------------
 (0,2) | 1 | LP_NORMAL | 34954232 | 34954233 | 0 | {HEAP_HASVARWIDTH,HEAP_XMIN_COMMITTED,HEAP_XMAX_COMMITTED,HEAP_HOT_UPDATED} | {} | \x501f00007a20202020
 (0,3) | 2 | LP_NORMAL | 34954233 | 34954234 | 0 | {HEAP_HASVARWIDTH,HEAP_XMIN_COMMITTED,HEAP_XMAX_COMMITTED,HEAP_UPDATED,HEAP_HOT_UPDATED,HEAP_ONLY_TUPLE} | {} | \x501f00007a20202020
 (0,4) | 3 | LP_NORMAL | 34954234 | 34954235 | 0 | {HEAP_HASVARWIDTH,HEAP_XMIN_COMMITTED,HEAP_UPDATED,HEAP_HOT_UPDATED,HEAP_ONLY_TUPLE} | {} | \x501f00007a20202020
 (0,4) | 4 | LP_NORMAL | 34954235 | 0 | 0 | {HEAP_HASVARWIDTH,HEAP_XMAX_INVALID,HEAP_UPDATED,HEAP_ONLY_TUPLE} | {} | \x501f00007a20202020
(4 rows)

-- 一个查询
select * from lzl;

--此时的page产生页内修剪
 t_ctid | lp | lp_flags | t_xmin | t_xmax | t_cid | raw_flags | combined_flags | sub
--------+----+-------------+----------+--------+--------+---------------------------------------------------------------------------------------+----------------+---------------------------------------
 [null] | 1 | LP_REDIRECT | [null] | [null] | [null] | [null] | [null] | [null]
 [null] | 2 | 0:LP_UNUSED | [null] | [null] | [null] | [null] | [null] | [null]
 [null] | 3 | 0:LP_UNUSED | [null] | [null] | [null] | [null] | [null] | [null]
 (0,4) | 4 | LP_NORMAL | 34954235 | 0 | 0 | {HEAP_HASVARWIDTH,HEAP_XMIN_COMMITTED,HEAP_XMAX_INVALID,HEAP_UPDATED,HEAP_ONLY_TUPLE} | {} | \x501f00007a20202020202020202020202020

结论：查询可以产生页内修剪，可以产生查询冲突

测试：共享表多database查询冲突
#

共享表是global的，之前在GetConflictingVirtualXIDs中有看到global的会无脑冲突。所以可以测一把。

共享表信息如下：

源码定义：IsSharedRelation
源码判断：shared ? InvalidOid : MyDatabaseId;
表：pg_class.relisshared
目录： global/

直接查pg_class.relisshared要方便一点：

select relname,relkind,relisshared from pg_class where relisshared is true and relkind='r';
		relname | relkind | relisshared 
-----------------------+---------+-------------
 pg_authid | r | t
 pg_subscription | r | t
 pg_database | r | t
 pg_db_role_setting | r | t
 pg_tablespace | r | t
 pg_auth_members | r | t
 pg_shdepend | r | t
 pg_shdescription | r | t
 pg_replication_origin | r | t
 pg_shseclabel | r | t

pg_authid会保存角色/用户的信息。这里以改密来测试：

--测试，在primary库 非业务db跑
create user lzl;
alter user lzl with password '1'; --多跑几次

产生CLEAN remxid：

rmgr: Heap len (rec/tot): 76/ 76, tx: 34954264, lsn: 3DB/F808D0F8, prev 3DB/F808D0B8, desc: HOT_UPDATE off 67 xmax 34954264 flags 0x20 ; new off 66 xmax 0, blkref #0: rel 1664/0/1260 blk 0
rmgr: Transaction len (rec/tot): 82/ 82, tx: 34954264, lsn: 3DB/F808D148, prev 3DB/F808D0F8, desc: COMMIT 2025-09-12 14:40:56.680782 CST; inval msgs: catcache 11 catcache 10
rmgr: Heap2 len (rec/tot): 60/ 60, tx: 0, lsn: 3DB/F808D1A0, prev 3DB/F808D148, desc: CLEAN remxid 34954264, blkref #0: rel 1664/0/1260 blk 0
rmgr: Heap2 len (rec/tot): 60/ 60, tx: 34954265, lsn: 3DB/F808D1E0, 

从库业务db的SQLselect 1被掐掉。

结论：共享表可以发生跨db查询冲突。

不过这些共享表正常业务很难有大量更新。

结论
#

开发视野
#

查询冲突可以跟查询的表无关，也就是说完全静态的表是可以发生冲突的。

跨db意味着不同的业务和数据。跨db不会发生查询冲突。一个例外是共享表会，但是共享表只有几个系统表，一般不会有什么更新。

对于开发来说，可以关注以下点：

请求重试：从库的查询可能会被掐掉，重试查询是必要的，重试有可能会成功
SQL时长：SQL时间越长越容易被掐掉
其他从库：可能要选择其他容灾属性不高的从库

运维视野
#

因为查询冲突可以从“四面八方”来，一个简单的长时间单表查询，可能会被其他频繁更新的表的页内修剪给干掉，所有可以调大max_standby_streaming_delay以降低冲突的概率。

但是，max_standby_streaming_delay是以牺牲应用日志为代价的，相当于日志应用停止。这个参数的大小就代表了最大可能的从库复制延迟（限制不了网络延迟等其他因素造成的延迟）。

查询时效：长时间的日志应用停止，从库的数据会严重落后（可能wal已经在从库磁盘上），会影响从库其他查询的数据时效要求。
RTO：如果主库灾难发生需要切换到从库，从库需要日志应用的时间。如果apply延迟太长比如几个小时，可能不能满足分钟级切换要求，这直接会影响SLA RTO承诺。

所以，调整max_standby_streaming_delay是一个精细活，需要从从库的角色定义，查询时效要求，甚至地域等来综合考虑。

控制文件上的参数和主从参数不一致问题

Mon, 25 Aug 2025 00:00:00 +0000

PARAMETER_CHANGE和控制文件上的数据库参数
#

pg有些参数会影响从库的运行，而这些参数不仅在参数文件中，也写到controlfile，只要参数改变就会写入wal并更新控制文件。从库会通过PARAMETER_CHANGE wal record进行redo，写入到从库的controlfile中。 PARAMETER_CHANGE wal record：

rmgr: XLOG len (rec/tot): 54/ 54, tx: 0, lsn: 27F/800001C0, prev 27F/80000148, desc: PARAMETER_CHANGE max_connections=3000 max_worker_processes=20 max_wal_senders=10 max_prepared_xacts=0 max_locks_per_xact=1024 wal_level=logical wal_log_hints=off track_commit_timestamp=on

XLOG_PARAMETER_CHANGE记录了这8种参数，控制文件也可以直接看，：

$ pg_controldata |grep setting
wal_level setting: logical
wal_log_hints setting: on
max_connections setting: 1000
max_worker_processes setting: 20
max_wal_senders setting: 10
max_prepared_xacts setting: 0
max_locks_per_xact setting: 1024
track_commit_timestamp setting: on

这些参数都是主库的，哪怕这个控制文件是从库的。 startup进程通过CheckRequiredParameterValues函数检查6个参数是否满足条件。其中1个参数wal_level>=replica，另外5个参数max_connections,max_worker_processes,max_wal_senders,max_prepared_transactions,max_locks_per_transaction会检查主从大小，从库小的话会pause recovery。直接将主库参数调大，从库直接挂掉，pg log如下：

FATAL,22023,"hot standby is not possible because max_connections = 2000 is a lower setting than on the master server (its value was 3000)",,,,,"WAL redo at 27F/800001C0 for XLOG/PARAMETER_CHANGE: max_connections=3000 max_worker_processes=20 max_wal_senders=10 max_prepared_xacts=0 max_locks_per_xact=1024 wal_level=logical wal_log_hints=off track_commit_timestamp=on",,,,"","startup"

8个参数中的6个都可能严重影响从库的运行。另外2个参数wal_log_hints,track_commit_timestamp不会被startup进程立即检查。8个参数同步到控制文件都有其意义。

wal_log_hint主从不一致
#

wal_log_hints的变化会记录到wal日志中，虽然不会被startup进程检查，pg_rewind会检查：

perform_rewind(...)
{
...
	/*
	 * Target cluster need to use checksums or hint bit wal-logging, this to
	 * prevent from data corruption that could occur because of hint bits.
	 */
	if (ControlFile_target.data_checksum_version != PG_DATA_CHECKSUM_VERSION &&
		!ControlFile_target.wal_log_hints)
	{
		pg_fatal("target server needs to use either data checksums or \"wal_log_hints = on\"");
	}

因为wal_log_hints是wal相关的，所以pg_rewind去检查从库的wal_log_hints参数有没有打开没有意义，应检查主库的wal_log_hints有没有打开，所以pg将wal_log_hints参数同步到从库的控制文件中了，非常合理。

wal_log_hint主从不一致测试：

select * from t1;
checkpoint;
update t1 set b='eee'; --观察点1
checkpoint; --忽略该online checkpoint wal record
select * from t1; --观察点2

--观察动作
pg_waldump 000000020000027F0000000A|tail -10

-- observing option
select t_ctid,lp,
case lp_flags 
when 0 then '0:LP_UNUSED' 
when 1 then 'LP_NORMAL' 
when 2 then 'LP_REDIRECT' 
when 3 then 'LP_DEAD' 
end as lp_flags,
t_xmin,t_xmax,t_field3 as t_cid, raw_flags, info.combined_flags,substring(t_data,0,40) 
from heap_page_items(get_raw_page('t1',0)) item,
LATERAL heap_tuple_infomask_flags(t_infomask, t_infomask2) info 
order by lp;

on，on:

--观察点1：
rmgr: Heap len (rec/tot): 85/ 208, tx: 11140182, lsn: 27F/5000CC38, prev 27F/5000CBC0, desc: HOT_UPDATE off 3 xmax 11140182 flags 0x10 ; new off 4 xmax 0, blkref #0: rel 1663/7472552/7472597 blk 0 FPW
rmgr: Transaction len (rec/tot): 46/ 46, tx: 11140182, lsn: 27F/5000CD08, prev 27F/5000CC38, desc: COMMIT 2025-07-21 18:28:13.292397 CST
rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 27F/5000CD38, prev 27F/5000CD08, desc: RUNNING_XACTS nextXid 11140183 latestCompletedXid 11140182 oldestRunningXid 11140183
--观察点2：
rmgr: XLOG len (rec/tot): 51/ 171, tx: 0, lsn: 27F/58000110, prev 27F/580000D8, desc: FPI_FOR_HINT , blkref #0: rel 1663/7472552/7472597 blk 0 FPW
rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 27F/580001C0, prev 27F/58000110, desc: RUNNING_XACTS nextXid 11140183 latestCompletedXid 11140182 oldestRunningXid 11140183

off,off:

--观察点1：
rmgr: Heap len (rec/tot): 85/ 225, tx: 11140183, lsn: 27F/580003C8, prev 27F/58000390, desc: HOT_UPDATE off 4 xmax 11140183 flags 0x10 ; new off 5 xmax 0, blkref #0: rel 1663/7472552/7472597 blk 0 FPW
rmgr: Transaction len (rec/tot): 46/ 46, tx: 11140183, lsn: 27F/580004B0, prev 27F/580003C8, desc: COMMIT 2025-07-21 18:33:18.192146 CST
rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 27F/580004E0, prev 27F/580004B0, desc: RUNNING_XACTS nextXid 11140184 latestCompletedXid 11140183 oldestRunningXid 11140184
rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 27F/58000518, prev 27F/580004E0, desc: RUNNING_XACTS nextXid 11140184 latestCompletedXid 11140183 oldestRunningXid 11140184
--观察点2：

on，off:

--观察点1：
rmgr: Heap len (rec/tot): 85/ 274, tx: 11140186, lsn: 27F/58000C18, prev 27F/58000BA0, desc: HOT_UPDATE off 7 xmax 11140186 flags 0x10 ; new off 8 xmax 0, blkref #0: rel 1663/7472552/7472597 blk 0 FPW
rmgr: Transaction len (rec/tot): 46/ 46, tx: 11140186, lsn: 27F/58000D30, prev 27F/58000C18, desc: COMMIT 2025-07-21 18:40:17.638691 CST
rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 27F/58000D60, prev 27F/58000D30, desc: RUNNING_XACTS nextXid 11140187 latestCompletedXid 11140186 oldestRunningXid 11140187
rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 27F/58000D98, prev 27F/58000D60, desc: RUNNING_XACTS nextXid 11140187 latestCompletedXid 11140186 oldestRunningXid 11140187
--观察点2：
rmgr: XLOG len (rec/tot): 51/ 236, tx: 0, lsn: 27F/58000E48, prev 27F/58000DD0, desc: FPI_FOR_HINT , blkref #0: rel 1663/7472552/7472597 blk 0 FPW
rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 27F/58000F38, prev 27F/58000E48, desc: RUNNING_XACTS nextXid 11140187 latestCompletedXid 11140186 oldestRunningXid 11140187

off，on:

--观察点1：
rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 27F/58001108, prev 27F/58001090, desc: RUNNING_XACTS nextXid 11140187 latestCompletedXid 11140186 oldestRunningXid 11140187
rmgr: Heap len (rec/tot): 85/ 289, tx: 11140187, lsn: 27F/58001140, prev 27F/58001108, desc: HOT_UPDATE off 8 xmax 11140187 flags 0x10 ; new off 9 xmax 0, blkref #0: rel 1663/7472552/7472597 blk 0 FPW
rmgr: Transaction len (rec/tot): 46/ 46, tx: 11140187, lsn: 27F/58001268, prev 27F/58001140, desc: COMMIT 2025-07-21 18:44:08.550109 CST
rmgr: Standby len (rec/tot): 54/ 54, tx: 0, lsn: 27F/58001298, prev 27F/58001268, desc: RUNNING_XACTS nextXid 11140188 latestCompletedXid 11140186 oldestRunningXid 11140187; 1 xacts: 11140187
rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 27F/580012D0, prev 27F/58001298, desc: RUNNING_XACTS nextXid 11140188 latestCompletedXid 11140187 oldestRunningXid 11140188
--观察点2：

测试小结：

FPI_FOR_HINT在hintbit回写时产生，查询语句可产生FPI_FOR_HINT
无论从on or off，主为on的时候，FPI_FOR_HINT就会生产

附加知识：what is XLOG_RUNNING_XACTS
#

XLOG_RUNNING_XACTS是RM_STANDBY_ID的一种：

/*
 * XLOG message types
 */
#define XLOG_STANDBY_LOCK			0x00
#define XLOG_RUNNING_XACTS			0x10
#define XLOG_INVALIDATIONS			0x20

XLOG_STANDBY_LOCK：记录 AccessExclusiveLock 的获取和释放，用于 Standby 节点识别锁状态。

XLOG_RUNNING_XACTS： running-xacts snapshots用于构建快照，确保事务一致性

XLOG_INVALIDATIONS：INVALIDATIONS消息，用于同时效元数据信息给local backend

 * standbydefs.h
 *	 Frontend exposed definitions for hot standby mode.

RM_STANDBY_ID是专门为hot standby只读从库定义的rmgr。对于本地实例恢复、逻辑解析这些需要用到wal的场景，``RM_STANDBY_ID`本质上对他们没有意义。

测试事务提交观察wal record：

command	wal record
begin;
select * from txid_current(); –11140191
commit;	rmgr: Transaction len (rec/tot): 46/ 46, tx: 11140191, lsn: 27F/80000538, prev 27F/80000500, desc: COMMIT 2025-07-23 11:16:10.872724 CST
	rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 27F/80000568, prev 27F/80000538, desc: RUNNING_XACTS nextXid 11140192 latestCompletedXid 11140191 oldestRunningXid 11140192

事务id 本身commit or abort还是rmgr: Transaction在同步，快照通过rmgr: Standby RUNNING_XACTS 同步。

track_commit_timestamp主从不一致
#

track_commit_timestamp，startup进程会在接受到相应wal后将从库的commit ts功能激活，主要是为从库查看xid提交时间用:

/*
 * Activate or deactivate CommitTs' upon reception of a XLOG_PARAMETER_CHANGE
 * XLog record during recovery.
 */
void
CommitTsParameterChange(bool newvalue, bool oldvalue)
{
	/*
	 * If the commit_ts module is disabled in this server and we get word from
	 * the primary server that it is enabled there, activate it so that we can
	 * replay future WAL records involving it; also mark it as active on
	 * pg_control. If the old value was already set, we already did this, so
	 * don't do anything.
	 *
	 * If the module is disabled in the primary, disable it here too, unless
	 * the module is enabled locally.
	 *
	 * Note this only runs in the recovery process, so an unlocked read is
	 * fine.
	 */
	if (newvalue)
	{
		if (!commitTsShared->commitTsActive)
			ActivateCommitTs();
	}
	else if (commitTsShared->commitTsActive)
		DeactivateCommitTs();
}

track_commit_timestamp主从不一致测试，测试步骤：

初始状态，主=on，从=on 。均能使用committed_xact等函数
主=off（重启主库），从库=on（不动）。均不能使用committed_xact等函数

主库修改并重启后，从库复制依然正常，committed_xact等函数不可使用：

$ select * from pg_last_committed_xact();
ERROR: 55000: could not get commit timestamp data
HINT: Make sure the configuration parameter "track_commit_timestamp" is set on the primary server.
LOCATION: error_commit_ts_disabled, commit_ts.c:385

$ show track_commit_timestamp
-> ;
 track_commit_timestamp 
------------------------
 on
(1 row)

Time: 0.198 ms
$ \q
## pg_controldata |grep track_commit_timestamp
track_commit_timestamp setting: off

pg14+ pause recovery
#

pg14对主库参数修改导致从库宕机做了提升。当参数不满足条件时，只读从库直接宕掉改成只读从库不宕只停复制，代码见RecoveryRequiresIntParameter

Pause recovery on a hot standby server if the primary changes its parameters in a way that prevents replay on the standby (Peter Eisentraut)

Previously the standby would shut down immediately

测试pg14修改参数导致从库复制中断：

2025-07-23 19:46:31.337 CST,,,141823,,6880ca5f.229ff,14,,2025-07-23 19:41:19 CST,1/0,0,LOG,00000,"recovery has paused","If recovery is unpaused, the server will shut down.","You can then restart the server after making the necessary configuration changes.",,,"WAL redo at 281/78324BE8 for XLOG/PARAMETER_CHANGE: max_connections=2000 max_worker_processes=20 max_wal_senders=10 max_prepared_xacts=0 max_locks_per_xact=1024 wal_level=logical wal_log_hints=on track_commit_timestamp=on",,,,"","startup",,0

因为复制已经中断，去把主库的参数改回来也没有用，从库无法应用后面的变更并更新控制文件，所以只能修改从库参数并重启（log的提示也很明显了）。

小结8个参数
#

8个参数在主库被修改并重启后，均会更新本地控制文件，如果参数有变会将改变后的参数写入wal中同步给下游，下游redo这个parameter change wal record，即更新本地的控制文件，从库根据一定条件来判断主从或者其他功能是否可用。

写到控制文件中的8个参数	check	if not,standby(pg13-)	if not,standby(pg14+)
wal_level	!=minimal	无法同步，原理性问题	无法同步，原理性问题
max_connections	主<=从	hot standby宕机	hot standby停止同步
max_worker_processes	主<=从	hot standby宕机	hot standby停止同步
max_wal_senders	主<=从	hot standby宕机	hot standby停止同步
max_prepared_transactions	主<=从	hot standby宕机	hot standby停止同步
max_locks_per_transaction	主<=从	hot standby宕机	hot standby停止同步
wal_log_hints	pg_rewind前置条件（either data checksums or wal_log_hints = on）	不影响standby同步	不影响standby同步
track_commit_timestamp	打开/关闭从库的commit_ts功能	不影响standby同步	不影响standby同步

特别鸣谢：高长军高大师

PostgreSQL DDL变更的坑和巧妙方案

Sat, 19 Jul 2025 00:00:00 +0000

自行保存，随便使用，不用问我

可能更新，也可能不会更新

欢迎交流，尽量挑刺

案例-授权和walsender跑不动

Thu, 26 Jun 2025 00:00:00 +0000

现象
#

walsender LSN未推进，堆栈显示堵在pathman的invalidate_psin_entries_using_relid，relid改变，walsender cpu打满。

pstack 121327
#0 hash_seq_search (status=status@entry=0x7fffaadf8330) at dynahash.c:1441
#1 0x00002ba3b40ec728 in invalidate_psin_entries_using_relid (relid=relid@entry=42319501) at src/relation_info.c:251
#2 0x00002ba3b40ecb3d in forget_status_of_relation (relid=relid@entry=42319501) at src/relation_info.c:232
#3 0x00002ba3b40fcc96 in pathman_relcache_hook (arg=<optimized out>, relid=42319501) at src/hooks.c:934
#4 0x000000000087168a in LocalExecuteInvalidationMessage (msg=0x3a391c8) at inval.c:595
#5 0x000000000071d50e in ReorderBufferExecuteInvalidations (rb=0x1b63ff8, txn=0x1be5f58, txn=0x1be5f58) at reorderbuffer.c:2238
#6 ReorderBufferCommit (rb=0x1b63ff8, xid=xid@entry=4285897514, commit_lsn=405674661986920, end_lsn=<optimized out>, commit_time=commit_time@entry=799377897828299, origin_id=origin_id@entry=0, origin_lsn=origin_lsn@entry=0) at reorderbuffer.c:1819
#7 0x0000000000712d18 in DecodeCommit (xid=4285897514, parsed=0x7fffaadf8630, buf=0x7fffaadf87f0, ctx=0x1a359e8) at decode.c:637
#8 DecodeXactOp (ctx=0x1a359e8, buf=buf@entry=0x7fffaadf87f0) at decode.c:245
#9 0x00000000007130b2 in LogicalDecodingProcessRecord (ctx=0x1a359e8, record=0x1a35c80) at decode.c:114
#10 0x0000000000733662 in XLogSendLogical () at walsender.c:2885
#11 0x0000000000735942 in WalSndLoop (send_data=send_data@entry=0x733620 <XLogSendLogical>) at walsender.c:2287
#12 0x0000000000736692 in StartLogicalReplication (cmd=0x1846c68) at walsender.c:1213
#13 exec_replication_command (cmd_string=cmd_string@entry=0x181a288 "START_REPLICATION SLOT \"lzl_logical_rep\" LOGICAL 170F5/7C3EAE78 (\"proto_version\" '1', \"publication_names\" 'lzl_logical_rep')") at walsender.c:1640
#14 0x0000000000774e91 in PostgresMain (argc=<optimized out>, argv=argv@entry=0x1866478, dbname=0x18662b8 "lzldb", username=<optimized out>) at postgres.c:4325
#15 0x0000000000485989 in BackendRun (port=<optimized out>, port=<optimized out>) at postmaster.c:4526
#16 BackendStartup (port=0x18635b0) at postmaster.c:4210
#17 ServerLoop () at postmaster.c:1739
#18 0x0000000000702f08 in PostmasterMain (argc=argc@entry=3, argv=argv@entry=0x1814da0) at postmaster.c:1412
#19 0x000000000048660a in main (argc=3, argv=0x1814da0) at main.c:210

## 第二次执行，堆栈一致，relid改变
pstack 121327
#0 hash_seq_search (status=status@entry=0x7fffaadf8330) at dynahash.c:1441
#1 0x00002ba3b40ec728 in invalidate_psin_entries_using_relid (relid=relid@entry=26560221) at src/relation_info.c:251
#2 0x00002ba3b40ecb3d in forget_status_of_relation (relid=relid@entry=26560221) at src/relation_info.c:232
#3 0x00002ba3b40fcc96 in pathman_relcache_hook (arg=<optimized out>, relid=26560221) at src/hooks.c:934
#4 0x000000000087168a in LocalExecuteInvalidationMessage (msg=0x39f1f68) at inval.c:595
...

分析
#

relid改变说明walsender还在跑还没有死。LSN没有改变，可以分析LSN的位置，看看这个事务在做什么。

当时的信息还在的话，可以通过slot视图查restart LSN反查wal的位置。如果当时的信息不在，可以通过stack中的LSN来找到wal日志是哪个。

pg_waldump查看wal日志信息，过滤xid

rmgr: Heap len (rec/tot): 961/ 961, tx: 4285897514, lsn: 170F5/7DFE3470, prev 170F5/7DFE3430, desc: UPDATE+INIT off 2 xmax 4285897514 flags 0x00 ; new off 1 xmax 0, blkref #0: rel 1663/17662/1259 blk 8443, blkref #1: rel 1663/17662/1259 blk 7327

...
rmgr: Transaction len (rec/tot): 1778325/1778325, tx: 4285897514, lsn: 170F5/7E1F4268, prev 170F5/7E1F4220, desc: COMMIT 2025-05-01 09:24:57.828299 CST; inval msgs: catcache 22 catcache 22 catcache 22 catcache 22 catcache 50 catcache 49 catcache 50 catcache 49 catcache 50 catcache 49 catcache 50 catcache 49 catcache 50 catcache 49 catcache 50 
...
 relcache 48813261 relcache 48813255 relcache 51030741 relcache 48813252 relcache 50737247 relcache 48813246 relcache 48813243 relcache 48813237 relcache 50737241 relcache 48813234 relcache 48813224 relcache 49379811 relcache 48813216 relcache 48813210 relcache 45452775

rel 1663/17662/1259的record有18万条，最后一条record是inval msgs，catcache有7万，relcache 3万。

rel 1663/17662/1259是pg_class，通过xmin去查pg_class可以找到对应的表和xid提交时间：

select xmin,xmax,pg_xact_commit_timestamp(xmin),relname from pg_class where xmin='4285897514'::xid order by relname desc ;
 xmin | xmax | pg_xact_commit_timestamp | relname 
------------+------+-------------------------------+---------------------------------------------
 4285897514 | 0 | 2025-05-01 09:24:57.828299+08 | v$session
 4285897514 | 0 | 2025-05-01 09:24:57.828299+08 | tmp_20230801_id_seq
 4285897514 | 0 | 2025-05-01 09:24:57.828299+08 | tmp_20230801
 4285897514 | 0 | 2025-05-01 09:24:57.828299+08 | test_param
 4285897514 | 0 | 2025-05-01 09:24:57.828299+08 | test_20240105
 ...
 
 select count(*) from pg_class where xmin='4285897514'::xid ;
 count 
-------
 18523

 select count(*) from pg_class ;
 count 
--------
 139138

通过时间去查pglog日志：

2025-05-01 09:24:59.837 CST,"postgres","lzldb",61418,"[local]",6812cd65.efea,3,"DO",2025-05-01 09:24:53 CST,549/0,0,LOG,00000,"duration: 6036.275 ms statement: 
...
 EXECUTE 'GRANT SELECT ON ALL TABLES IN SCHEMA public TO r_lzldbdata_qry';
...
 END;
 $$",,,,,,,,,"psql","client backend"

基本可以定位是这个授权引起，因为授权会更新pgclass中的relacl，至少更新了1.8w个relation的权限，pgclass更新会触发invalidation消息，大量的invalidation消息在walsender进程中处理缓慢。

复现
#

--建逻辑复制链路，随便来个
select pg_create_logical_replication_slot('logical_test','test_decoding');
pg_recvlogical -h 127.0.0.1 -p 7997 -d lzldb -U repuser --slot=logical_test --start -f recv.sql &

--建多张表
DO $$
BEGIN
 FOR i IN 1..20000 LOOP
 EXECUTE format(
 'CREATE TABLE IF NOT EXISTS table_%s ( 
 col1 varchar(10)
 )', 
 lpad(i::text, 5, '0') -- 生成5位数字编号的表名
 );
 END LOOP;
END $$;

--一次授权
grant select on all tables in schema public to r_lzldb_qry;

--完美复现
postgres@lzlhost:~/lzl/grant]$ pstack 172862
#0 hash_seq_search (status=status@entry=0x7ffd664be280) at dynahash.c:1444
#1 0x00002ad31235e728 in invalidate_psin_entries_using_relid (relid=relid@entry=1002857) at src/relation_info.c:251
#2 0x00002ad31235eb3d in forget_status_of_relation (relid=relid@entry=1002857) at src/relation_info.c:232
#3 0x00002ad31236ec96 in pathman_relcache_hook (arg=<optimized out>, relid=1002857) at src/hooks.c:934
#4 0x000000000087168a in LocalExecuteInvalidationMessage (msg=0x2ad3c3f61a88) at inval.c:595
#5 0x000000000071d50e in ReorderBufferExecuteInvalidations (rb=0x17e5698, txn=0x180d698, txn=0x180d698) at reorderbuffer.c:2238


[postgres@lzlhost:~/lzl/grant]$ pstack 172862
#0 0x0000000000891d0c in hash_seq_search (status=status@entry=0x7ffd664be280) at dynahash.c:1441
#1 0x00002ad31235e728 in invalidate_psin_entries_using_relid (relid=relid@entry=1011110) at src/relation_info.c:251
#2 0x00002ad31235eb3d in forget_status_of_relation (relid=relid@entry=1011110) at src/relation_info.c:232
#3 0x00002ad31236ec96 in pathman_relcache_hook (arg=<optimized out>, relid=1011110) at src/hooks.c:934


--relid在动
--cpu打满:
ps -eo pid,%cpu,%mem|grep 172862
172862 99.3 0.0

--运行2h左右追平

without pathman加速walsender解析
#

因为库里面是没有用pathman分区表的，但有pathman extension，所以尝试绕过pathman hook以加速walsender解析过程。

drop extension pg_pathman;
grant update on all tables in schema public to r_lzldb_upd;

[postgres@lzlhost~/lzl/grant]$ pstack 133460
#0 hash_seq_search (status=status@entry=0x7ffe292d5c90) at dynahash.c:1418
#1 0x000000000087f228 in RelfilenodeMapInvalidateCallback (arg=<optimized out>, relid=1034036) at relfilenodemap.c:64
#2 0x000000000087168a in LocalExecuteInvalidationMessage (msg=0x2b9699795768) at inval.c:595
#3 0x000000000071d50e in ReorderBufferExecuteInvalidations (rb=0x195a358, txn=0x1a6ff38, txn=0x1a6ff38) at reorderbuffer.c:2238
#4 ReorderBufferCommit (rb=0x195a358, xid=xid@entry=328684387, commit_lsn=8016890875224, end_lsn=<optimized out>, commit_time=commit_time@entry=799851538975691, origin_id=origin_id@entry=0, origin_lsn=origin_lsn@entry=0) at reorderbuffer.c:1819

## 20s以内完成

没有注释shared_preload_libraries中的pg_pathman，同样有很好的效果，walsender从2小时缩短到20s。

这里感觉挺奇怪，没有注释shared_preload_libraries，hook应该还是要走的。分析源码发现，之所以有效果是因为hook的第一步就有pathman config表的判断，不会再走pathman中的invalidate逻辑了，所以很快可以执行完成：

/*
 * Invalidate PartRelationInfo cache entry if needed.
 */
void
pathman_relcache_hook(Datum arg, Oid relid)
{
	Oid pathman_config_relid;

	/* See cook_partitioning_expression() */
	if (!pathman_hooks_enabled)
		return;

	if (!IsPathmanReady())
		return;

...

	/*
	 * Invalidation event for PATHMAN_CONFIG table (probably DROP EXTENSION).
	 * Digging catalogs here is expensive and probably illegal, so we take
	 * cached relid. It is possible that we don't know it atm (e.g. pathman
	 * was disabled). However, in this case caches must have been cleaned
	 * on disable, and there is no DROP-specific additional actions.
	 */
	pathman_config_relid = get_pathman_config_relid(true);
	if (relid == pathman_config_relid)
	{
		delay_pathman_shutdown();
	}

	/* Invalidation event for some user table */
	else if (relid >= FirstNormalObjectId)
	{
		/* Invalidate PartBoundInfo entry if needed */
		forget_bounds_of_rel(relid);

		/* Invalidate PartStatusInfo entry if needed */
		forget_status_of_relation(relid);

		/* Invalidate PartParentInfo entry if needed */
		forget_parent_of_partition(relid);
	}
}

get_pathman_config_relid获取了pathman_config表，drop extension pg_pathman把db中pathman_config表删掉了，所以源码就不会走forget那一堆逻辑。

也有其他办法可以加速walsender解析，比如将pg_pathman.enable=off，会走if (!IsPathmanReady())直接return。或者最直接的注释shared_preload_libraries中的pg_pathman并重启实例（这是实例级不是db级）。

pg14的提升
#

pg14.0 release note:

Allow logical decoding to more efficiently process cache invalidation messages (Dilip Kumar) This allows logical decoding to work efficiently in presence of a large amount of DDL.

https://www.postgresql.org/docs/release/14.0/

patch:

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=d7eb52d71

pg14ReorderBufferAddInvalidations的注释：

We require to record it in form of the change so that we can execute only the required invalidations instead of executing all the invalidations on each CommandId increment.

对比pg14和pg13，ReorderBufferCommit逻辑大改

13中处理事务的逻辑直接放在commit函数里ReorderBufferCommit

				case REORDER_BUFFER_CHANGE_INTERNAL_COMMAND_ID:
					Assert(change->data.command_id != InvalidCommandId);

					if (command_id < change->data.command_id)
					{
						command_id = change->data.command_id;

						if (!snapshot_now->copied)
						{
							/* we don't use the global one anymore */
							snapshot_now = ReorderBufferCopySnap(rb, snapshot_now,
																 txn, command_id);
						}

						snapshot_now->curcid = command_id;

						TeardownHistoricSnapshot(false);
						SetupHistoricSnapshot(snapshot_now, txn->tuplecid_hash);

						/*
						 * Every time the CommandId is incremented, we could
						 * see new catalog contents, so execute all
						 * invalidations.
						 */
						ReorderBufferExecuteInvalidations(rb, txn);
					}

14中的主要逻辑是ReorderBufferReplay->ReorderBufferProcessTXN

在ReorderBufferProcessTXN中新增case REORDER_BUFFER_CHANGE_INVALIDATION判断以执行ReorderBufferExecuteInvalidations执行reorderbuffer中的invalidate

				case REORDER_BUFFER_CHANGE_INVALIDATION:
					/* Execute the invalidation messages locally */
					ReorderBufferExecuteInvalidations(
													 change->data.inval.ninvalidations,
													 change->data.inval.invalidations);
					break;

ReorderBufferExecuteInvalidations之后的逻辑都差不多，没有多大变动。13对比14的ReorderBufferCommit主要差异：

ReorderBufferCommit不再是主要process txn的函数，调用栈更深
新增case REORDER_BUFFER_CHANGE_INVALIDATION判断，与REORDER_BUFFER_CHANGE_INTERNAL_COMMAND_ID标识区分，单独处理invalidation
移除以每个command_id处理invalidation的逻辑

根因和解决办法
#

walsender卡住的根因是有批量授权任务，导致pg_class多个元组更新，触发大量invalidation消息。GRANT privs ON ALL TABLES IN SCHEMA public TO role1 这样的授权语句在pg中是1个事务多个command处理的，而pg13 逻辑复制处理invalidation message时，会通过每个command去处理一次reorder buffer invalidate，并处理各个hook的inval hash表。在这个场景中，pathman hook在处理inval hash表较慢，从而导致复制延迟。

pathman处理较慢的触发条件（且）：

pg13-
批量授权
安装了pathman extension（无论是否使用）
逻辑复制链路

即使将pathman干掉，也会在RelfilenodeMapInvalidateCallback等函数上花较多cpu。pg13目前测下来，有pathman对比没有pathman，处理时间是小时级和分钟级的差距。

其他未测试但社区提及的场景（且）：

pg13-
批量DDL/TRUNCATE/DCL/DROP PUBLICATION
逻辑复制链路

短期解决办法：如果没有用到pathman表的，可以drop extension或者不加载pathman so；重启链路

长期解决办法：升级到pg14+（已测试非常快无延迟）

#

ref
#

https://www.postgresql.org/message-id/flat/17716-1fe42e7b44fc2f25%40postgresql.org

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=d7eb52d71

Linux内存进阶

Thu, 19 Jun 2025 00:00:00 +0000

（内存基础知识参考 linux内存浅析，本篇只有其上的内存知识）

内存基本概念
#

buddy
#

buddy系统申请和合并page的过程，略。

容易忽略的知识点：

buddy合并2个同大小块的前提它俩的物理地址连续
合并算法是迭代的，本级合并后会自行尝试合并更大的块。也就是说可以不依赖compactd来处理合并

page table & PTE
#

page table和PTE其实是两个不同的概念，十分容易混淆，因为他们总体还是在说页表。以下是page table和PTE的相关知识¹

PTE存储了页框的物理地址
“page table”和“Page Table”是不同的概念，“page table”指保持线性地址和物理地址之间映射的页，“Page Table”是上层页表中的页
pte_t、pmd_t、pud_t、pgd_t 分别描述页表项、页中间目录项、页上级目录项、页全局目录项
PTE是Page Table Entry

如果只是看MMU缓存虚拟内存到物理内存映射区pagetable大小，把pagetable和PTE混淆差别不大；如果要深入到页表目录，需要将两个概念分开。

TLB
#

每一级的页表是存储在内存里的，在完成一次虚拟内存地址转换的过程中，需要把当前虚拟地址对应的四个页表全部找出来，才能完成从虚拟地址到物理地址的转换。说明一次内存IO仅虚拟地址到物理地址的转换就要区内存查4次页表。Translation Lookaside Buffers，就是专门用于加速虚拟地址到物理地址转换速度的缓存。

关于TLB的位置，它通常位于L1缓存中（也有说在寄存器orL2的，应该跟cpu架构有关系，权且就当成cpu缓存，与主存区分）²：

在现代处理器中，L1缓存通常被划分为多个部分，包括数据缓存dTLB、指令缓存iTLB。频繁地修改页表会导致导致访问主存次数增加，这会使CPU频繁地刷新TLB缓存 ¹。TLB也是有大小的，提升TLB的命中率可以减少对主存pagetable的访问。使用大页可以降低PTE三个数量级，TLB Miss会大大降低。³。

TLB的信息：

#cpuid -l
 L1 TLB/cache information: 2M/4M pages & L1 TLB (0x80000005/eax):
 L1 TLB/cache information: 4K pages & L1 TLB (0x80000005/ebx):
...
 L2 TLB/cache information: 2M/4M pages & L2 TLB (0x80000006/eax):

观察TLB命中率:

perf stat -e dTLB-loads,dTLB-load-misses,iTLB-loads,iTLB-load-misses -I 10000 -p $PM_PID 

在内存回收时，观察TLB missing确实会上涨，但难以形成因果关系，TLB missing只是观察MMU的一种观测指标，TLB is part of MMU。

反向映射
#

PFRA（page fram reclaiming algorithm）页框回收算法总体原则¹：

首先释放“无害”页。先回收pagecache上的无害页，这些页没有被任何进程占用
用户态进程的所有页定位可回收页。FRPA将睡眠时间较长的用户态页可逐渐失去页框
取消一个共享页框的所有页表项的映射，然后就可以回收该共享页框
只回收“未用”页

PFRA目标之一就是能释放共享页框，能快速定位指向同一页框的所有页表项的过程就叫反向映射（reverse mapping）。

Reverse mappings for shared

Anonymous pages
File-mapping pages

Basic tricks of page frame reclaiming

LRU lists
Free cheapest pages first
Unmap all at once
Etc⁴

大页
#

开启大页对特定应用的负载有一定提升。在pg中，大内存库开启大页也有一定的性能提升，甚至有一些稳定性的好处。

为什么大页更好？[^ kernel.org, Page Table Management]：

减少TLB的压力
减少pagetable在主内存上的大小
大页在物理上是连续的。连续的物理内存访问比不连续的物理内存访问更优
When using these kinds of larger pages, higher level pages can directly map them, with no need to use lower level page entries[^ kernel.org,mm pagetables]

不过使用大页会带来管理上的挑战：

需要提前分配大页
需要提前计算大页大小，以避免内存浪费

进程使用大页的两种方式：

The first is by using shmget() to setup a shared region backed by huge pages
the second is the call mmap() on a file opened in the huge page filesystem

C库和系统调用
#

内核空间和用户空间之间的中间层就是系统调用层。应用编程接口（API)和系统调用是不同的。应用程序调用用户空间的实现的应用编程接口来编程，而不是直接执行系统调用。在UNIX的世界里，最通用的系统调用层是POSIX标准(Portable Operation System Interface of UNIX)。POSIX标准针对的是API而不是系统调用。Linux操作系统的API通常以C标准库方式提供，如libc库。C标准库提供了POSIX的绝大部分API的实现。⁵

C app->C lib->system calls->OS->hardware⁶:

常见C库和系统调用：

malloc,free=>C lib

mmap、brk、munmap=>系统调用

缺页异常
#

缺页异常（or缺页中断）需要区分两种情况：由编程错误所引起的异常；用虚拟地址空间但尚未分配物理页框所引起的分配物理页的行为。¹

异常的缺页：Segment Fault——每个虚拟内存区域具有相关权限。如果一个进程访问了不在有效范围内的内存区域，或者非法访问了内存区域，或者以不正确的方式访问了内存区域，那么处理器会报告缺页异常，严重的会报告“Segment Fault”段错误并终止进程⁵。
正常的缺页：mmap、brk等系统调用都是管理虚拟内存的，它们不直接分配物理内存。虚拟内存系统调用函数只建立进程地址空间，在用户空间里可以看到虚拟内存，但没有建立虚拟内存和物理内存直接的映射关系。当进程访问这些还没有建立映射关系的虚拟内存时，触发缺页中断。⁵

缺页类型也分两种

minor fault：没有阻塞当前进程的情况下处理了缺页，分配了页框
major fault：缺页迫使当前进程睡眠（很可能是用磁盘上的数据填充页框花费时间），阻塞当前进程缺页就是主缺页major fault¹

写时复制COW
#

当执行fork系统调用时，子进程和父进程拥有独立的进程地址空间，但是共享物理内存资源，包括进程上下文、进程栈、内存信息、文件描述符、目录、资源限制等。只需要复制父进程中页表给子进程。此时以只读方式共享，当需要写入时（运行各自的任务时），数据才会被复制，使父进程和子进程拥有各自的副本。⁵

对于PG多进程来说，fork本身不算重，可能只需要关心页表，但是fork之后到来的各种任务会发生写时复制创建子进程自己的资源副本。

注意区分写时复制和缺页异常：写时复制是说的fork时没有分配相应的资源给子进程；缺页异常是说的这个进程发生了物理内存分配，跟fork没有关系。

mmap、brk&共享内存映射区、堆区
#

mmap、brk的功能和所使用的内存地址区域是不同的：

mmap 用于管理共享内存，对应共享内存映射区
brk 用于管理私有内存，对应堆区

线性地址分区功能：

mmap ：映射区域至顶向下扩展，mmap 映射区域和堆相对扩展，直至耗尽虚拟地址空间中的剩余区域，这种结构便于C运行时库使用mmap 映射区域和堆进行内存分配。
栈区(Stack)：存储程序执行期间的本地变量和函数的参数，从高地址向低地址生长
堆区(Heap)：动态内存分配区域，通过 malloc、new、free 和delete 等函数管理
未初始化变量区(BSS)：存储未被初始化的全局变量和静态变量
数据区(Data)：存储在源代码中有预定义值的全局变量和静态变量
代码区(Text)：存储只读的程序执行代码，即机器指令。

共享内存映射区和堆区⁷ ：

真实的postmaster的堆区和共享内存映射：

cat /proc/1063005/smaps |grep -E "\-s|heap"
022a4000-022ee000 rw-p 00000000 00:00 0 [heap]
7fef6019e000-7fef601a5000 rw-s 00000000 00:17 21 /dev/shm/PostgreSQL.1291978332
7fef601a5000-7fef6098b000 rw-s 00000000 00:01 1052 /dev/zero (deleted) #这是shared buffers的
7fef6e238000-7fef6e239000 rw-s 00000000 00:01 10 /SYSV0011f702 (deleted)

可以看到heap和共享内存区的地址差不多能对上。

VM
#

linux内核virtual memory子系统

目录：cd /proc/sys/vm/

compact
#

concept & param
#

内存压缩（Compaction）是Linux内核用于解决内存碎片化问题的机制，通过合并空闲物理页，提升大块内存页的分配和压缩效率。

参数名	功能定位	默认值/范围
`compact_memory`	手动触发全局内存压缩操作	写入1触发
`compaction_proactiveness`	控制主动压缩的触发频率	4.x才有的参数。0-100（默认20）
`compact_unevictable_allowed`	是否允许压缩不可回收页（如`mlock`锁定的内存）	4.x才有的参数。0（禁止）或1（允许）
`defrag_mode`	控制内存碎片整理的触发策略	4.x才有的参数。0-3，0表示关闭自动compaction特性，只能手动压缩；1表示defer开启被动压缩。3.10默认1
`extfrag_threshold`	大块内存不足时，触发压缩的阈值	0-1000（默认500）

压缩有3种模式（跟内核版本是否支持相关）：

被动压缩：extfrag_threshold是进程申请大块内存发现已经不足是否压缩，解决“已发生”的碎片问题。
主动压缩：compaction_proactiveness是主动控制压缩的积极性，优化“未发生”但可能出现的碎片风险。
手动压缩：compact_memory。

extfrag_threshold是Linux内核中控制被动压缩的参数。当内核尝试分配高阶连续物理内存（如大页）失败时，会通过碎片化指数判断失败原因：

-1：分配成功（满足水位线）
0：因内存不足失败
1000：因碎片化失败

通过/sys/kernel/debug/extfrag/extfrag_index查看具体值，其输出为浮点数（如0.854），但实际范围被放大1000倍，例如0.854对应实际值854：

cat /sys/kernel/debug/extfrag/extfrag_index |grep Normal
Node 0, zone Normal -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 0.995 0.998 

若extfrag_threshold=600，则当碎片化指数>600时触发压缩。extfrag_index还是挺有用的，可以协助buddy观察碎片问题。

dirty
#

concept & param
#

刷脏跟内存回收有点类似，也分异步和同步：

异步刷脏：由pdflush/flush/kdmflush等后台线程执行，应用写入不受影响
同步刷脏：直接阻塞应用进程，由发起写操作的进程自己刷脏

参数名称	作用描述	默认值
dirty_background_bytes	后台异步刷脏阈值，字节	0（未启用）
dirty_background_ratio	后台异步刷脏阈值，百分比	10%
dirty_bytes	同步刷脏阈值，字节	0（未启用）
dirty_ratio	同步刷脏阈值，百分比	20-40%
dirty_expire_centisecs	脏页在内存中的最长存活时间	3000（30秒）
dirty_writeback_centisecs	内核周期性检查脏页状态的频率	500（5秒）

xxx_bytes和xxx_ratio参数互斥。

示例参数和流程图：

dirty_background_bytes 0
dirty_background_ratio 10
dirty_bytes 0
dirty_ratio 40
dirty_expire_centisecs 3000
dirty_writeback_centisecs 500

%% 整合时间参数的刷脏流程图
graph TD
 A[应用程序写入生成脏页] --> B{检查周期到达?<br>dirty_writeback_centisecs 每5秒}
 B -- 否 --> D{存在超时脏页?<br> dirty_expire_centisecs>30秒}
 B -- 是 --> C{脏页阈值检查}
 C --> E[脏页占比? dirty_background_ratio>10% ]
 C --> F[脏页占比? dirty_ratio> 40%]
 E -- 触发 --> G[后台异步刷脏]
 F -- 触发 --> H[同步刷脏]
 D -- 触发 --> G
 G --> I[脏页写入磁盘]
 H --> I[脏页写入磁盘] 
 I --> J[释放内存空间]

刷脏参数的设置跟pg刷脏参数的基本原理差不多，设置的过低刷脏过于频繁，同一个脏页可能多次写入磁盘浪费IO，过高可能会有IO风暴。

观察脏页
#

监控脏页

ps -eo pid,%cpu,%mem,wchan,args,state|grep kdmflush|grep -E -w -v "S" #观察异步刷脏进程状态
cat /proc/vmstat| grep -E -w "nr_dirty|nr_writeback" #vmstat dirty,页数
cat /proc/meminfo |grep -i dirty #meminfo dirty，kb

使用dd测试脏页

 grep -E "nr_dirty_threshold|nr_dirty_background_threshold" /proc/vmstat | awk '{printf "%s: %.2fGB\n", $1, ($2*4)/1048576}'
nr_dirty_threshold: 141.28GB
nr_dirty_background_threshold: 35.32GB

dd if=/dev/zero of=testfile bs=8k count=128000 # cache io

失败测试（测试多次仍然是这个结果）：

未见RUNNING kdmflush进程
没有满35GB，也没有满30S，脏页就被刷下去了

时间戳	nr_dirty	nr_dirty(GB)	趋势模拟
17:00:18	2,757	0.01052	▍
17:00:19	336,199	1.282	████▌
17:00:25	1,984,867	7.574	██████████████▍
17:00:32	4,252,177	16.22	████████████████████
17:00:33	3,699,227	14.11	█████████████████▊
17:00:38	170,865	0.652	▎
17:00:46	2,865,814	10.93	█████████▋
17:00:54	4,721,827	18.01	██████████████████████
17:00:55	3,876,509	14.79	██████████████████
17:01:03	835,097	3.186	██▊

os dirty !=pg dirty
#

pg fsync=on，数据写入是需要经过os pagecache然后再将指定块写入磁盘的。pg有自己的drity，os也有dirty，两者是什么关系？

## 观察语句
cat /proc/meminfo |grep -E -w "Dirty" # os脏页

select isdirty,pinning_backends,count(*) from pg_buffercache where isdirty is true group by isdirty,pinning_backends; # pg脏页

checkpoint;
begin;
--观察
insert into tlzl select generate_series(1,1000000);
--观察
commit;
--观察
checkpoint;
--观察

测试结果：

stage	dirty in pg	os dirty
干净状态	0	0.02-2M 浮动
insert完成	200M	上涨到1.7G，随后降落到20KB
commit提交	200M	0.02-2M 浮动
checkpoint刷脏	0	0.02-2M 浮动

将插入数据加大，insert时os dirty会上涨，涨到GB级再浮动。

pg dirty跟os dirty有点关系但又不全是相关的，pg插入数据时 os dirty确实会上升，不过os自己刷脏后，pg的脏页仍然是脏页。初步判断共享内存中的脏页与os dirty无关，os dirty上涨暂未判断是不是pg私有内存的脏页。

swappiness
#

控制系统从anonymous memory pool或 page cache 中回收内存的偏向性。其实是控制交换匿名页或者回收文件页，谁的代价对于上层应用来说更低。比如计算类的应用，动态分配或者私有内存使用更多，应该设置更低的swappiness，依赖数据的应用设置更高的swapiness以降低刷file page对数据访问的影响。不过这一切都建立在swap IO和filesystem IO的效率上⁸。一切都很美好，但是swap发生时很可能意味着性能降低。

swappiness=0
#

swappiness=0时，内核会直到内存到达high水位线时，才会做swap⁹。具体的策略跟内核版本和NUMA也有关系。可以确认的是swappiness=0不代表关闭了swap，swapoff -a才是关闭swap功能。

#查看是否打开了swap
swapon --show
free -h |grep Swap
cat /proc/swaps
grep -E 'swap|none' /etc/fstab
cat /proc/meminfo|grep Swap

#监控swapping是否发生
cat /proc/vmstat|grep swp
sar -W 1

inconsistent swap behavior
#

os层的 /proc/sys/vm/swappiness 对 cgroups v1 的系统的swap特性几乎没有影响（has little-to-no effect on the swap）。此问题可能导致不一致的swap行为¹⁰。

发生场景（且）：

vm.swappiness != cgroups memory.swappiness
cgroups v1

发生原因：

systemd在启动初期创建cgroups，早于sysctl.service加载/etc/sysctl.conf ，vm.swappiness 无法限制cgroup memory.swappiness。问题在于，当os的swap行为和cgroup不同时，到底哪个该生效的问题。

解决办法：

for cgroup v1，设置vm.swappiness = all cgroups memory.swappiness
for cgroup v1，很多解决办法，参考https://access.redhat.com/solutions/6785021
使用cgroup v2。v2新增vm.force_cgroup_v2_swappiness参数，使cgroup的memory.swappiness失效

memory overcommitment
#

concept & param
#

linux不是为每个虚拟地址预留物理内存，而是等到实际需要内存时才进行分配。overcommitment可以限制所有进程申请的总虚拟内存的大小，申请的内存超过限定的物理内存大小时，称为overcommit。

overcommit策略参数有三个：overcommit_memory，overcommit_ratio/overcommit_kbytes

overcommit_memory参数控制overcommitment策略：

0(默认): 启发式overcommitment策略，允许轻微的overcommit，CommitLimit=物理内存+swap 。
1: 无overcommit检查
2: 严格限制，禁止超过CommitLimit

graph TD
 A[内存分配请求] --> B{Overcommit模式}
 B -->|模式0:启发式| C["允许适度超分虚拟内存"]
 B -->|模式1:无限制| D["虚拟内存承诺无约束"]
 B -->|模式2:严格限制| E["虚拟内存总量≤CommitLimit"]
 C --> F[运行时按需分配物理页]
 D --> G[可能耗尽物理内存+Swap]
 E --> H[强制虚拟内存总量控制]

当overcommit_memory=2时，overcommit_ratio和overcommit_kbytes参数只有一个会生效，此时的CommitLlimit计算如下： $$ CommitLimit = (RAM - 大页内存) × \frac{overcommit_ratio}{100} + SwapTotal $$ or $$ CommitLimit = (RAM - 大页内存) + overcommit_kbytes + SwapTotal $$ 有点意思的overcommit accounting¹¹,mmap、brk、fork都计算在内，明显对pg是有影响的：

Status
------
o	We account mmap memory mappings
o	We account mprotect changes in commit
o	We account mremap changes in size
o	We account brk
o	We account munmap
o	We report the commit status in /proc
o	Account and check on fork
o	Review stack handling/building on exec
o	SHMfs accounting
o	Implement actual limit enforcement

reserve内存和overcommmit
#

user_reserve_kbytes ：在overcommit_memory=2时，为普通用户进程预留的物理内存，在系统内存严重不足时，确保普通用户仍能执行基本操作（如启动新进程、处理内存分配请求）。默认值为 min(3% of the current process size, 128M)。当设置为0时，单个进程可以分配（所有空闲内存-admin_reserve_kbytes）

admin_reserve_kbytes：为具备 CAP_SYS_ADMIN 权限的用户（通常是 root 用户）保留的物理内存，确保管理员恢复能力，确保系统管理员可以登陆并执行命令的保留物理内存。默认min(3%内存, 8MB)。严格限制overcommit模式时最好提高该参数。

$ cat user_reserve_kbytes 
131072
$ cat admin_reserve_kbytes 
8192

观察overcommit
#

grep -E 'CommitLimit|Committed_AS' /proc/meminfo
sar -r 1

$ grep -E 'CommitLimit|Committed_AS' /proc/meminfo
CommitLimit: 203103492 kB
Committed_AS: 252170700 kB

$ sar -r 1
07:32:35 PM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty
07:32:37 PM 25472180 370249056 93.56 14588 274485956 252242936 62.91 233866528 103568816 12924
07:32:38 PM 25471904 370249332 93.56 14588 274487888 252242740 62.91 233851748 103570136 11180

观测指标含义：

meminfo CommitLimit：由物理内存、Swap及overcommit参数共同计算得出的CommitLimit
meminfo Committed_AS：当前所有进程已申请的虚拟内存总量
sar -r kbcommit = Committed_AS
sar -r %commit =kbcommit/总物理内存

smaps或者status也可以查看总申请的虚拟内存，但直接算smaps/status的总计虚拟内存重复计算了共享库文件，映射文件（如mmap），而Committed_AS 仅统计mmap、brk、fork等申请的内存，且不会重复计算共享内存。两者计算口径不同，看总虚拟内存还是看Committed_AS或者kbcommit就行。

watermark
#

参数名称	作用描述	引入版本	默认值	单位/范围
min_free_kbytes	定义系统保留的最小空闲内存量，直接影响内存水位 `watermark[min]` 的计算，确保系统在内存紧张时保留足够内存供关键操作使用	早期内核版本		KB
watermark_scale_factor	全局调节内存水位线间距（`high-low` 和 `low-min`）	Linux 内核4.x（4.几未知）	`10`（ 0.1%物理内存）	最大`3000`（30%物理内存）
watermark_boost_factor	临时提升内存高水位线（`high`），触发积极内存回收以减少碎片化	Linux 内核4.x（4.几未知）	`15000`（即 1.5 倍原始高水位线）

min_free_kbytes
#

## 从zoneinfo中计算zone的总min等值
cat /proc/zoneinfo | grep -E -w "min|low|high"|grep -E -v "high:"| awk '
/min/ { total_min += $2 }
/low/ { total_low += $2 }
/high/ { total_high += $2 }
END {
 printf "总min: %d KB\n总low: %d KB\n总high: %d KB\n",
 total_min * 4, total_low * 4, total_high * 4;
}'
总min: 15828844 KB
总low: 19786048 KB
总high: 23743260 KB

#当前系统min值
cat min_free_kbytes
15828849

因为有其他zone，所有zone的总min加起来才差不多min_free_kbytes。Normal zone的min肯定比min_free_kbytes小一点点，只需要关注Normal zone就行了：

## Normal zone的min、low、high设置；page=4k
cat /proc/zoneinfo | grep -A 50 Normal | grep -E "min|low|high"
 min 3931615
 low 4914518
 high 5897422

在Linux 内核4.6前，min、low、high是固定比例，只能通过设置min_free_kbytes来改变low、high的值，min：low：high=1：1.25：1.5。

固定比例的问题：

本身应该提高low积极触发kswapd异步回收，降低min减少direct reclaim。在4.6前只能通过调整min来间接调整low/high，通过调整min来调整kswapd的delta工作缓冲。例如

	kswapd异步回收工作缓冲（low-min）	kswapd异步回收工作量（high-low）
min=1GB，low=1.25GB，high=1.5GB	0.25GB	0.25GB
min=10GB，low=12.5GB，high=15GB	2.5GB	2.5GB

提高min是为了提高low和high。

过低的min值，会导致kswapd还没来得及异步回收更多的内存，direct reclaim就触发了。过高的min，不仅浪费了内存，也会导致内存回收动作更频繁，sys cpu会更多。Linux中默认的low与min之间的差值确实显得小了点。

watermark_scale_factor
#

如果可以直接调整min、low、high不是美滋滋吗？抱歉，linux内核没有（安卓有extra_free_kbytes）。但是，

linux4.x内核以后新增watermark_scale_factor参数可以调节参数之间的比例，比例不再是固定的了。其默认值为10，对应内存占比0.1%(10/10000)，最大为3000。当它的值被设定为1000时，意味着"low"与"min"之间的差值，以及"high"与"low"之间的差值都将是内存大小的10%(1000/10000)。

0.1%明显是小了，1T的内存，scale才1GB。

watermark_boost_factor
#

watermark_boost_factor 用于优化内存外碎片化。它临时提高内存管理区的水位，即 zone->watermark_boost 从而提高内存管理区的高水位（ WMARK_HIGH），这样 kswapd 可以回收更多内存，内存规整模块（ compactd 内核线程）就比较容易合并大块的连续物理内存。 watermark_boost_factor 的默认值是 15000，表示会临时把原来的高水位提升到 150%。若把这个值设置为 0，则关闭临时提高内存管理区水位的机制¹²

oom
#

OOM Killer 是内核模块不是一个进程。

参数名称	作用描述	默认值
panic_on_oom	控制OOM发生时系统行为： 0: 不触发panic，启动OOM Killer 1: 触发panic并停机 2: 触发panic后尝试内存释放	0
oom_kill_allocating_task	是否优先杀死触发OOM的进程（而非遍历进程树选择最优目标）： 0: 禁用 1: 启用	0
oom_dump_tasks	OOM发生时是否转储所有任务信息（用于事后分析）： 0: 禁用 1: 启用	1

oom_score
#

oom发生时，系统需要通过oom score决定要kill哪个进程。每个用户进程都有3个oom score接口文件

-rw-r--r-- 1 postgres postgres 0 May 24 16:39 /proc/63766/oom_adj
-r--r--r-- 1 postgres postgres 0 May 24 16:39 /proc/63766/oom_score
-rw-r--r-- 1 postgres postgres 0 May 24 16:39 /proc/63766/oom_score_adj

oom_score是系统自动计算的动态oom分数，至少受以下影响：

很多子进程的 +分
运行很长时间的 -分
low nice value +分 (nice value代表进程的cpu时间片优先级。nice值越低，优先级越高，CPU时间片分配更多)
直接访问硬件的 -分¹³

除了linux自己算的oom分数，还可以自行调整（adj）oom分数。oom_adj是linux内核早期版本的，最好通过调整oom_score_adj接口文件来调整adj score。

参数/文件	作用	示例值
oom_score	内核计算的原始评分（动态变化）	0~1000
oom_score_adj	用户自定义调整值，直接影响最终评分	-1000~1000；-1000等价于禁用OOM
oom_adj（旧版）	旧版调整参数，范围-17~15	-17~15

lowmem_reserve_ratio
#

除了min_free_kbytes，还有一个最低内存保留参数，会可能导致进程申请内存失败，但他们功能有较大差别。

lowmem_reserve_ratio 是一个用于保护低端内存（DMA、DMA32）不被高端内存分配请求过度占用键内核参数。lowmem_reserve_ratio只是一个系数，并不是直接可用的数，内核会计算每个zone的保留页数。

#下面默认值
cat /proc/sys/vm/lowmem_reserve_ratio 
256 256 32

内存区域（zone）按优先级从低到高排列：DMA → DMA32 → Normal → HighMem。高优先级区域的分配请求可“借用”低优先级区域的内存，但需按比例保留一定内存供低优先级区域使用。

cat /proc/zoneinfo |grep -Ew "Node 0|protection|free"
Node 0, zone DMA
 pages free 3976
 protection: (0, 2484, 386430, 386430)
Node 0, zone DMA32
 pages free 415741
 protection: (0, 0, 383946, 383946)
Node 0, zone Normal
 pages free 5658528
 protection: (0, 0, 0, 0)

例如DMA的 protection 表示：

0:本区分配，没有跨区分配的限制
2484：DMA为来自DMA32区域保留的页数。
386430：DMA为来自Normal区域保留的页数
386430：保留扩展字段，此场景中无意义

以上设置

当DMA32区申请DMA区的内存时，3976>2484，是有可能成功的
当Normal区申请DMA区的内存时，3976<386430，是不会成功的
地区向高区申请内存，不会受到该限制

misc
#

还有一丢丢相关的参数，关系不大的没有列举

参数	作用
nr_hugepages	大页数
~~nr_overcommit_hugepages~~	大页的overcommit；The maximum is nr_hugepages + nr_overcommit_hugepages
~~nr_hugepages_mempolicy~~	NUMA本地化大页分配
~~hugetlb_shm_group~~	共享内存权限控制
~~hugetlb_optimize_vmemmap~~	重构大页元数据管理模型，减少大页元数据（struct page）的内存占用。linux 内核5.13开始支持
max_map_count	限制单个进程可拥有的内存映射区域（VMA）的最大数量，默认65530
zone_reclaim_mode	NUMA下内存回收策略，例如从其他节点分配内存
stat_interval	vm stat刷新频率，默认1秒
vfs_cache_pressure	虚拟文件系统（VFS）缓存回收压力的参数，主要影响内核回收dentry、inode缓存的积极性
page-cluster	swap readahead，一次交换多个page到swap分区。默认3，即一次8个pages

OS内存的观测和计算
#

/proc/meminfo，/proc/vmstat，/proc/zoneinfo中都有内存信息，很多信息还是重复的。差异就不列举了没啥意思，看一眼就知道了。

free available的计算（未完成）
#

大体方向：(NR_FREE_PAGES+NR_FILE_PAGES-NR_SHMEM+NR_SWAP_PAGES+NR_SLBA_RECLAIMABLE-TOTALRESERVE_PAGES-root预留内存)

内核有估算可用内存，直接用公式计算available有点难计算出准确的值：

## 不太准确，别用
cat /proc/meminfo |grep -Ew "MemFree|Active\(file\)|Inactive\(file\)|SwapFree|SReclaimable|nr_shmem|Shmem" |awk 'NR==1 {a=$2} NR==2 {b=$2} NR==3 {c=$2} NR==4 {d=$2} NR==5 {e=$2} NR==6 {f=$2 ;print (a+b+c+d-e+f)}' ;
cat /proc/meminfo |grep -Ew "MemAvailable";

inactive_anon+active_anon != anon
#

why？

主要：Shmem 会单独统计共享内存的页数。nr_anon_pages 未包含共享内存页，而 nr_inactive_anon 和 nr_active_anon包含匿名共享内存页
次要：anon包含部分Unevictable （Mlocked又是Unevictable的子集）
其他统计口径差异影响不大

粗糙但比较准确的算法：nr_inactive_anon +nr_active_anon +nr_unevictable -nr_shmem

## 大页下适用；numa下不适用
## /proc/meminfo,/proc/zoneinfo,/proc/vmstat都可以计算

#/proc/vmstat
echo -n "anon_computed : ";cat /proc/vmstat|egrep -w "nr_inactive_anon|nr_active_anon|nr_unevictable|nr_shmem"| awk 'NR==1 {a=$2} NR==2 {b=$2} NR==3 {c=$2} NR==4 {d=$2; print (a+b+c-d)}' ;\
echo -n "anon_real : ";cat /proc/vmstat|egrep -w "nr_anon_pages"|awk '{print $2}'
anon_computed : 15776924
anon_real : 15772671

##/proc/zoneinfo Normal
echo -n "anon_normal_computed : "; cat /proc/zoneinfo |grep Normal -A 50|egrep -w "nr_inactive_anon|nr_active_anon|nr_unevictable|nr_shmem"| awk 'NR==1 {a=$2} NR==2 {b=$2} NR==3 {c=$2} NR==4 {d=$2; print (a+b+c-d)}' ;\
echo -n "anon_normal_real : "; cat /proc/zoneinfo |grep Normal -A 50|egrep -w "nr_anon_pages"|awk '{print $2}'
anon_normal_computed : 15711170
anon_normal_real : 15707402

cache的计算
#

free命令中的buff/cache，可以通过文件页或者cache本身计算出来

echo -n "filepage+shmem: ";cat /proc/meminfo |grep -Ew "Buffers|Active\(file\)|Inactive\(file\)|Shmem|SReclaimable"| awk 'NR==1 {a=$2} NR==2 {b=$2} NR==3 {c=$2} NR==4 {d=$2} NR==5 {e=$2 ;print (a+b+c+d+e)}';\
echo -n "cached: ";cat /proc/meminfo |grep -Ew "Buffers|Cached|SReclaimable" | awk 'NR==1 {a=$2} NR==2 {b=$2} NR==3 {c=$2 ;print (a+b+c)}';\
free -k;

#执行结果：
filepage+shmem: 289417584
cached: 289419156
 total used free shared buff/cache available
Mem: 395721236 79633516 26668564 84704912 289419156 178501152
Swap: 5242876 0 5242876

争议：shmem算不算cache？
#

很明显，上面在计算cache的时候，把shmem也算进去了。shmem理论上应该不属于cache的部分

实际上内核社区也讨论过这个事情Why is Shmem included in Cached in /proc/meminfo?，想把共享内存从cache中抛出去：

> -	cached = global_node_page_state(NR_FILE_PAGES) -
> -			total_swapcache_pages() - i.bufferram;
> +	cached = global_node_page_state(NR_FILE_PAGES) -
> +			total_swapcache_pages()
> +			- i.bufferram - i.sharedram;

但是修改这个东西涉及向前兼容，问题就归结于向前兼容和修改一个信息表达的准确性谁更重要？

目前来看没有一个好的解决，反正现状就是这样了。

这个邮件还讨论到一些有意思的东西：

Another point of view is that everything in tmpfs is part of the page
cache and can be written out to swap

- Dirty: total amount of RAM used to buffer data to be written on
permanent storage (dirty). Gets converted to Cached when write is
complete. (Actually I would call this "Buffers" but Dirty is okay, too.)
- Cached: total amount of RAM used to improve *performance* that can be
*immediately dropped* without any data-loss – note that this includes
all untouched RAM backed by swap.
- Shared: total amount of RAM shared between multiple process that
cannot be freed even if any single process gets killed. (If this is even
possible to know - note that this would *only* contain COW pages in
practice. We already have Committed_AS which is about as good for real
world heuristics.)

cache是不包含dirty的，可以直接drop不会造成数据丢失
tmpfs是swapout

共享内存看上去是swapout，明显跟cache page可以直接drop的性质是不同的。pg的共享内存明显不可以直接drop。

所以对于pg来说，cache有共享内存一点，还是很重要的，不要默认以为没有。

内存页统计数据老对不上
#

计算内存页的时候，有些计算对不上，汇总原因如下：

shmem算到cache中
看不到shmem中的文件映射和匿名映射pages
nr_anon_pages 未包含共享内存页，而 nr_inactive_anon 和 nr_active_anon包含匿名共享内存页
vm和cgroup的统计口径略有差别

cgroup v1
#

cgroup 内存管理
#

cgroup可以观察和限制匿名页，文件页，swap cache，kernel mem的使用情况。每个memcg都有独立的LRU，没有GLOBAL LRU的概念。

cgroup内存管理不同于cgroup cpu管理，1个任务可以申请很多cpu工作，达到cg cpu上线可延长执行时间来处理，但是这个任务占用的内存是工作内存，一个任务使用相同的物理内存。

cgroup管理cpu和内存的重要区别：

内存必须通过复用和回收来管理，一个任务的工作内存是真实占用的不可被其他任务使用的；CPU通过时间分配来管理，其他任务或cg组可以用到
内存需要即时可用，CPU通过时间片轮转，时间可以分散
CPU control的核心是时间分配；Memory Control的核心是page计数

The core of the design is a counter called the page_counter. The page_counter tracks the current memory usage and limit of the group of processes associated with the controller

Memory Control的核心是page计数，也就是说不是物理page分这些就是这些，这次申请的内存使用完后释放回free，下次申请基本上不会是同一个物理page¹⁴。

物理page知道自己属于哪个cgroup：

				+--------------------+
				| mem_cgroup |
				| (page_counter) |
				+--------------------+
				 / ^ \
				/ | \
 +---------------+ | +---------------+
 | mm_struct | |.... | mm_struct |
 | | | | |
 +---------------+ | +---------------+
 |
 + --------------+
 |
 +---------------+ +------+--------+
 | page +----------> page_cgroup|
 | | | |
 +---------------+ +---------------+

mm_struct代表虚拟内存。每个虚拟内存都知道自己属于哪个cgroup；每个物理page都可以指向page_cgroup，即知道这个物理内存属于哪个cgroup¹⁴。

cgroup 参数和指标
#

cgroup通过接口文件配置和查看内存使用情况。

目录：cd /sys/fs/cgroup/memory/xxx/

内核内存和mem+swap可以单独设置或查看使用上限和使用情况：

memory.kmem.xxx #kernel mem
memory.memsw.xxx #mem+swap

以下只看mem相关的。

接口文件可分为三类：

只读-显示使用情况，权限:-r--r--r--
读写-控制参数，权限:-rw-r--r--
其他-特殊设置，权限:其他

具体含义如下，重要参数标出：

type	接口文件	含义
只读	`memory.numa_stat`	numa维度mem stat
只读	`memory.stat`	重要，是主要的内存使用情况接口文件，有很多指标，下面单独分析
只读	`memory.usage_in_bytes`	usage_in_bytes is affected by the method and doesn’t show ’exact’ value of memory。不建议使用该文件查看cgroup的内存使用情况
只读	`memory.failcnt`	内存使用量超过`memory.limit_in_bytes`的次数，累计值
读写	`cgroup.clone_children`	控制子 cgroup 是否继承父级配置
读写	`cgroup.procs`	用于管理当前 cgroup 中的进程组（进程 ID，PID）。对于多进程的pg来说，就是把pg的所有进程，包括管理进程和backend都写入`procs`文件
读写	`tasks`	用于管理当前 cgroup 中的线程（线程 ID，TID）。将进程 PID 写入 `cgroup.procs` 时，其所有线程 TID 会自动添加到 `tasks`
读写	`notify_on_release`	控制当 cgroup 中的最后一个任务（进程或线程）退出时，是否触发释放操作。容器管理才有可能打开，传统的cgroup管理默认都是关闭，数据库重启cgroup还是要保留的
读写	memory.move_charge_at_immigrate	v2已启用该参数。迁移croup时charge归属规则
读写	memory.use_hierarchy	父cgroup是否限制子cgroup
读写	memory.limit_in_bytes	cgroup内存上限
读写	memory.soft_limit_in_bytes	内存超限时回收超限的部分
读写	memory.max_usage_in_bytes	cgroup使用峰值，属于观察指标
读写	memory.oom_control	oom_kill_disable 1–禁用oom under_oom 0是否处于OOM状态
读写	memory.swappiness	cg级别的swappiness
其他	memory.force_empty	仅写入，写入 `0` 强制释放cgroup所有内存
其他	cgroup.event_control	事件通知接口，监听内存压力事件，需编程实现。常与memory.pressure_level配合使用
其他	memory.pressure_level	内存压力通知级别

通过一个pg实例来看memory.stat中各个指标的含义。

这个pg实例配置为：

shared_memory_type=mmap
shared_buffers=64GB
clients 800个左右，running

cat memory.stat

cache 345587761152 						 #page cache！！！
rss 27332608 #匿名和swap cache内存大小，注意，跟OS的进程rss不同，这里明显不包含PG的共享内存
rss_huge 0 #of bytes of anonymous transparent hugepages，注意是匿名大页
mapped_file 61491769344 # 文件共享内存大小，这里包含pg的共享内存
swap 0 # swap分区上的
pgpgin 389395357 # rss+cache的charge pages
pgpgout 305016672 # rss+cache的uncharge pages
pgfault 1954040341 # 略
pgmajfault 17 # 略
inactive_anon 165728256 # anonymous and swap cache memory on inactive LRU
active_anon 61549518848 # anonymous and swap cache memory on active LRU list
inactive_file 138240962560 # file-backed on inactive LRU list
active_file 145658613760 # file-backed memory on active LRU list
unevictable 0 # 无法回收的内存
hierarchical_memory_limit 408021893120 #
hierarchical_memsw_limit 9223372036854771712 #
total_xxx # hierarchical 

粗略来看（不看swap）cache+rss=inactive_anon+active_anon+inactive_file+active_file。

这上面的值还挺绕的，cache+rss跟[in]active_anon/file也难有直接对应关系，再加上mapped_file这个共享内存不知道该算到哪去，容易算晕。结合各种文档和测试，手搓脚本如下：

#cginfo_lzl
echo -n "shared_mem_mapped : ";cat /sys/fs/cgroup/memory/$PGNAME/memory.stat|egrep -w "mapped_file"| awk '{print $2 / 1024 / 1024 /1024 }' ;\
echo -n "shared_mem_anon : ";cat /sys/fs/cgroup/memory/$PGNAME/memory.stat|egrep -w "rss|inactive_anon|active_anon"| awk 'NR==1 {a=$2} NR==2 {b=$2} NR==3 {c=$2; print (b + c -a)/1024/1024/1024}' ;\
echo -n "pagecache : ";cat /sys/fs/cgroup/memory/$PGNAME/memory.stat|egrep -w "cache"| awk '{print $2 / 1024 / 1024 /1024 }' ;\
echo -n "pagecache_cache-share : ";cat /sys/fs/cgroup/memory/$PGNAME/memory.stat|egrep -w "cache|mapped_file"| awk 'NR==1 {a=$2} NR==2 {b=$2; print (a - b)/1024/1024/1024}';\
echo -n "file_total : ";cat /sys/fs/cgroup/memory/$PGNAME/memory.stat|egrep -w "inactive_file|active_file"| awk '{sum += $2} END {print sum /1024/1024/1024}';\
echo -n "anon_total : ";cat /sys/fs/cgroup/memory/$PGNAME/memory.stat|egrep -w "inactive_anon|active_anon"| awk '{sum += $2} END {print sum /1024/1024/1024}';\
echo -n "total_used_rss+map : ";cat /sys/fs/cgroup/memory/$PGNAME/memory.stat|egrep -w "rss|mapped_file"| awk '{sum += $2} END {print sum /1024/1024/1024}';\
echo -n "total_mem_file+rss+map : ";cat /sys/fs/cgroup/memory/$PGNAME/memory.stat|egrep -w "inactive_file|active_file|rss|mapped_file"| awk '{sum += $2} END {print sum /1024/1024/1024}';\
echo -n "total_mem_rss+cache : ";cat /sys/fs/cgroup/memory/$PGNAME/memory.stat|egrep -w "rss|cache"| awk '{sum += $2} END {print sum /1024/1024/1024}';\
echo -n "total_mem_anon+file : ";cat /sys/fs/cgroup/memory/$PGNAME/memory.stat|egrep -w "inactive_file|active_file|inactive_anon|active_anon"| awk '{sum += $2} END {print sum /1024/1024/1024}';\
echo -n "total_memsw : ";cat /sys/fs/cgroup/memory/$PGNAME/memory.stat|egrep -w "rss|cache|swap"| awk '{sum += $2} END {print sum /1024/1024/1024}';\
echo -n "hard_limit : ";cat /sys/fs/cgroup/memory/$PGNAME/memory.limit_in_bytes| awk '{print $1 / 1024 / 1024 /1024 }'

#shared_buffers=2GB的库
shared_mem_mapped : 1.69063
shared_mem_anon : 1.69828
pagecache : 5.94717
pagecache_cache-share : 4.25654
file_cache : 4.24889
anon_cache : 3.23096
total_used_rss+map : 3.2233
total_mem_file+rss+map : 7.47219
total_mem_rss+cache : 7.47984
total_mem_anon+file : 7.47984
total_memsw : 7.47984
hard_limit : 8

cgroup rss和process rss的差异
#

#shared_buffers= 64GB,所有pg进程的rss排序
ps -eo pid,ppid,rss,args |grep `cat $PGDATA/postmaster.pid|head -1`|sort -k3 -rn
 97632 97627 61103720 postgres: lzlinst: checkpointer 
 97633 97627 59045152 postgres: lzlinst: background writer 
 97627 1 2322820 /paic/postgres/base/11.3/bin/postgres -D /paic/pg6888/data
 97637 97627 85116 postgres: lzlinst: pgsentinel 
 97697 97627 19620 postgres: lzlinst: dbmgr users [local] idle
 97634 97627 17932 postgres: lzlinst: walwriter 
250063 97627 14508 postgres: lzlinst: dbmon postgres [local] idle
 97636 97627 13220 postgres: lzlinst: stats collector 
248777 97627 11576 postgres: lzlinst: dbmon postgres [local] idle
 97635 97627 2980 postgres: lzlinst: autovacuum launcher 
 97638 97627 2376 postgres: lzlinst: logical replication launcher 
 97630 97627 1592 postgres: lzlinst: logger 
250185 39130 972 grep --color=auto 97627

一般来说，pg rss值最多的是checkpointer和bgwriter进程，因为rss代表的真实使用的内存，含共享内存部分，这2个要刷shared buffer脏页的进程占用最多。也有查数据过多的backend也可能rss值较高，不过一般是抽数或者全表扫的慢sql导致。

postmaster为什么很少？因为postmaster本身不需要做太多shared_buffer的操作，它只需要把共享内存的虚拟地址开辟下来，fork给其他进程用即可。

pm的子进程的共享内存地址是相同的，rss就不一定了：

$ cat /proc/97632/smaps |grep -A 3 "zero" #checkpointer
2b4fd87cf000-2b60a2143000 rw-s 00000000 00:04 15925397 /dev/zero (deleted)
Size: 70411728 kB
Rss: 61087812 kB
Pss: 31429895 kB
$ cat /proc/97633/smaps |grep -A 3 "zero" #bgwriter
2b4fd87cf000-2b60a2143000 rw-s 00000000 00:04 15925397 /dev/zero (deleted)
Size: 70411728 kB
Rss: 59043388 kB
Pss: 29394787 kB
$ cat /proc/97627/smaps |grep -A 3 "zero" #postmaster
2b4fd87cf000-2b60a2143000 rw-s 00000000 00:04 15925397 /dev/zero (deleted)
Size: 70411728 kB
Rss: 2318408 kB
Pss: 1741764 kB

以上checkpointer和bgwriter占用最多的rss，且rss中大部分是共享内存。它们两个进程几乎平分了整个真实使用的共享内存，postmaster反倒使用不多。pm及其fork的所有子进程的共享内存的虚拟地址是相同的。

但是，cgroup中的rss只有几十MB，远小于进程的rss

cat /sys/fs/cgroup/memory/lzlinst/memory.stat |egrep -w "rss|mapped_file"
rss 88997888
mapped_file 52963262464

可以看出来，pg共享内存没有在cgroup stat rss的统计中。cgroup的rss没有计算file page以及shared file page。

linux kernel¹⁴:

Only anonymous and swap cache memory is listed as part of ‘rss’ stat. This should not be confused with the true ‘resident set size’ or the amount of physical memory used by the cgroup.

进程和cgroup内存统计差异¹⁵：

内存	单进程	进程`cgroup(memcg)`
`cache`	无	`PageCache`
`mapped_file`	无	`file_rss + shmem_rss`
`RSS`	`anon_rss + file_rss ＋ shmem_rss`	`anon_rss`

对于pg来说，stat中的rss不包含file map共享内存。pg官网把mmap描述为anonymous shared mem：

Possible values are mmap (for anonymous shared memory allocated using mmap), sysv (for System V shared memory allocated via shmget)

cg把pg mmap的内存算成mapped_file。

观察sysv和大页的情况，pg的memory.stat相关指标总结：

stat中的rss不包含file map共享内存。观察来看，无论是mmap还是sysv，rss都不含pg的共享内存
同理，rss_huge也不含file map共享大页内存。观察来看，即便开启大页，stat也不含pg的共享内存
无大页时，pg的共享内存（mmap or sysv）均统计在memory.stat mapped_file下；有大页时，不在stat中的任何指标中，包括rss_huge

mapped_file到底在哪里？
#

mapped_file在cache中，也在inactive_anon+active_anon中
mapped_file也可以是匿名的，mmap/sysv都算在这里

#shared_buffers=2GB的库
shared_mem_mapped : 1.69063
shared_mem_anon : 1.69828
pagecache : 5.94717
pagecache_cache-share : 4.25654
file_cache : 4.24889
anon_cache : 3.23096
total_used_rss+map : 3.2233
total_mem_file+rss+map : 7.47219
total_mem_rss+cache : 7.47984
total_mem_anon+file : 7.47984
total_memsw : 7.47984
hard_limit : 8

soft_limit_in_bytes
#

软限制（memory.soft_limit_in_bytes）是 cgroup 内存管理中的一种非强制约束。当 cgroup 的内存使用量超过软限制时，系统不会立即强制回收内存，而是会在 全局内存压力较大时（例如系统整体内存紧张）优先回收该 cgroup 的超额内存。

触发条件：全局内存压力（例如系统空闲内存不足）。
调用路径：kswapd → balance_pgdat → 检查 cgroup 软限制 → 触发回收。
回收目标：优先回收超出软限制的 cgroup 的内存页面。

+-------------------+ 全局内存压力检测 +-------------------+
| kswapd 线程 | ---------------------> | balance_pgdat |
+-------------------+ +-------------------+
 |
 | 遍历内存区域并检查
 v
 +---------------------------+
 | 检查各 cgroup 的软限制使用情况 |
 +---------------------------+
 |
 | 对超限 cgroup 触发回收
 v
 +---------------------------+
 | 页面回收（LRU 链表扫描等） |
 +---------------------------+

soft_limit_in_bytes机制很像high，v2的soft_limit_in_bytes已过期，新增min、low、high三个参数。

超卖对pagecache的影响
#

再说

cg oom
#

正常来说，sharedbuffer=1/4的cg mem，那么在不计算私有内存的情况下，pagecache最大可以到3/4的cg mem。一般来说，正常的业务私有内存占用不会很多，如果cg mem打满是可以从cg pagecache中回收内存的（是直接内存回收，aliOS做了异步后台回收：Memcg后台异步回收内存）。所以测试cg oom最好的办法是用占用很多私有内存的会话而不是加压。

测试用例：

#观察score
-r--r--r-- 1 postgres postgres 0 May 24 16:39 /proc/63766/oom_score
rss # 随便哪个命令啦

## 一个可以占用很多私有内存的sql，很多union all有很多plan node
psql -d lzldb -tX -c "create table lzl1(col1 varchar(1));"
psql -tX -c "\o sqltext.sql" -c "
SELECT 'select col1 from lzl1' || ' union all'
FROM generate_series(1, 100000)
UNION ALL
SELECT 'select col1 from lzl1;'
FROM generate_series(1, 1);
" 

#调整stack参数不然sql会被掐掉
psql -d lzldb -c "set max_stack_depth=1024000" -f sqltext.sql

cg oom off:

wchan有oom信息，甚至有oom score，但不会被OOM killer干掉

## vm oom打开; 0:不触发panic，启动OOM Killer
$ cat /proc/sys/vm/panic_on_oom 
0

## cg oom关闭;1:禁用oom
$ cat /sys/fs/cgroup/memory/$PGNAME/memory.oom_control
oom_kill_disable 1
under_oom 0


$ ps -eo user,ppid,pid,state,%cpu,%mem,stime,wchan:14,args,rss,vsz,sig_block |grep `head -1 $PGDATA/postmaster.pid` |grep -v grep 
postgres 19005 870 D 0.0 0.0 10:54 mem_cgroup_oom postgres: pg3ymhp2: lzluser 7216 2807460 0000000000000000
postgres 19005 3417 S 0.0 0.0 10:55 pipe_wait postgres: pg3ymhp2: lzluser 22944 2808540 0000000000000000
postgres 19005 13069 D 0.0 0.0 11:10 mem_cgroup_oom postgres: pg3ymhp2: lzluser 11944 2808348 0000000000000000
postgres 19005 13104 D 0.0 0.0 11:10 mem_cgroup_oom postgres: pg3ymhp2: lzluser 12224 2808348 0000000000000000
postgres 19005 14352 D 0.0 0.0 11:10 mem_cgroup_oom postgres: pg3ymhp2: lzluser 11680 2808348 0000000000000000

cat /sys/fs/cgroup/memory/$PGNAME/memory.oom_control
oom_kill_disable 1
under_oom 1

cat /proc/97994/oom_score
11

shared_mem_mapped : 2.00019
shared_mem_anon : 2.0023
pagecache : 2.0023
pagecache_cache-share : 0.00211334
file_cache : 0
anon_cache : 8
total_used_rss+map : 7.99789
total_mem_file+rss+map : 7.99789
total_mem_rss+cache : 8
total_mem_anon+file : 8
total_memsw : 8
hard_limit : 8

目前看来，PG的进程在分配不到内存的时候也有可能跑崩，例如walwriter跑奔溃会导致其他进程都崩溃。

cg oom on：

用户进程因为oom score高而被kill，发送的是kill -9，pg绝大部分进程奔溃，postmaster reset_shared()后自动拉起其他进程。mesage和dmesg都有out of memory相关信息：

#cg oom打开
oom_kill_disable 0

pg log:
2025-05-29 19:10:45.945 CST,,,198877,,6838374d.308dd,4,,2025-05-29 18:30:37 CST,,0,LOG,00000,"server process (PID 236413) was terminated by signal 9: Killed","Failed process was running: select col1 from lzl1 union all

message:
May 29 19:10:45 lzlhost kernel: Memory cgroup stats for /t1lzldb: cache:8392988KB rss:8384228KB rss_huge:0KB mapped_file:7458316KB swap:0KB inactive_anon:1310184KB active_anon:15467032KB inactive_file:0KB active_file:0KB unevictable:0KB
May 29 19:10:45 lzlhost kernel: Memory cgroup out of memory: Kill process 236413 (postgres) score 497 or sacrifice child

dmesg:
[Thu May 29 18:26:27 2025] Memory cgroup stats for /t1lzldb: cache:8392988KB rss:8384228KB rss_huge:0KB mapped_file:7458316KB swap:0KB inactive_anon:1310184KB active_anon:15467032KB inactive_file:0KB active_file:0KB unevictable:0KB
[Thu May 29 18:26:27 2025] Memory cgroup out of memory: Kill process 236413 (postgres) score 497 or sacrifice child
[Thu May 29 18:26:27 2025] Killed process 236413 (postgres) total-vm:18828736kB, anon-rss:8328252kB, file-rss:2328kB, shmem-rss:1832kB

cg oom on和off对于pg库管理上的区别：

on，cg oom killer会kill oom score高的进程，一般来说是用户进程
off，cg oom killer不会启动。pg进程会hang，当然也可能自己恢复，但pg的关键进程（如walwriter）可能因内存不足而跑崩，实例一样可能挂掉。

注意这里说的cg oom，不是vm oom。系统级的vm oom由系统级的vm overcommit机制来判断。

cg v1的问题
#

没有统计cg pagetable
没有统计cg slab
没有统计cg hugepage（hugepage是没有charge，还不是没有算进去）
没有统计cg异步、同步回收pages
cg rss与process rss统计口径不统一
shmem统计口径比较乱

what’ new in V2
#

V2 Officially released in Linux 4.5 (March 2016)¹⁶。

cgroup v2内存管理的提升和改变：¹⁷

cg mem接口文件	对比v1	含义
memory.current	重修	当前使用内存大小。移除没什么用的usage_in_bytes
memory.min	新增	跟vm的min/low/high不同。vm的水位线是操作系统剩的内存，cg v2的水位线是cg mem使用的内存。memory.min为硬保护内存保护值，默认值为0。系统没有可回收内存的时候，也不会回收在该值边界及以下的内存¹⁸
memory.low	新增	尽力而为的内存保护值，默认值为0。系统优先回收未被保护的cgroup组的内存。如果内存还不足，再回收memory.min到memory.low之间的内存。
memory.high	新增	内存回收警示值，默认为max。当cgroup组内存使用量达到high值，会触发对该cgroup及子节点的同步内存回收任务，将内存尽量限制在high之下
memory.max	重修	等价memory.limit_in_bytes
memory.reclaim	重修	主动回收接口文件，v1只有memory.force_empty强制清空
memory.peak	重修	等价max_usage_in_bytes；超过peak会触发cg oom killer
memory.oom.group	新增	控制 cg OOM killer时是否终止整个 cgroup（1）或仅单个进程（0）。默认为0.如果oom_score_adj=-1000，不会被kill
memory.events	新增	报告内存相关事件
memory.stat	重修	改变较多，单独分析
memory.zswap.current，memory.zswap.max，memory.zswap.writeback	新增	Zswap 是 Linux 内核中的一种内存压缩交换机制，通过压缩待交换的内存页，减少对磁盘的 I/O 操作，从而提升系统性能。其核心思想是将原本需要写入磁盘的交换数据压缩后暂存于内存中，仅在必要时才将数据写入物理交换设备（如 Swap 分区或文件）
soft_limit_in_bytes	移除
memory.oom_control	移除	代表v2无法直接关闭cg oom killer；不过可以通过设置min/low/high和设置event内存事件通知等来精细化管理内存

v2 cg mem在管理上有如下优势：

相对v1，v2有更简单明了的层级管理
v1只有OOM kill or freeze，v2有更多手段控制内存大小(如memory.min/low/high)
v2更容易控制突刺负载¹⁹
移除直接关闭cg oom killer的接口文件
增加memory_hugetlb_accounting

memory.stat：

参数	含义	v1 对应项
anon	匿名页	active_anon+inactive_anon
file	文件页，含 tmpfs	active_file+inactive_file
kernel (npn)	总内核内存，包括kernel_stack, pagetables, percpu, vmalloc, slab以及其他内核内存的使用情况。	新增
kernel_stack	kernel stacks占用的内存量。	新增
pagetables	page tables	新增
sec_pagetables	二级页表，适合虚拟机、GPU 设备、网络加速卡等硬件资源隔离场景	新增
percpu (npn)	存储per-cpu内核数据结构的内存大小	新增
sock (npn)	network transmission buffers	新增
vmalloc (npn)	vmalloc	新增
shmem	b包括tmpfs, shm , shared anonymous mmap	新增
zswap	zswap压缩本身消耗的内存	新增
zswapped	zswap了多少用户内存	新增
file_mapped	mmap()大小	有点类似v1 mapped_file，不过mapped_file包含tmpfs、shm
file_dirty		同v1 dirty
file_writeback		同v1 writeback
swapcached		同v1 swapcached
anon_thp	透明大页中的匿名页	新增
file_thp	透明大页中的文件页	新增
shmem_thp	透明大页的shm、tpfs、匿名mmap	新增
inactive_anon, active_anon, inactive_file, active_file, unevictable		同v1
slab_reclaimable	意如其名	新增
slab_unreclaimable	意如其名	新增
slab (npn)	意如其名	新增
workingset_refault_anon，workingset_refault_file，workingset_activate_anon，workingset_activate_file，workingset_restore_anon，workingset_restore_file，workingset_nodereclaim	refaulted相关page统计	新增
pswpin (npn)	swap in	同v1 pgpgin
pswpout (npn)	swap out	同v1 pgpgout
pgscan (npn)	scanned pages (in an inactive LRU list)	新增
pgsteal (npn)	回收的内存	新增
pgscan_kswapd (npn)	意如其名	新增
pgscan_direct (npn)	意如其名	新增
pgscan_khugepaged (npn)	透明大页守护进程扫描的pages	新增
pgscan_proactive (npn)	proactive主动扫描的pages	新增
pgsteal_kswapd (npn)，pgsteal_direct (npn)，pgsteal_khugepaged (npn)，pgsteal_proactive (npn)	意如其名，pgsteal对应pgscan	新增
pgfault (npn)	意如其名	同v1 pgfault
pgmajfault (npn)	意如其名	同v1 pgmajfault
pgrefill (npn)	在active LRU中扫描的pages	新增
pgactivate (npn)	移动到active LRU中的pages	新增
pgdeactivate (npn)	移动到inactive LRU中的pages	新增
pglazyfree (npn)	有内存压力时，推迟释放的pages	新增
pglazyfreed (npn)	已回收的lazyfree pages	新增
swpin_zero,swpout_zero	zero-filled pages；在Swap In 阶段，内核检测到页面内容全为零（Zero-filled），标记该页为“零页”并记录在元数据中，跳过磁盘 I/O 操作	新增
zswpin,zswpout,zswpwb	zswap相关pages	新增
thp_fault_alloc (npn)，thp_collapse_alloc (npn)，thp_swpout (npn)，thp_swpout_fallback (npn)	透明大页相关pages	新增
numa_pages_migrated (npn)，numa_pte_updates (npn)，numa_hint_faults (npn)	numa相关pages，其实还有memory.numa_stat	新增
pgdemote_kswapd，pgdemote_direct，pgdemote_khugepaged，pgdemote_proactive	没懂demote	新增
hugetlb	大页	新增

v2 cg mem在观测上有如下优势：

新增slab、pagetable、pgscank/pgsand/pgsteal、大页信息，这些都是v1没有的
更多具体特性相关的观测指标，比如sock 、vmalloc、透明大页、zswap压缩交互、swap_zero全零交互等
共享内存shmem和file_mapped指标分开

wchan
#

Waiting Channel，name of the kernel function in which the process is sleeping

一般来说要检查D状态的进程的wchan，看看进程在等待什么内核函数。

-：Running tasks will display a dash (’-’) in this column

poll_schedule_timeout: PM常见，-一般在运行状态

zz ***Fri May 2 04:50:10 CST 2025
postgres 141378 1 19 0.5 0.4 70585180 2322876 poll_schedule_timeout S 21:06:18 00:02:40 /paic/postgres/base/11.3/bin/postgres -D /paic/pg6888/data
zzz ***Fri May 2 04:50:43 CST 2025
postgres 141378 1 19 0.5 0.4 70585180 2322876 - R 21:06:18 00:02:42 /paic/postgres/base/11.3/bin/postgres -D /paic/pg6888/data

futex_wait_queue_me: SLEEP进程常见。偶现D

postgres 455358 141378 19 4.7 1.0 70590684 5349576 futex_wait_queue_me S 03:01:12 00:02:47 postgres: t1lzldb: lzl test3 30.181.32.3(39801) COMMIT

hugetlb_fault：只见过hugepage刚加载，刚起负载时

do_last：虚拟文件系统（VFS）路径解析逻辑中的函数，负责处理文件路径的最后一个分量（如文件名或符号链接），并触发实际的文件操作

lock_page_killable：以可中断方式锁定物理内存页；可中断性是说允许进程在等待页面锁时响应致命信号，如SIGKILL

rpc_wait_bit_killable：该函数与远程过程调用（RPC）机制相关，用于在内核中等待某个位标志的变更

wait_on_page_bit：等待页面标志位的状态变更（如PG_locked、PG_writeback）

blkdev_issue_flush：块设备层的刷新缓存函数；可能的调用链：用户调用fsync() → 文件系统（如ext4）将相关脏页提交至块设备层 → 调用blkdev_issue_flush()确保设备缓存刷新

on_proc_exit：注册进程退出时的清理函数

ima_file_check：属于IMA（Integrity Measurement Architecture）子系统，用于在文件访问时验证其完整性；典型的有open()调用

flush_work：等待任务完成

call_rwsem_down_write_failed：当尝试获取写锁（down_write()）失败时，此函数处理写锁竞争与等待逻辑。它通过自旋或睡眠机制让当前进程等待锁释放（rwsem（读写信号量））

get_request ：iowait高时出现；从块设备请求队列中获取空闲的请求结构体（struct request）。若队列已满（设备处理速度不足），线程将等待直至有可用请求

lookup_slow：VFS（虚拟文件系统）路径解析的慢速路径

/**
 * lookup_fast - do fast lockless (but racy) lookup of a dentry
 * @nd: current nameidata
 *
 * Do a fast, but racy lookup in the dcache for the given dentry, and
 * revalidate it. Returns a valid dentry pointer or NULL if one wasn't
 * found. On error, an ERR_PTR will be returned.
 */
 static struct dentry *lookup_fast(struct nameidata *nd)

/* Fast lookup failed, do it the slow way */
static struct dentry *__lookup_slow(const struct qstr *name,
				 struct dentry *dir,
				 unsigned int flags)

static struct dentry *lookup_slow(const struct qstr *name,
				 struct dentry *dir,
				 unsigned int flags)
{
	struct inode *inode = dir->d_inode;
	struct dentry *res;
	inode_lock_shared(inode);
	res = __lookup_slow(name, dir, flags);
	inode_unlock_shared(inode);
	return res;
}

lookup_fast和lookup_slow都是在找dentry并返回dentry，lookup_fast会在dentry cache中寻找，如果失败会通过lookup_slow查找。

开大页压测，无直接内存回收，出现以下事件：

lock_page：iowait高时出现；内核尝试锁定一个内存页时，若页面已被其他线程/进程锁定，当前线程会进入等待状态。

vx_svar_sleep_unlock，vx_ilock，vx_bc_biowait，vx_dio_physio，vx_rwsleep_lock：

vx是Veritas 公司开发的日志型文件系统（现归属于 Symantec 及后续拆分后的 Veritas Technologies），设计目标为高性能、高可用性的大规模数据存储，主要面向企业级应用场景。跟xfs、ext4一样是一种文件系统。

pipe_wait：当进程尝试从管道（Pipe）读取数据或向管道写入数据时，若管道缓冲区已满（写操作）或已空（读操作），当前线程会进入休眠状态，等待缓冲区状态变化

pipe_write：管道写操作的入口函数，当缓冲区满时，线程在此函数中休眠，等待可写空间

congestion_wait：当块设备 I/O 队列拥塞时（如请求队列已满或设备处理延迟），内核通过此函数让线程短暂休眠

wait_iff_congested：检查块设备队列是否拥塞，若拥塞则进入短暂休眠。与 congestion_wait 类似，但更轻量级，通常用于内存回收或脏页回写路径

mem_cgroup_oom_synchronize：usage_in_bytes达到limit_in_bytes时，标记oom_control.under_oom=1，是否启用OOM killer内核模块取决于oom_control.oom_kill_disable

mem_cgroup_oom:同mem_cgroup_oom_synchronize

rmap_walk
#

PFRA目标之一是为了回收共享页框，为了达到这个目的，Linux 2.6内核能够快速定位指向同一页框的所有页表项，这个过程叫反向映射（reverse mapping）¹。

当已被一个进程引用的页框插入另一个进程的页表项（fork）时，应该也会发生rmap_walk

zcat hostlzl_ps_25.04.08.0900.dat.gz|egrep "\-D /dirlzl/pg5998/data|zzz"|less
zzz ***Tue Apr 8 09:10:50 CST 2025
postgres 209987 1 19 0.2 0.5 70247548 2117844 poll_schedule_timeout S 22:17:21 00:01:56 /dirlzl/postgres/base/postgressql/bin/postgresdb -D /dirlzl/pg5998/data
zzz ***Tue Apr 8 09:11:20 CST 2025
postgres 209987 1 19 0.2 0.5 70247548 2117844 poll_schedule_timeout S 22:17:21 00:01:56 /dirlzl/postgres/base/postgressql/bin/postgresdb -D /dirlzl/pg5998/data
zzz ***Tue Apr 8 09:13:08 CST 2025
postgres 209987 1 19 0.2 0.5 70247548 2117844 - D 22:17:21 00:01:57 /dirlzl/postgres/base/postgressql/bin/postgresdb -D /dirlzl/pg5998/data
postgres 225076 209987 19 1.6 0.0 70247548 1720 rmap_walk D 09:11:51 00:00:01 /dirlzl/postgres/base/postgressql/bin/postgresdb -D /dirlzl/pg5998/data
postgres 224924 209987 19 0.7 0.0 70247548 1728 rmap_walk D 09:11:46 00:00:00 /dirlzl/postgres/base/postgressql/bin/postgresdb -D /dirlzl/pg5998/data
postgres 224817 209987 19 0.5 0.0 70247548 1720 try_to_unmap_file D 09:11:44 00:00:00 /dirlzl/postgres/base/postgressql/bin/postgresdb -D /dirlzl/pg5998/data
zzz ***Tue Apr 8 09:19:16 CST 2025
postgres 209987 1 19 0.3 0.5 70247548 2117884 poll_schedule_timeout S 22:17:21 00:02:00 /dirlzl/postgres/base/postgressql/bin/postgresdb -D /dirlzl/pg5998/data
postgres 250875 209987 19 0.0 0.0 70247548 2208 - R 09:19:17 00:00:00 /dirlzl/postgres/base/postgressqlbin/postgresdb -D /dirlzl/pg5998/data
zzz ***Tue Apr 8 09:19:48 CST 2025
postgres 209987 1 19 0.3 0.5 70247548 2117884 poll_schedule_timeout S 22:17:21 00:02:01 /dirlzl/postgres/base/postgressql/bin/postgresdb -D /dirlzl/pg5998/data

try_to_unmap_file
#

try_to_unmap_file()函数调用try_to_unmap_cluster()，而try_to_unmap_cluster()函数会扫描该线性区线性地址所对应的所有页表项，并尝试将他们清理¹。try_to_unmap_file()执行映射页的反向映射。注意，反向映射即通过pagetable反向寻找所有vma，并将共享物理页框回收。

page_referenced
#

refenced和active用于控制page的活跃度，在页面回收中使用。refcount=0时表示空闲或即将要被释放的页面⁵。

在kernel.org doc的Object-Based Reverse Mapping中有对page_referenced()函数的描述[^ kernel.org, Page Table Management]：

page_referenced() which checks all PTEs that map a page to see if the page has been referenced recently

page_referenced() calls page_referenced_obj() which is the top level function for finding all PTEs within VMAs that map the page.

If a page is mapped and it is referenced through the mapping, index hash table, this bit is set. It is used during page replacement for moving the page around the LRU lists

简言之，page_referenced()通过页框找到map的所有PTEs上的VMAs。这也是一个rmap的过程。

Linux 引入了两个页面标志符 PG_active 和 PG_referenced 用于标识页面的活跃程度，从而决定如何在两个链表（active LRU和inactive LRU）之间移动页面。

PG_active 用于表示页面当前是否是活跃的，如果该位被置位，则表示该页面是活跃的。PG_referenced 用于表示页面最近是否被访问过，每次页面被访问，该位都会被置位。

page_referenced()：当操作系统进行页面回收时，每扫描到一个页面，就会调用该函数设置页面的 PG_referenced 位。如果一个页面的 PG_referenced 位被置位，但是在一定时间内该页面没有被再次访问，那么该页面的 PG_referenced 位会被清除。²⁰。

内存观察指标
#

查看基本内存设置：

观察内存指标：

一些问题
#

kswapd和直接内存回收是否会一起执行？
#

会。如果是水位线触发的内存回收，有pgscand时经常伴随pgscank，反之则不然。如果pgscank、pgscand均频繁，那么可以考虑调整内存回收水位线，调大delta，防止delta被快速冲破。

不过还有一种情况，碎片率较高的时候，free还有很多，也有可能直接触发阻塞式内存压缩，有pgscand，完全没有pgscank。此时调整水位线就没有什么用了，可以考虑开启大页内存并提升一定的sharedbuffer命中率，减少pagecache频繁分配切碎内存。

pagetable过大对内存回收的影响
#

pagetable过大，会增加反向映射的代价和时间。在直接内存回收时需要通过反向映射，找到所有进程的虚拟地址空间VMA，然后取消所有进程的VMA页表映射。也就说进程数越多，pagetable越大，内存回收也就越慢。

postgres的进程数越多，pagetable越大；shared buffer越大，pagetable也越大。

开启大页内存可以减少500倍（4k=>2M）pagetable大小，不仅可以空出一定内存，也可以提升内存回收效率。

shared buffers多大合适
#

sharedbuffers=1/4 cgmem 似乎以成为行业标准，但是实际情况要复杂的多。理论上，把sharedbuffers调小可以增加一点pagecache，实际上略微增大了整个缓存大小，把sharedbuffers调大略微减少了减少了整个缓存大小，但是提升了一定的sharedbuffer命中率。很明显，sharedbuffers调大了不好，调小了也不好。sharedbuffers调太小，pg自己能工作的内存就太小了，相当于把内存管理工作扔给了OS，OS回收pagecache时对性能也会有影响；sharedbuffers调太大，不仅pagecache被挤占，还需要考虑pg刷脏的影响，特别是写入较多的情况需要调整相应的bgwriter参数。

从粗糙的压测来看

不开大页，shared buffers=min(1/4 MEM,20GB)
开大页，shared buffers=min(1/4 MEM,60GB)

进程和线程的差别真的不大吗？
#

在任何linux内核资料中，都会说进程和线程的差别不大。无论是创建进程还是线程，内核中都是用同一个函数kernel_clone来实现的，唯一区别在于传入的参数不同，fork和clone的系统调用差不多³：

维度	进程	线程
childID	每个进程都有独立的 `pid`（进程 ID）	每个线程有 `tid`（线程 ID），但线程的 pid`与所属进程的`pid` 一致。
地址空间	每个进程拥有独立的地址空间（`mm_struct`），包括内存、堆栈等。	线程共享所属进程的地址空间，所有线程的 `mm_struct` 指向同一个地址空间。
文件系统	每个进程有自己的 `fs_struct`，包含文件描述符、挂载点等。	线程共享所属进程的 `fs_struct`，所有线程的文件描述符和挂载点与进程一致。

线程跟进程相比，只是稍微“轻量”了一点，总体来说进程和线程的相同点大于他们的不同点。

但是，进程多了以后区别可就大了，特别是像pg这样的多进程应用：

每个进程都有自己的VMA，所以要维护更多的地址空间
每个进程都有自己的pagetable，所以pagetable要占用更多的内存
多进程会增加TLB的刷新负担，而线程不会
进程切换需要更多的上下文开销，而线程不会
进程间通信IPC效率更低，而线程直接共享内存不会有IPC通信问题

可以这么说，进程和线程在创建的时候差别不大，但是多进程管理和多线程管理差别很大。

为什么从库会有pg层脏页？
#

从库日志回放机制本身会产生脏页，从库也会刷脏。可通过pg_buffercache查看从库脏页，从库的脏页跟主库不一样，从库脏数据也是一般的relation；同时可以观察到从库的checkpoint/bgwriter/backend刷脏都跟主库不一样。

为什么file cache有些库高有些低
#

一般来说是离散度多的库file cache比较多，简单的慢sql是比较难把file cache长期维持在较高水平的。一个慢sql访问较多数据，可能会短暂的升高filecache，但是过一会这些file page的reference下降，并成为inactive file pages后，内存可以回收这一部分内存。但是频繁的离散度，比如索引的correlation接近0，如UUID主键，其SQL性能较好但reads高，可能产生频繁物理IO，加载了太多的page到filecache中。甚至业务模型的转变会导致shared buffer的大量换入换出，对性能影响较大。

pg进程和共享内存映射
#

#未开大页时，是/dev/zero （deleted）
cat /proc/102208/smaps |egrep "rw\-s" -A 1
2aefd8901000-2aefd8902000 rw-s 00000000 00:04 1202061313 /SYSV00001000 (deleted)
Size: 4 kB
--
2aefd8918000-2aefd898f000 rw-s 00000000 00:13 4084862058 /dev/shm/PostgreSQL.1008001451
Size: 476 kB
--
2aefe2605000-2b00ad129000 rw-s 00000000 00:04 4084864418 /dev/zero (deleted)

#开启大页时，是/anon_hugepage (deleted)
cat /proc/29091/smaps |egrep "rw\-s" -A 1
2aaaaac00000-2ac3a2c00000 rw-s 00000000 00:0e 215471503 /anon_hugepage (deleted)
Size: 104726528 kB
--
2b48dfe93000-2b48dfe94000 rw-s 00000000 00:04 88604727 /SYSV00001000 (deleted)
Size: 4 kB
--
2b48dfeab000-2b48dff22000 rw-s 00000000 00:12 215515747 /dev/shm/PostgreSQL.1123685558
Size: 476 kB

子进程页表都是从父进程中复制过来的，父子进程因此共享同一页框¹。所以无论是postmaster还是backend进程（任何postmaster fork出来的进程），在虚拟内存地址中都会映射相同的共享内存地址，他们在smaps中的地址和Size是相等的。

为什么pg的所有的进程的虚拟内存都是/dev/zero段占用多
#

mmap实现匿名页映射主要有两种方式：一种是通过设置MAP_ANONYMOUS标志并传入fd=-1，另一种是打开/dev/zero设备文件并将得到的文件描述符传递给mmap。这两种方法在功能上是等效的。

pg sharebuffer使用的/dev/zero设备映射来实现的匿名共享页，所以一般能看到pg进程的/dev/zero的虚拟内存地址占用是比较多。

References
#

[《深入理解Linux内核》]: 《深入理解Linux内核》：内存寻址、内存管理、地址空间管理、回收页框

[《深入理解Linux进程和内存》]: 《深入理解Linux进程和内存》 CPU硬件原理、进程、线程的对比

[《奔跑吧 Linux内核入门篇（第2版）》]: 《奔跑吧Linux内核入门篇（第2版）》系统调用、内存管理

《深入理解Linux内核》：内存寻址、内存管理、地址空间管理、回收页框 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
https://www.cs.oslomet.no/~haugerud/os/Forelesning/os7.pdf ↩︎
《深入理解Linux进程和内存》CPU硬件原理、进程、线程的对比 ↩︎ ↩︎
https://www.cs.unc.edu/~porter/courses/comp630/s24/slides/pfra.pdf ↩︎
《奔跑吧Linux内核入门篇（第2版）》系统调用、内存管理 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
https://courses.cs.washington.edu/courses/cse333/20wi/lectures/07/CSE333-L07-posix_20wi.pdf ↩︎
https://www.sohu.com/a/392831824_467784 ↩︎
redhat,Configuringanoperatingsystemtooptimizememoryaccess ↩︎
https://www.kernel.org/doc/html/latest/admin-guide/sysctl/vm.html#swappiness ↩︎
https://access.redhat.com/solutions/6785021 ↩︎
https://www.kernel.org/doc/Documentation/vm/overcommit-accounting ↩︎
https://carlyleliu.github.io/LinuxKernel/LinuxMemoryOptimization/ ↩︎
https://www.man7.org/linux/man-pages/man5/proc_pid_oom_score.5.html ↩︎
https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/memory.html ↩︎ ↩︎ ↩︎
https://wiki.goframe.org/pages/viewpage.action?pageId=157646868 ↩︎
https://www.man7.org/conf/lca2019/cgroups_v2-LCA2019-Kerrisk.pdf ↩︎
https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html ↩︎
https://support.huaweicloud.com/usermanual-hce/hce_02_0072.html ↩︎
https://chrisdown.name/talks/cgroupv2/cgroupv2-fosdem.pdf ↩︎
https://www.cnblogs.com/muahao/p/10109712.html ↩︎

我的年终总结2024

Sat, 11 Jan 2025 00:00:00 +0000

As a DBA
#

2023对我来说是全面学习pg的一年，而2024就是全面运维pg的一年。其实还有一些资料我很想dive in但是一直没有时间搞，今年主要是案例分析，基础知识学习只有靠时不时的补补了。

年中的时候有一个关于“dba会不会被云时代淘汰的”的讨论，这次讨论我印象很深，我后面也想了很多东西，想了很多为什么别人事情很少，但是我的dba事情这么多之类的，甚至最后还去云计算群里面battle了一圈，确实有收获，不同的立场会有意想不到的结果。battle的结论可能只有一个：dba在给领导们提供1510情绪价值。

无论对还是错吧，今年可以在很多文章中看到对dba职业的思考。dba再继续走传统dba模式肯定是死路一条了，现在的dba会更倾向业务数据层运维，或者上升到架构设计，专注数据库的专家型dba的职位其实是很少的。

READING
#

再说下为何执着看书（23年也说过···）：

阅读带来的价值短期无法估量
阅读带来的知识充值愉悦感
学习是一种信仰。尤瓦尔有个观点是：相信科学实际上也是一种信仰。我选择相信这个信仰，至少24年以及短期可见的未来是这样

我的书单大概分成3类：pg类、大技术范围类、课外书。有中文也有英文，有纸质有电子。

今年继续来个书单排名，类别不同横向对比有点扯，就分类对比吧。再次备注，这些书单是“从头到尾”式的冲着finish去的，当reference的看的书不在此列。

2024年pg书单（按喜好排名）：

《PostgreSQL数据库内核分析》，思路框架清晰，就是版本有点老
《快速掌握PostgreSQL版本新特性》，这应该是我今年最喜欢的pg书，因为它全程无废话，看着舒服
《PostgreSQL指南内幕探索》，这本书我本来想放到第一位，但是因为有interdb在线免费文档，我甚至都不推荐这本书，排在这里是因为interdb太棒了，替身在这里当神供着
《PostgreSQL修炼之道从小工到专家第二版》，很细但也很多，建议快速翻完找到里面的重点，不要逗留太久
《PostgreSQL技术内幕事务处理深度探索》，事务是pg的基础，也是我的源码入门基础
《PostgreSQL实战》，里面的实战还是很值得借鉴
《PostgreSQL 16 Administration Cookbook》，不推荐，目录框架看着不错，内容很空，不推荐在这本书上浪费时间

2024年大技术范围类书单（按喜好排名）：

《DDIA-v2 设计数据密集型应用（第二版）》，好到不知道从何说起，棒到我专门写了读书笔记（我今年唯一的读书笔记文章），相见恨晚
《数据库简史》，读史真的可以明鉴，数据库的故事从这里开始，有些技术的东西都想得更明白了。
《ITIL 4 与devops 服务管理认证指南（第二版）》，IT服务管理的经典，提升一下对运维这个角色的理解，和我工作息息相关的这些东西又是怎么来的，哪些又是不符合实际以及为什么没有应用上？可以领悟到很多东西。
《云原生Kubernetes》，硬核，另一个赛道
《深入浅出Docker》，理解容器和容器历史还不错，容器本身的知识其实不多
《鸟哥的linux私房菜》，sorry我确实没有读过这本经典，补番来的。里面的写做思路很值得借鉴，缺点在于很多东西对于我的职能来说无法受益
《机器学习》，排在这里不是这本书不好，是很难看懂，大概到1/4的时候就放弃了，这本书让我了解了我的智力上限，我很难过
《从零搭建向量数据库》，看源码应该去github
《深入理解go语言》，理解了个寂寞

2024年课外书单（按喜好排名）：

《癌症楼》，这本书上半年早期就看完了，看的时候就觉得，不出意外这本书今年能排第一。诺贝尔文学奖，实至名归
《亲密关系》，理解和恋人、和朋友、和老板的关系，论文风格，扎实，我喜欢
《上帝掷骰子吗？量子物理史话》，别的不说，写作风格极其提供情绪价值，让我想一直看下去，没几天就把他看完了
《The Worlds I see》，AI 李飞飞的自传，一个成都长大的姑娘到水生活热美利坚冒险，最后执掌谷歌AI的故事，顺便讲述了一下AI的发展历史
《今日简史》，尤瓦尔三部曲最后一部，前两本都看完甚是喜欢，但是这一本感觉一般般，算是有始有终吧
《the old man and the sea》，不好评价，我喜欢它的气质，但不喜欢它的内容
《朝问道》，这是一本刘慈欣的短篇小说集，某天在图书馆因为第一篇短篇把它买下了，买回来发现其他短篇都很boring很幼稚，感觉被骗了
《西游记》，暴论：唐僧的身世都讲不明白，乱起八遭、稀里糊涂。看了点就放弃了（我去年对《三国演义》的评价是很高的）

博客和公众号
#

2024年的创作文章：

pg技术 21篇
其他技术 2篇
读书笔记 1篇
无用文章 1篇

今年只写了25篇文章，写作数量较去年明显下降了。

公众号followers 600，虽然人不多，但是我相信每一个都是有品位的人 😸

写技术文章其实挺累的，花的时间要比想象的多的多，不过在写作过程中确实可以学到东西，完作的成就感还是有的。应为要对文章负责，不懂的事情我自己不会去乱写。至于理解有误而出现的错误，其实也是正常现象，没人能保证5年后的自己不怼现在的自己，在当前状态下写对就行了。

今年写作内容上，放弃了课外书的读后感写作，去年写的挺多的，写读后感很费时间而且价值很低，低情绪价值的事情自然就放弃了。其实我每年的写作内容都有差别，目前来看就PG库技术类文章是永恒不变坚持创作的，其他类型的都没那么稳定。这也算正常吧，本来写博客就是为了写数据库，其他领域如果没有应用场景的话，短暂试探期过去就不会再接触了。

还想吐槽一点，国内的博客平台只对文章数量感兴趣，跟我的写作风格十分不契合，我一篇文章都是手敲的上万字，我是宁缺毋滥型博主。所以也懒得管了，准备25年放弃CSDN，就发发github和公众号得了。

CSDN我2017年就开始写了，当初写博客那会就没几个好用的博客托管平台。现在来看CSDN 社区交互为0，上面文章绝大部分都很挫，我自己都不想搜到CSDN的文章，就像虽然有7、8年感情的初恋，该分手还是得分手。

24年的发文途径：

CSDN博客：https://liuzhilong.blog.csdn.net
墨天轮 liuzhilong62
github：https://github.com/liuzhilong62/blogs
公众号：破斯特贵斯库儿

25年预计途径：

github：https://github.com/liuzhilong62/blogs
公众号：破斯特贵斯库儿
其他平台看情况吧

最后
#

我似乎每年都在说work-learning balance···由于今年工作量剧增，有段时间甚至都没办法学习了，balance已经被击碎。没有时间学习我是无法接受的，所以后面调整了一下自己的作息时间（感谢《原子习惯》这本书，我太爱了），总算能挤出一点时间来学习。其实只要周围没人，学习效率就是高的。

收集了一下今年我比较认可的话：

不要让别人成为那你任务链上的依赖 –heisenberg.liu
需要执行力的方案一般都是简单的方案 –heisenberg.liu
没有落地的事情等于没有做 –somebody
自己去想办法解决问题，而不是等别人回消息 –somebody
重要的事情马上就做，等一会都是做不了的 –somebody
不要做重复的低价值的事情，多想想这个需求源头的上下文 –heisenberg.liu
不要在屎里淘金，想办法搞优质信息源 –somebody
SRE需要配置最佳默认参数的能力，也需要批量修改这些参数的能力 –《企业云计算》
杂活做的越多，杂活就越多 –heisenberg.liu
sre 50%的时间用来运维，50%的时间用来研发 –《企业云计算》
过早的优化是万恶之源，过早的代码抽象也是万恶之源 –somebody
人脑接收知识的速度是有限的 –somebody
如果有人不让你看书，那就离开这个人，或者离开这个环境 –heisenberg.liu
做知识库的团队是混子 –somebody
标准的价值是由客户来决定的 –《ITIL 4 》
英雄主义：长时间工作并独立排查故障，长时间的工作也会对工作本身感到倦怠。凡事想成为英雄的人，他们只对自己的成就感兴趣，对团队协调工作置若罔闻 –《ITIL 4 》
不是所有问题都需要定位根因，取决于问题发生频率和故障范围 –《ITIL 4 》

回顾了一下2023年的自己定的计划，总共就2个一个都没完成，KPI达成率0% 😄

结合敏捷运维、敏捷项目管理、OKR的思想，我在年初就给自己定下全年计划，就是不合理的。回想去年、前年，我有些计划就是半路杀出并在优先级上pk过了其他任务。并且有些任务无法完成，这是应该是一个正常状态。so，不给自己立太多flag。

2025年计划：

一些东西继续
想想怎么做产出
掌握一个其他赛道
PG···没想好还要怎么做
想办法重拾健身

pg数据库运维经验2024

Wed, 08 Jan 2025 00:00:00 +0000

这篇文章主要是讲pg运维常见问题，两三年见一次的疑难杂症就不说了。

主要是技术性运维总结，主打通俗易懂和快速上手，尽量避免源码层面等深入分析。

SQL性能与执行计划
#

执行计划突变
#

pg官方不支持hint功能，并且计划永远不支持！ PG社区大概是这个意思"我们的优化器是完美的，如果当前执行计划不够优秀，那是开发不懂优化”。

不管pg社区怎么看，生产环境的执行计划突变问题是时常发生的，而且我们没有ORACLE那样原生且丰富的绑定执行计划手段来处理问题。这对生产运维来说是一个挑战，例如：某天早上，一个敏感的sql突然执行计划改变了，运行时间从0.1s上涨到1s，由于SQL有一定的并发导致数据库的cpu打满，业务感知明显。由于我们没有绑定执行计划的手段，此时我们唯二能做的快速恢复手段就是1.收集统计信息 2.scale up扩容cpu。

这里的快速恢复手段有个问题是：收集统计信息一定有用吗？好的DBA可以找到优化器中的关键问题步骤在哪，但是也不能快速脑补一个完整的执行计划出来，特别是SQL比较复杂的时候。收集统计信息这个恢复手段，实际上把SQL优化问题返还给了优化器，同时相信优化器是可以胜任这个工作的。虽然这看上去有些扯，但是在PG数据库中，绝大部分情况是有用的（对于已知收集统计信息无用的场景，见"order by limit问题"小节)。

为什么执行计划会突变且性能变差？

执行计划是基于成本的，而成本又基于统计信息，统计信息又是永远滞后的
SQL足够复杂的话执行路径就会有非常多种，优化器会根据成本选择最优的一条
PG提供了很多优化器参数可以调整，目的是以适配本地硬件设置（如seq_page_cost ,effective_cache_size等等），我们可以通过调整这些参数来微调优化器的倾向。但是这些参数太底层，虽然理论上是有优化空间，但都是牵一发而动全身的。特别是数据库上线后，调整这些参数就是一个极高风险的操作。从这些参数设置的理由来看，也可以推测执行计划不可能是100%完美的，因为优化器的推理也依赖环境

即使强如oracle，提供了各种方案稳固执行计划，它也保证不了SQL 100%不会出问题，因为SQL、数据、统计信息、绑定变量等等都是动态的。对于PGer来说还想不了那么远，不过我们可以尽可能地考虑稳定执行计划的方案，如下：

不要用太多的表连接。表越多可能的执行计划也就越多，甚至PG GEQO会放弃生成所有的执行计划，这就降低了最优执行计划的概率
不要写太过复杂的SQL。还要考虑SQL可能是框架（ORM）生成而不是业务人员手工编写的，这样的SQL一般是为了实现某个目标而几乎不考虑SQL的简洁性和阅读性，优化起来十分棘手。
不要乱建索引以迷惑优化器，必须有明确的目标
调整表的统计信息搜集阈值autovacuum_vacuum_scale_factor（参考“统计信息收集不及时”小节）
可以使用pg_hint_plan来提示优化器。

pg_hint_plan
#

pg_hint_plan是第三方插件，通过hint来提示优化器选择正确的执行计划。 pg_hint_plan支持：

指定扫描方式（如索引扫描）、连接方式（NL/HASH/MERGE）、连接顺序、memoize、指定预估行数、并行、GUC参数
通过hint_plan.hints绑定sql的执行计划，不需要改变业务SQL文本

pg_hint_plan缺陷：

子查询、外部表、CTE、视图、PL/SQL等有使用限制
compute_query_id会把hint当做注释忽略
未知的bug

这个插件虽然在持续更新，但是（我）还没有找到大规模生产应用的案例。另外我们在少量的生产应用场景中发现了一些问题，执行计划可能不会生效，这跟jdbc执行计划缓存有关系，至于有没有其他问题暂时不好下定论。总之pg_hint_plan是个好东西，但是生产大规模部署有待商榷。推荐静待其变，可以试用但不要对它产生依赖性。

统计信息收集不及时
#

统计信息是sql优化的基础，pg统计信息并不难但还是有很多人没弄明白。

pg的统计信息主要看这3个表：pg_class、pg_stat_all_tables、pg_stat

-- pg_class看pages和tuples
select relname,relpages,reltuples::bigint from pg_class where relname='lzlpg'\gx
-[ RECORD 1 ]------
relname | lzlpg
relpages | 187501
reltuples | 6000032

--pg_stat_all_tables看活元组、死元组，上次统计信息收集时间
 select relname,n_live_tup,n_dead_tup,last_analyze,last_autoanalyze from pg_stat_all_tables where relname='lzlpg'\gx
-[ RECORD 1 ]----+------------------------------
relname | lzlpg
n_live_tup | 6000032
n_dead_tup | 0
last_analyze | 2025-01-04 15:54:44.553057+08
last_autoanalyze | [null]

--pg_stats看列的统计信息，每个字段都需要了解含义
 select * from pg_stats where tablename='lzlpg' and attname='a'\gx
-[ RECORD 1 ]----------+-------
schemaname | public
tablename | lzlpg
attname | a
inherited | f
null_frac | 0
avg_width | 70
n_distinct | -1
most_common_vals | [null]
most_common_freqs | [null]
histogram_bounds | [null]
correlation | [null]
most_common_elems | [null]
most_common_elem_freqs | [null]
elem_count_histogram | [null]

统计信息过久很有可能会造成SQL执行计划改变，引起SQL性能问题。此时就需要查看pg_stat_all_tables表的last_autovacuum,last_autoanalyze时间来判断表的收集是不是滞后了。

为什么要调整？因为表的统计信息收集阈值autovacuum_analyze_scale_factor 默认值是0.1，也就是数据变化达到10%时，才会收集统计信息。例如一个10亿数据的表，数据变化达到1亿时才会收集，频率可能太低了。

应该结合是否核心业务表、SQL表连接个数、SQL复杂度、表访问频率、月初越界问题、数据倾斜问题等判断是否需要针对性的调整表的autovacuum_vacuum_scale_factor,autovacuum_analyze_scale_factor以提高统计信息收集频率，降低SQL执行计划突变的概率，同时也要避免收集过于频繁老是跑vacuum浪费资源。

到底该调整到多少？举个例子：

以月表（或月分区表）及SQL统计当天数据为例，由于autovacuum_analyze_scale_factor =0.1，月表在前10天基本每天都会收集，在第12天左右的时候可能不会收集，这时候统计信息可能越界，执行计划就有可能有问题。为了保证月表在每月的10-31天都收集统计信息，应该把autovacuum_analyze_scale_factor设置得小于0.03，所以推荐autovacuum_analyze_scale_factor=0.02

参数调整参考（请考虑表上的业务数据模型！）：

参数名	默认值	建议值
`autovacuum_vacuum_scale_factor`	`0.2`	`0.04`
`autovacuum_analyze_scale_factor`	`0.1`	`0.02`

优化器可能选择其他索引而不是主键
#

一般来说主键的过滤性已经是最高了，但是优化器可能也不会选择走主键

--复现命令
create table t1(a char(1000) primary key,b char(1000));
insert into t1 select md5(g::text),md5(g::text) from generate_series(1,10000) g;
create index idxa on t1(a);
create index idxb on t1(b);
analyze t1;

explain (analyze,buffers) select * from t1 where a='qwer' and b='qwer';
explain (analyze,buffers) select * from t1 where a='qwer' and b||''='qwer';

--a、b字段有同样的过滤性，但是优化器没有走主键而是走普通索引
explain (analyze,buffers) select * from t1 where a='qwer' and b='qwer';
 QUERY PLAN 
------------------------------------------------------------------------------------------------------------
 Index Scan using idxb on t1 (cost=0.41..5.43 rows=1 width=2008) (actual time=0.045..0.046 rows=0 loops=1)
 Index Cond: (b = 'qwer'::bpchar)
 Filter: (a = 'qwer'::bpchar)
 Buffers: shared hit=3

--强行走主键，cost只多一丢丢丢
explain (analyze,buffers) select * from t1 where a='qwer' and b||''='qwer';
 QUERY PLAN 
------------------------------------------------------------------------------------------------------------
 Index Scan using idxa on t1 (cost=0.41..5.44 rows=1 width=2008) (actual time=0.079..0.079 rows=0 loops=1)
 Index Cond: (a = 'qwer'::bpchar)`
 Filter: (((b)::text || ''::text) = 'qwer'::text)
 Buffers: shared read=3

虽然a、b两个字段类型和选择率是一样的，但是优化器没有选择走主键而是走了普通索引，从cost来看走主键的cost多了0.01。

这有什么问题？

从当前这个表数据分布来看选择普通索引问题不大，但是数据一旦变化，两个索引的执行计划效率就会有差别：

alter table t1 set (autovacuum_enabled ='off');
insert into t1 select md5(g::text),'repeat' from generate_series(20001,30000) g;

--b='repeat'过滤性很差，但是还是走b字段索引
explain (analyze,buffers) select * from t1 where a='qwer' and b='repeat';
 QUERY PLAN 
--------------------------------------------------------------------------------------------------------------
 Index Scan using idxb on t1 (cost=0.41..5.43 rows=1 width=2008) (actual time=15.823..15.824 rows=0 loops=1)
 Index Cond: (b = 'repeat'::bpchar)
 Filter: (a = 'qwer'::bpchar)
 Rows Removed by Filter: 10000
 Buffers: shared hit=2511

--对比走主键的执行计划
 explain (analyze,buffers) select * from t1 where a='qwer' and b||''='repeat';
 QUERY PLAN 
------------------------------------------------------------------------------------------------------------
 Index Scan using idxa on t1 (cost=0.41..5.44 rows=1 width=2008) (actual time=0.041..0.041 rows=0 loops=1)
 Index Cond: (a = 'qwer'::bpchar)
 Filter: (((b)::text || ''::text) = 'repeat'::text)
 Buffers: shared hit=3

即使真实的过滤性不好，优化器仍然选择走普通索引，但是走普通索引的效率要低很多，因为shared hit=2511远大于shared hit=3。如果是敏感业务sql或者数据量比较大的时候，就会有问题，这个问题在生产中也常见。解决办法：

手动收集统计信息；调高统计信息收集频率
pg_hint_plan
改写sql让其不能走普通索引

order by limit问题
#

order by limit的sql已是一个常见的问题了，网上案例和分析也比较多，这里就不详细分析了（可以参考我写这篇ORDER BY limit 10比ORDER BY limit 100更慢)。根本原因在于优化器目前无法评估数据以索引顺序存放在表的哪个位置，可能数据靠后而导致扫描过多的数据才返回limit。注意这个场景不是仅出现在order by limit，任何可以用到排序操作的+limit都可能有这个问题，如：group by +limit、distinct +limit、merge..

解决办法：

SQL改造：添加表达式防止走到排序列的索引上（含主键），如 order by ''||col1 limit xxx
创建复合索引：创建排序字段的索引字段的复合索引，优化器可能会选择这个索引，效率一般都比排序字段的索引高。这个方案也不用动sql。

表膨胀
#

某个东西阻止了死元组回收
#

抛开autovacuum配置问题和一些边缘场景，常见的阻塞是：

长事务。注意：不是同一个表的长事务也会阻止死元组回收；查询语句也会造成这个问题
复制槽。复制槽延迟和死的复制槽会造成这个问题

这两种常见都是比较好解决的，1.terminate长事务会话 2.删除复制槽或者让消费端分析消费为什么这么慢。

update并发高导致表膨胀
#

不同于某个东西阻止vacuum回收死元组，频繁的update导致表膨胀是因为死元组生成的速度快于vacuum回收的速度。一般来说这个场景的表的pg_stat_all_tables.n_tup_upd比较高，如果是因为表膨胀问题发现需要做repack的话，最好同时评估下是不是表的写入量大，应避免反复的手工repack。此时就需要调整表/索引的fillfactor参数。

原理参考这篇文章从很慢的唯一索引扫描到索引膨胀，结论我直接copy下来：

fillfactor原理：

fillfactor相当于表或索引的水位线，在INSERT数据时，插入到page的fillfactor线就到下一页去插入。fillfactor本身是为了给update留一定的空间，防止update频繁的去寻找新的page。

虽然表和索引都有fillfactor，他们的目的是一样的（为了update），但是具体细节有很大区别：

表：如果表的某个page上还有留有空间，那么update可以在这个page中进行，不需要申请新的page或者到其他有空闲空间的page上去。不仅如此，因为PG 独有的HOT特性，页内更新不会更新索引，当然也就会减缓索引膨胀
索引：不同的数据行或者相同数据行的页外更新，会新生成索引条目。fillfactor给索引页留下余量，会极大的减缓索引分离问题。

当然，fillfactor的设置跟业务模型是息息相关的，如果数据类似日志那样是递增且完全没有更新的，那么表和索引的fillfactor设置成100无可厚非。但是大部分业务表总是有更新的，表和索引fillfactor就不应该设置成100，如果是频繁的update，那么fillfactor应该设置得更低。然而，pg默认的fillfactor如下：

表默认 fillfactor=100
索引默认 fillfactor=90

推荐设置：

alter table lzlpg set (fillfactor=60);
alter index lzlpg_pkey set (fillfactor=70);
--以上命令只会对新page生效，对存量page需要做repack

--repack:
1.检查是否有长事务，有则先处理长事务
2.nohup pg_repack -d lzldb --table lzlpg -p 6666 -no-kill-backend > pgrepack_lzlpg_log.log 2>&1 &

长事务问题
#

长事务的知识点没有多少，及时告警及时处理就行了，但长事务问题绝对值得拿出来单独批斗。

长事务会导致许多问题，例如：

锁不释放导致应用阻塞
wal不回收导致磁盘告警
死元组不回收导致sql性能下降
还有些奇葩性能问题跟长事务相关
…

pg的长事务危害要比oracle、mysql来得大的多，pg中的长事务一定要严格管理。

子事务问题
#

“Subtransactions are basically cursed. Rip em out.”

子事务会造成很多问题，也是我们常踩的坑，在行业中也经常遇到子事务导致的问题。

行业踩坑记录：

Waiting for Postgres 17: Configurable SLRU cache sizes for increased performance

Subtransactions-overflow-and-the-performance-cliff

Why we spent the last month eliminating PostgreSQL subtransactions

子事务的出现：

PL/pgSQL functions containing a block with an exception clause
savepoints
JDBC+autosave=always （默认autosave=never ）
ODBC

注意OGG使用ODBC驱动，ODBC不能关闭子事务。

GaussDB提供的ODBC可以关闭子事务，参数ForExtensionConnector

所以我们可以建议应用使用子事务不超过64个，但很难建议他们不去使用OGG，因为脱O意味着使用依赖OGG 的数据同步工具。

子事务问题出现的场景和现象：

1(+)个长事务+子事务溢出+高并发业务，性能急剧下降
子事务溢出(64+)，性能稍微下降
子事务溢出(64+)+multixact，性能急剧下降
1(+)个长事务+1(+)个子事务，查询库性能急剧下降

pg17的提升：

SLRU是clog、multixact、subtrans等用来在共享内存中管理事务关系的。相关的源码定义如下：

/* Number of SLRU buffers to use for subtrans */
#define NUM_SUBTRANS_BUFFERS	32 //SLRU页面个数32个，这是共享内存中的

/*
 * Each backend advertises up to PGPROC_MAX_CACHED_SUBXIDS TransactionIds
 * for non-aborted subtransactions of its current top transaction. These
 * have to be treated as running XIDs by other backends.
 *
 * We also keep track of whether the cache overflowed (ie, the transaction has
 * generated at least one subtransaction that didn't fit in the cache).
 * If none of the caches have overflowed, we can assume that an XID that's not
 * listed anywhere in the PGPROC array is not a running transaction. Else we
 * have to look at pg_subtrans.
 */
#define PGPROC_MAX_CACHED_SUBXIDS 64	//超过64个则溢出，each backend

pg17对SLRU的提升：新增GUC参数可以配置SLRU槽的个数，拆分现有的SLRU锁由单个集中控制锁变为多个bank锁

提升效果：

（https://www.pgevents.ca/events/pgconfdev2024/sessions/session/53/slides/27/SLRU%20Performance%20Issues.pdf）

子事务处理方案：

开发规范：不要用savepoints，考虑on conflict语法处理写入冲突
开发规范：不要用exception
开发规范：确保jdbc没有显示打开autosave=always
添加监控：针对性的监控pg_stat_slru
添加监控：针对性的监控SAVEPOINT and EXCEPTION
CDC规范：谨慎使用ODBC，OGG或其他用到ODBC的工具，需要切割事务，一个大事务最高子事务个数上限为5W
升级版本：升级到PG17

并发与性能
#

快照和并发参数调整
#

参数名	参数类型	默认值	建议值	是否需要重启
`old_snapshot_threshold`	cpu	-1（社区版）	-1	是
`max_parallel_workers_per_gather`	cpu	2	0	否

old_snapshot_threshold参数打开很容易引起性能问题，网上资料已经很多了自行搜索，哪怕是需要重启数据库，也强烈推荐关闭参数。

max_parallel_workers_per_gather 参数会自动开墙大sql的并行，但是并行为2效率不会成比例提高2倍，参数建议在特殊场景下使用，如跑批时显示指定并行度。由于不需要重启，也就顺手一改的事。

关闭old_snapshot_threshold会不会有问题？

不会。old_snapshot_threshold参数目的是为了限制长事务，因为pg长事务很容易引起性能问题，但是参数本身也会引发性能问题就得不偿失了。

处理长事务可以很多手段：

长事务监控。这是最重要的，而且监控已经比较成熟了。
设置statement_timeout，默认0
设置transaction_timeout ，默认0，版本17=+支持
设置lock_timeout ，默认0，DDL语句建议会话级别开启
设置idle_in_transaction_session_timeout，默认0，已开启2h
设置idle_session_timeout ，默认0，这个场景没用

高并发提交导致LWLOCK:WALWrite
#

案例-insert value偶发慢分析

记忆点：

IO:WALWrite只有1个，而LWLOCK:WALWrite有几十个
不能直接看到LWLOCK的blocking chain，但是我可以从源码中得知，LWLOCK:WALWrite在等待IO:WALWrite
在这种并发高的小事务场景中，提高wal buffer内存大小理论上效果不会太理想

会引起什么问题？

并发写入阻塞，写入接口变慢，活动会话可能上涨
高并发小事务无法压榨磁盘IO

解决办法：

业务打散并发写入
业务合并提交
分析FPI，尝试减少FPI（参考FPI小节）
组提交（待研究）

WAL与延迟
#

FPI与checkpoint参数
#

pg的wal FPI发生在checkpoint后首次写入相关page时，所以checkpoint越频繁FPI出现的概率越高。

checkpoint频率与两个参数相关：

checkpoint_timeout
max_wal_size

原理如下：

(Egor Rogov PoStgreSQL 14 Internals)

max_wal_size默认是1GB，这对于负载高的库来说太小了，一般来说可以调大这个参数以减少FPI。

checkpoint_timeout默认是5分钟，目前来看比较合理。

FPI与离散写
#

即使调大了checkpoint的间隔，可能还是会有 FPI 问题，此时需要再排查业务是否有 UUID 离散写情况，可能需要业务改造为 sequence 或其他 UUID 方案。

找到具体索引示例：

1.查看FPI是否严重

--stats=record比较好用

pg_waldump -z --stats=record 00000001000001860000001B

2.排序哪个rel的FPW比较多

pg_waldump 00000001000001860000001B|grep FPW|awk -F ':' '{print $7}'|awk '{print $2}'|sort -n|uniq -c |sort -r|head -10

逻辑复制和复制槽
#

逻辑复制问题非常多，也是社区重点优化项之一，几乎每个版本都有很大提升。

逻辑复制和复制槽基础知识

spill问题
#

PG起库逻辑和spill导致起库慢问题分析

spill记忆点：

spill是逻辑解码的时候内存放不下事务信息了所以放到磁盘，spill文件存放的就是事务信息
每个walsender都有独立的解码，所以每个逻辑复制都有自己的spill
大事物spill时，会有大spill文件，一般文件数比较少
子事务spill时，每个子事务对应一个spill文件

版本：

PG12及以前是写死的4096条changes
PG13新增logical_decoding_work_mem参数，可调整内存大小以减少spill概率
PG14及以后支持流式复制Streaming
触发流式复制也需要一定的条件，所以即使有流式复制也可能会发生spill
PG17新增debug_logical_replication_streaming参数以强制触发流式传输

walsender阻止停库
#

PG停库逻辑和walsender阻止停库问题分析

其实任意进程不退出都会阻止停库，问题在于哪些比较容易搞出事。从停库代码流程来看archiver、walsender会常阻止停库，因为他们在停库阶段会做最后一次归档or日志传递。

如果停库卡在walsender，尝试用kill杀掉walsender而不是直接kill -9 ，此时checkpoint还没有跑完，强制停库会造成不一致停库。注意强制停库也最好用pg_ctl stop -D $PGDATA -m i来停库，而不是直接kill -9
如果停库卡在archiver，可以直接kill -9，因为checkpoint已经跑完了，库是一致性状态

分区表
#

分区表基础知识

由于PG分区表其实是很有特点的，有些特性知识不研究就不知道，开发一般弄不明白pg分区表，所以在使用分区表时会留下很多坑

分区表父表和子表索引不一致
#

由于创建子分区不规范，很多索引是在子表上建的（实际上不应该单独在子表上建索引），也没有做 ”所有子表创建索引+attach索引“的操作，导致父表其实没有索引或没用有效索引。父表因为没有数据所以其上没索引对业务没有影响，影响的是新建子分区时，只会继承父表索引，导致新的子表可能会缺少索引。

父表失效索引比较好处理，参考创建分区索引的正确姿势

--ONLY方式在分区主表上创建失效索引。快，会阻塞后续dml，会影响业务，需要关注长事务
CREATE INDEX IDX_DATECREATED ON ONLY lzlpartition1(date_created);
--CONCURRENTLY在各个分区子表上创建索引。慢，不会阻塞后续dml，不会影响业务，但需要关注DML长事务防止本身失败
create index concurrently idx_datecreated_202302 on lzlpartition1_202302(date_created);
--所有索引attach。快，不会发生业务阻塞
 ALTER INDEX idx_datecreated ATTACH PARTITION idx_datecreated_202302;

父表没有主键比较难处理，参考分区表添加主键和唯一索引

添加主键在主表上申请AccessExclusiveLock，阻塞一切。分区表上添加索引很慢，主键又会造成后续的阻塞，目前没有影响较小的在分区表上添加主键的办法。虽然没有达到目的，可以考虑用“attach唯一索引+非空约束”的办法；或者只能申请较长的停分区表业务，等待创建索引完成；或者通过第三方同步工具将数据插入一个带主键的分区表。

滥用default分区
#

default分区过大导致parition of创建子分区长期阻塞

原因很简单：分区表新增子分区时，由于建分区的语句需要校验default分区中的数据，保证新分区数据范围与default分区的现有数据不冲突，导致create table partition of读取了大量的default分区数据，新建分区一直未完成。随后阻塞扩大，业务数据无法查询和写入。

default分区滥用是普遍的问题！社区pg本来也没有提供interval分区功能，开发哪天忘记创建分区了，数据就跑到default分区，也不会有任何报错和告警。但是日复一日···default分区就越来越大，最后发版建分区搞出问题。

default分区过大不能一直这么放着，虽然attach建分区可以避开阻塞问题，但出于各种角度考虑还是需要排这个雷。

default分区数据处理方案1：

detach default子分区，然后合理创建子分区，再将default表数据回插到分区表中。
如有必要，可在detach且创建合理子分区后，创建一个空的default分区，以保持业务数据的连续性。
注意detach跟attach不同，detach需要主表的8级锁。PG14支持detach concurrently，但不能有default分区。

default分区数据处理方案2：

detach default子分区，然后合理创建子分区，detached后的default表attach成普通子分区，需要注意range的范围。
如有必要，可在detach且创建合理子分区后，创建一个空的default分区，以保持业务数据的连续性。
注意detach跟attach不同，detach需要主表的8级锁。PG14支持detach concurrently，但不能有default分区。

default分区数据处理方案3：

新建表所有数据通过dts同步
rename表

方案3看起来是最矬的，但是我个人最推荐。原因是如果你的手里有5套库需要处理，那么可以用精湛方案没问题，如果你的手里有200套库需要处理，那么要投入的人力成本，dts应该是最佳落地方案。

分区表select权限丢失导致执行计划异常
#

用户对分区子表没用select权限，会导致用户执行的sql不能访问子表的统计信息，从而导致执行计划异常。正常partition of创建的分区表是不带select权限的，从主表访问数据可以访问到，所以这是范围比较大的问题。

解决方案

让云平台解决，自动化处理
落地select子分区权限的开发规范

高并发分区全扫描和LWLock:lockmanager
#

这也是一个很常见的问题！

推荐看下aws的文档，写的很清楚了：https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/wait-event.lw-lock-manager.html

问题现象：

活动会话暴涨
LWLock:lockmanager等待事件严重
数据库性能cliff

发生场景：

sql查询多个分区
该sql并发较高

记忆点：

fastpath锁机制本身是为了“弱锁”快速访问，提升数据库并发而设计的
fastpath锁等级小于等于3。即是select、select for xxx、DML才能使用（弱锁便是锁模式必须小于ShareUpdateExclusiveLock，也就是1、2、3级锁有机会使用到fastpath）。换句话说就是为了正常业务都受益
FP_LOCK_SLOTS_PER_BACKEND，本地进程持有fastpath的锁不超过16个，超过16就要到内存中去获得锁，LWLock:lockmanager在此时产生
不仅是表，每个被访问的索引都要加锁
这个问题跟分区数量没有多大关系，即便分区比较少也可能触发LWLock:lockmanager等待导致性能下降

可以计算一下，如果一个分区表上有1个主键和2个普通索引，多少个分区就会用不到fastpath？

16/（3个索引+1表本身）-1父表本身=3个子分区

是的，3个子分区的全分区扫描就会可能会出现这个LWLock:lockmanager等待了。

如果是普通表的话，表上建16个索引也会用不到fastpath。

解决办法：

对于表不是特别大的，合并分区成普通表
sql加入分区过滤条件
减少索引（比较没用，因为一般子分区数就超过16个了）

难点：

在oracle脱O到PG库的场景中，由于oracle支持全局索引，主键和唯一索引可以不带分区键，到pg后主键和唯一索引必须要带分区键。

主键示例如下：

idxlzl(primarykey) --oracle
idxlzl(primarykey,partitionkey) --pg

常见的表上的sql是这样：

select col from tlzl where primarykey=12345;

这个场景要推动业务在这个sql上添加分区条件吗？很难。阻力在于“我已经传入主键了，你还要我怎样？如果我什么数据都知道，我还要查数据库吗？”

如果是这样，只能推荐改造分区表为普通表，目前没有想出其他好办法。

内存
#

对象过多导致relcache过大
#

记忆点：

relcache保留relation相关的元数据：oid、pg_class、分区表、子事务、行安全策略、统计信息、索引元数据、am等等。
每个会话都有自己的(rel)cache缓存系统数据（元数据等）
一般这个cache很小。当catalog很大且会话访问过所有catalog时，cache会变的很大
cache的管理很简单，没有删除机制和limit限制（其实有invalidation消息）
关闭会话会释放cache

解决办法：

减少对象，特别是要检查分区表子分区数是否太多了
设置激进的连接池断连参数，让业务连接中断更频繁

内存碎片问题
#

命令推荐：

cat /proc/meminfo|grep whatyouneed
cat /proc/buddyinfo

## cg内存
/opt/cgtools/cginfo -t perf -s mem 

#重点关注 pgscand/s直接内存回收指标，一般几万就代表有问题
sar -B -s "08:00:00" -e "09:00:00"
#min_free_kbytes设置:
cat /proc/sys/vm/min_free_kbytes
#所有进程的物理总内存使用量：
grep Pss /proc/[1-9]*/smaps | awk '{total+=$2}; END {printf "%d kB\n", total }'
#某进程PSS内存：
cat /proc/90875/smaps |grep Pss |awk '{sum+=$2 };END {print sum/1024}'
#某进程的RSS内存 ：
cat /proc/68729/smaps |grep Rss |awk '{sum+=$2 };END {print sum/1024}'
#某进程私有内存：
cat /proc/90875/smaps|sed '/zero/,/VmFlags/d' |grep Private |awk '{sum+=$2 };END {print sum/1024}'

min_free_kbytes：

（https://vivani.net/2022/06/14/linux-kernel-tuning-page-allocation-failure/)

当可用内存较低时kswapd守护进程会被唤醒以释放页

pages_low:当可用的空闲页面数量低于pages_low 时，buddy allocator会唤醒 kswapd 进程，内核开始将页换出到硬盘。
pages_min:当可用页面数量达到 pages_min时，说明页回收工作的压力就比较大，因为内存域中急需空闲页。分配器将以同步的方式执行 kswapd 工作，有时也称为直接回收。
pages_high:一旦 kswapd 被唤醒开始释放页面，只有在可用页面数量达到pages_high时，内核才认为该区域是“平衡的”。如果水位线达到pages_high，kswapd 将重新进入休眠状态。空闲页多于pages_high，则内核认为zone的状态是理想的。

vm.min_free_kbytes也就是min_pages线，十分重要的操作系统参数。非常低的值会阻止系统有效地回收内存，这可能会导致系统崩溃并中断服务。太高的值会增加系统回收活动，造成分配延迟，这可能导致系统立即进入内存不足状态。

优化效果：

min_free_kbytes调大+部署非业务时段drop cache，问题已经少很多了。

为什么是调高min_free_kbytes？

This is used to force the Linux VM to keep a minimum number of kilobytes free. The VM uses this number to compute a watermark[WMARK_MIN] value for each lowmem zone in the system. Each lowmem zone gets a number of reserved free pages based proportionally on its size.

min_free_kbytes调高的本质不是为了把对应的min page线提高已更高概率地触发直接内存回收，而是因为low page线在linux7以前是无法调整的，只能通过调高min page线以等比例的提高low page线以更容易触发异步回收，并给直接内存回收的触发创造缓冲时间。

Redhat 8 版本增加了2个内存参数来优化内存回收：watermark_scale_factor 可以在不调整min_free_kbytes情况下，抬高水位线。

建议开启大页：

大页在业务（pg库）申请连续内存的时候性能较好
大页也有助于减少page cache大小
shared_buffer可使用大页，需开启Huge_pages和操作系统已开启大页
生产开启了大页的库，性能有提升，问题更少
aws大页标准：除了几个测试套餐外，其他均默认开启大页且不可关闭

Huge_pages parameter is turned on by default for all DB instance classes other than t3.medium,db.t3.large,db.t4g.medium,db.t4g.large instance classes. You can’t change the huge_pages parameter value or turn off this feature in the supported instance classes of Aurora PostgreSQL.

cgroup和主机内存错位
#

cgroup中的内存达到cg内存限制后，kswapd 进程会优先回收cg中的内存，云主机售卖资源和cgroup配置，可能存在主机空闲内存在水位之上，而cg内存紧张，主机层面的pages_low ，导致kswapd 不会异步回收主机内存也不会回收cg内存，最终是通过触发直接回收内存CG中的DB内存需求。

根因在于cgroup中没有单独的free page内存管理机制。

这种情况只能把cg内存调高，云主机内存更多的超卖，以达更容易达到主机的pages_low。

shared_buffer和pagecache
#

pg是double buffer机制，目前还没有direct IO。

double buffer是指DB shared buffer一层共享内存，OS pagecache一层共享内存。在真实场景中，pagecache一般远大于shared buffer，而pagecache又是算在cgroup mem中的，没有算到监控cg内存中···

总之，要留足内存给pagecache使用，shared buffer不要超过太大（目前来看20GB足够），除非可以明显观察到等待事件中有buffer mapping相关内存等待，不然不要去调太大。

work_mem无法限制hash join/hash aggregate使用的内存
#

hash_mem_multiplier 用于限制基于hash-based operations的内存大小（应该包括hash join，hash agg等），限制是hash_mem_multiplier*work mem。hash_mem_multiplier默认为2。

在pg13以前虽然可以限制work mem，但是无法限制1个query使用了多少个hash操作，所以pg13增加了这个参数。也就是说13以前，是很难限制hash table的内存的。

在pg12-的生产环境中找到消耗300G内存的一个会话，罪魁祸首就是低版本没有hash table限制和执行计划错误的使用hash table

其他问题
#

排他备份和起库问题
#

正常来说，数据库停库再起库，起库的位置从pg_controldata中的LSN位置获取，但是如果PGDATA目录下有一个backup_label文件，启动位置LSN会从backup_label文件获取。

会引起什么问题：

磁盘快照直接打的是data目录快照，label文件有可能在里面，如果库大备份时间长的话，起库时间就很长
大问题：某些原因生产停库后，库启动会很久。根因在于起库的LSN应该从controldata中获取，而不是备份中

版本变化：

pg13:

pg_start_backup() pg_stop_backup()

支持排他和非排他模式，默认就是排他模式。排他模式会在start的时候在data目录下创建backup_label文件，stop的时候会清理。非排他模式start的时候不会创建label文件，stop的时候返回label信息。

pg15: pg_backup_start() pg_backup_stop()

函数名称变化，移除了排他备份模式。不会在启动备份的时候写backup_label文件，而是在结束备份的时候写入到备份区域。

pg_stat_activty无法查询
#

现象：

pg_stat_activty无法查询

当时的pstack如下：

#0 pgstat_read_current_status () at pgstat.c:3642
#1 0x0000000000727181 in pgstat_read_current_status () at pgstat.c:2788
#2 pgstat_fetch_stat_numbackends () at pgstat.c:2789
#3 0x000000000083f2ee in pg_stat_get_activity (fcinfo=0x25c2d98) at pgstatfuncs.c:575
#4 0x000000000065058f in ExecMakeTableFunctionResult (setexpr=0x25b1d28, econtext=0x25b1c48, argContext=<optimized out>, expectedDesc=0x2545218, randomAccess=false) at execSRF.c:234
#5 0x00000000006609dc in FunctionNext (node=node@entry=0x25b1b38) at nodeFunctionscan.c:94
#6 0x000000000065110c in ExecScanFetch (recheckMtd=0x660700 <FunctionRecheck>, accessMtd=0x660720 <FunctionNext>, node=0x25b1b38) at execScan.c:133

分析：

代码定位比较明确，卡在st_changecount成为奇数进入死循环。

什么场景会触发？OOM（可复现），backend异常退出（可能），terminate（maybe）；这三个场景不代表一定会造成这个问题。

社区邮件没有讨论出结果，目前来看触发概率不高。

解决方案：重启数据库

连接问题和连接池问题
#

IO error报错
#

IO error报错一般是业务层与数据库连接断开，业务层仍在使用已断连的连接导致的报错。该问题出现比较频繁，而且由于整个链路上涉及的组件多、知识域宽，所以诊断起来比较困难，以下做一个简单总结。

已知的主动断连场景：

1.hikari maxLifetime 现象：会话保持时间与参数一致。可能报错原因：业务显示事务执行 select 未提交，连接池断开会话，业务报 io error；could not rollback 相关错误。

pg.datasouce.maxLifetime

2.druid timeout 现象：业务 sql 执行超 20s 后连接断开

spring.datasource.dynamic.druid.socketTimeout=20000 
spring.datasource.dynamic.druid.connectTimeout=20000 
改为
spring.datasource.socketTimeout=3600000
spring.datasource.connectTimeout=3600000 

业务容器扩容和数据库连接上限
#

业务横向扩容和pg库的连接瓶颈：

HikariCP目前已是SpringBoot默认的连接池，伴随着SpringBoot和微服务的普及，HikariCP 的使用也越来越多。业务每扩容一个pod，数据库连接数都会上涨。原因在于maximumPoolSize虽然每个pod中配置没有动，但业务节点横向扩展了。从已有节点数、增加节点数、现有数据库连接总数可以成比例的计算出来数据库的空闲连接会加多少。

应用可以无状态的横向扩容，但是数据库不是，pg的连接上限参数max_connections，应用成倍的扩容是有可能造成idle连接数就打满了。max_connections的调整是个很麻烦的工作因为要重启数据库生效。

pg库连接上限:

还有一个点在于，业务无限横向扩容，max_connections应该随云实例套餐调整而调整，但是可以无限往上调整吗？很明显不是的。pg库，无论什么库，idle连接越多性能都会下降。

可参考AWS的做法： max_connections与套餐相关，最大值5000 ,LEAST({DBInstanceClassMemory/9531392},5000).这可以减少人力运维连接数，也给出了比较合理的最大值

PG起库逻辑和spill导致起库慢问题分析

Sat, 04 Jan 2025 00:00:00 +0000

问题现象-起库缓慢
#

版本pg13.2

数据库启动缓慢，startup进程在读取spill文件，文件名在变化。查看spill文件也很慢，ls -l最后跑出来有800w个文件spill文件。

为什么有上千万个spill文件
#

wal段和LSN的含义
#

LSN
#

LSN总体是一个64位的bigint，LSN实际长这样42D3B/1732C540（hex），斜杠/前是32位逻辑日志号，/后32位是段号+块号+块内偏移。这4个部分分别是：

32位	8位	11位	13位
逻辑日志号	日志段号	块号	块内偏移

块内偏移 8192=2^13

块号=16M（默认wal段大小）/8192

wal segment
#

wal文件名由3组16进制数字组成。

以8k的wal文件0000000300042D3B00000002为例：

32位	32位	32位
timeline	逻辑日志号	日志段号
00000003	00042D3B	00000002

可以看出LSN可以定位到wal文件名及文件中offset位置。

其中，LSN斜杠/前是逻辑日志号，斜杠/后8位的日志段号下面都会用到。

spill文件名转换
#

复制槽名：logical_ex2209_rep

spill文件名：xid-407989064-lsn-42D1E-20000000.spill

42D1E不是一个完整的LSN，不能直接用pg_walfile_name来定位wal文件名。42D1E是一个逻辑日志号，如果直接过滤文件名含42D1E的wal文件，可以找到16个wal文件。

能否通过数字20000000定位到wal日志段号从而定位到哪一个文件呢？

spill文件名：

/*
 * Given a replication slot, transaction ID and segment number, fill in the
 * corresponding spill file into 'path', which is a caller-owned buffer of size
 * at least MAXPGPATH.
 */
static void
ReorderBufferSerializedPath(char *path, ReplicationSlot *slot, TransactionId xid,
 XLogSegNo segno)
{
 XLogRecPtr recptr;

 XLogSegNoOffsetToRecPtr(segno, 0, wal_segment_size, recptr);

 snprintf(path, MAXPGPATH, "pg_replslot/%s/xid-%u-lsn-%X-%X.spill",
 NameStr(MyReplicationSlot->data.name),
 xid,
 (uint32) (recptr >> 32), (uint32) recptr);
}

pg_replslot/%s和xid-%u-lsn比较好理解，就是复制槽名称和xid。后面的recptr还要再看下定义：

/*
 * Pointer to a location in the XLOG. These pointers are 64 bits wide,
 * because we don't want them ever to overflow.
 */
typedef uint64 XLogRecPtr;

XLogSegNoOffsetToRecPtr是通过wal日志段号、段大小、offset计算LSN:

#define XLogSegNoOffsetToRecPtr(segno, offset, wal_segsz_bytes, dest) \
 (dest) = (segno) * (wal_segsz_bytes) + (offset)

XLogRecPtr就是LSN！那么

(uint32) (recptr >> 32)表示取LSN前32位，(uint32) recptr)取LSN后32位。

LSN前32位也就是刚才看到的LSN前半段，lsn-42D1E；LSN后32位实际上信息多了，这里只要LSN后32位中的前几位的段号即可。

因为传入的offset=0，也传入了segno，那么根本不需要wal日志段内偏移量信息，就可以计算出dest的值。wal_segsz_bytes的真实值是128M*1014*1024，将XLogSegNoOffsetToRecPtr中的式子转化下为：

segno= dest/(128*1024*1024)
-- 再把16进制20000000转化下
segno= x'20000000'::int/(128*1024*1024)
segno= 4

可以从式子算出日志段号segno，也就可以定位到wal文件号了。

所以，这里的spill文件名：xid-407989064-lsn-42D1E-20000000.spill对应的wal文件为

逻辑日志号=42D1E，段号=04：

ls 42D1E*04
0000000200042D1E00000004

pg_waldump可以看到xid 407989064在里面。

实际上wal大小在实例创建后也是固定的，即(128*1024*1024)是一个常量，那么segno跟(uint32) recptr绝对相关，但不相等。也就是说切换一个wal日志就会切换一个spill。

最后总结spill文件生成规则如下：

同一个事务id，如果跨wal就会产生多个spill。如：一个不含子事务的大事务跨越3个wal，就会对应3个spill文件
不同的事务id对应不同的spill。如：1000w个子事务对应1000w个spill

spill文件名结构xid-407989064-lsn-42D1E-20000000.spill：

xid	lsn前32位；即wal逻辑日志号	由wal日志段号换算；不等于段号
xid-407989064	lsn-42D1E	20000000

## 恢复出的环境

[postgres]$ ll |head -100
total 40000276
-rw------- 1 postgres postgres 184 Dec 6 15:20 state
-rw------- 1 postgres postgres 196 Dec 6 13:25 xid-407989064-lsn-42D1E-0.spill
-rw------- 1 postgres postgres 208 Dec 6 13:25 xid-407989064-lsn-42D1E-20000000.spill
...
-rw------- 1 postgres postgres 540 Dec 6 16:44 xid-407989064-lsn-42D2A-D0000000.spill
-rw------- 1 postgres postgres 152 Dec 6 13:09 xid-407989065-lsn-42D1D-C8000000.spill
-rw------- 1 postgres postgres 152 Dec 6 13:09 xid-407989066-lsn-42D1D-C8000000.spill
-rw------- 1 postgres postgres 152 Dec 6 13:09 xid-407989068-lsn-42D1D-C8000000.spill
-rw------- 1 postgres postgres 152 Dec 6 13:09 xid-407989070-lsn-42D1D-C8000000.spill
-rw------- 1 postgres postgres 152 Dec 6 13:09 xid-407989072-lsn-42D1D-C8000000.spill
-rw------- 1 postgres postgres 152 Dec 6 13:09 xid-407989076-lsn-42D1D-C8000000.spill
-rw------- 1 postgres postgres 152 Dec 6 13:09 xid-407989079-lsn-42D1D-C8000000.spill
-rw------- 1 postgres postgres 152 Dec 6 13:09 xid-407989080-lsn-42D1D-C8000000.spill
-rw------- 1 postgres postgres 152 Dec 6 13:09 xid-407989082-lsn-42D1D-C8000000.spill

[postgres@lzlhost /myhost/liuzhilong/pg_replslot/logical_ex9e15_rep]$ ll |awk '{print $9}'|awk -F '-' '{print $2}'|sort|uniq -c|wc -l
10000003
[postgres@lzlhost /myhost/liuzhilong/pg_replslot/logical_ex9e15_rep]$ ll |wc -l
10000070

所以我们在实际环境中看到了10000070个文件，文件的distinct xid有10000003个，也就是说1个父事务跨越约70个wal文件，这个父事务有1000w个子事务。

复制槽溢出测试
#

--发布订阅搭建复制链路
logical_decoding_work_mem = 64MB #pg_ctl reload
wal_segment_size =128 MB

--source
CREATE TABLE replication_table (
 id BIGSERIAL PRIMARY KEY,
 column1 char(2000),
 column2 char(2000),
 column3 char(2000)
);
create publication pub_test for table replication_table ;

--dest
CREATE TABLE replication_table (
 id BIGSERIAL PRIMARY KEY,
 column1 char(2000),
 column2 char(2000),
 column3 char(2000)
);

CREATE SUBSCRIPTION sub_test
CONNECTION 'host=127.0.0.1 port=8094 dbname=lzl user=lzl password=qwer'
PUBLICATION pub_test;

--source
select * from pg_replication_slots;

大事务、无子事务、复制表溢出测试
#

--创建一个大事务暂时不提交
begin;
insert into replication_table(column1,column2,column3) 
select 'a','b','c' from generate_series(1,1000000) g;

--复制槽溢出
 ll
total 331924
-rw------- 1 postgres postgres 184 Dec 9 20:22 state
-rw------- 1 postgres postgres 88226964 Dec 9 20:22 xid-5074343-lsn-163-38000000.spill
-rw------- 1 postgres postgres 119698488 Dec 9 20:22 xid-5074343-lsn-163-40000000.spill

大事务提交后，等待消费直至复制链路延迟为0，spill文件消失

M=# select pid,usename,sent_lsn,write_lsn,flush_lsn,replay_lsn,write_lag,flush_lag,replay_lag,reply_time from pg_stat_replication;
 pid | usename | sent_lsn | write_lsn | flush_lsn | replay_lsn | write_lag | flush_lag | replay_lag | reply_time 
--------+---------+--------------+--------------+--------------+--------------+-----------+-----------+------------+------------------------------
 163525 | lzl | 163/4996E1C8 | 163/4996E1C8 | 163/4996E1C8 | 163/4996E1C8 | [null] | [null] | [null] | 2024-12-09 20:25:35.14769+08
(1 row)

M=# select pid,usename,pg_wal_lsn_diff(pg_current_wal_lsn(),sent_lsn) diff_sent_mb,pg_wal_lsn_diff(pg_current_wal_lsn(),write_lsn) diff_write_mb,pg_wal_lsn_diff(pg_current_wal_lsn(),flush_lsn) diff_flush_mb,pg_wal_lsn_diff(pg_current_wal_lsn(),replay_lsn) diff_replay_mb,pg_walfile_name_offset(sent_lsn) sentoffset,pg_walfile_name_offset(write_lsn) writeoffset,pg_walfile_name_offset(flush_lsn) flush_lsn from pg_stat_replication;
 pid | usename | diff_sent_mb | diff_write_mb | diff_flush_mb | diff_replay_mb | sentoffset | writeoffset | flush_lsn 
--------+---------+--------------+---------------+---------------+----------------+-------------------------------------+-------------------------------------+-------------------------------
 163525 | lzl | 0 | 0 | 0 | 0 | (000000010000016300000009,26665416) | (000000010000016300000009,26665416) | (000000


[/mypg/pg8094/data/pg_replslot/sub_test]$ ll
total 357392
-rw------- 1 postgres postgres 184 Dec 9 20:23 state
-rw------- 1 postgres postgres 88226964 Dec 9 20:22 xid-5074343-lsn-163-38000000.spill
-rw------- 1 postgres postgres 137696328 Dec 9 20:23 xid-5074343-lsn-163-40000000.spill
-rw------- 1 postgres postgres 26076708 Dec 9 20:23 xid-5074343-lsn-163-48000000.spill
[/mypg/pg8094/data/pg_replslot/sub_test]$ ll
total 4
-rw------- 1 postgres postgres 184 Dec 9 20:25 state2666
(1 row)

大事务、无子事务、非复制表溢出测试
#

--source 创建一个不相干的表，准备写入数据
CREATE TABLE no_replication_table (
 id BIGSERIAL PRIMARY KEY,
 column1 char(2000),
 column2 char(2000),
 column3 char(2000)
);

--创建一个大事务暂时不提交
begin;
insert into no_replication_table(column1,column2,column3) 
select 'a','b','c' from generate_series(1,1000000) g;

--溢出
[postgres@lzldb:MYINST:8094 /mypg/pg8094/data/pg_replslot/sub_test]$ ll
total 357492
-rw------- 1 postgres postgres 184 Dec 9 20:09 state
-rw------- 1 postgres postgres 107511456 Dec 9 20:08 xid-5074106-lsn-163-28000000.spill
-rw------- 1 postgres postgres 137698804 Dec 9 20:09 xid-5074106-lsn-163-30000000.spill
-rw------- 1 postgres postgres 4308444 Dec 9 20:09 xid-5074106-lsn-163-38000000.spill

大事务、子事务、非复制表溢出测试
#

## 一次insert一行，每个insert一个子事务
echo "begin;">subtx.sql
for i in {1..1000000}
do
 echo "savepoint p$i;">>subtx.sql
 echo "insert into no_replication_table(column1,column2,column3) select 'a','b','c';">>subtx.sql
done


nohup psql -d lzl -f subtx.sql &

#执行过程中，观察到溢出80w+文件
[/myhost/pg8094/data/pg_replslot/sub_test]$ ll |wc -l
823749
[/myhost/pg8094/data/pg_replslot/sub_test]$ ll |head -10
total 1099532
-rw------- 1 postgres postgres 184 Dec 9 21:10 state
-rw------- 1 postgres postgres 1236 Dec 9 21:10 xid-5519686-lsn-163-70000000.spill
-rw------- 1 postgres postgres 252 Dec 9 21:09 xid-5519687-lsn-163-70000000.spill
-rw------- 1 postgres postgres 252 Dec 9 21:09 xid-5519688-lsn-163-70000000.spill
-rw------- 1 postgres postgres 252 Dec 9 21:09 xid-5519689-lsn-163-70000000.spill
-rw------- 1 postgres postgres 252 Dec 9 21:09 xid-5519690-lsn-163-70000000.spill
-rw------- 1 postgres postgres 252 Dec 9 21:09 xid-5519691-lsn-163-70000000.spill
-rw------- 1 postgres postgres 252 Dec 9 21:09 xid-5519692-lsn-163-70000000.spill
-rw------- 1 postgres postgres 252 Dec 9 21:09 xid-5519693-lsn-163-70000000.spill

数据库启动慢分析
#

startup进程起库流程分析
#

这里以堆栈编号逐栈解析起库流程：

11：main：没啥好说的

10：PostmasterMain：

在主循环前，会先调用起库流程 StartupPID = StartupDataBase();本质上是调用StartChildProcess(StartupProcess)

#define StartupDataBase()		StartChildProcess(StartupProcess)

9：StartChildProcess ：fork一个进程。该进程为启动postmaster的辅助进程，正常的子进程启动都走这个逻辑，在这一步fork。这里的入参AuxProcType=StartupProcess

8：AuxiliaryProcessMain：

因为MyAuxProcType=StartupProcess，所以走的是StartupProcessMain流程，这不同于walsender,walwrite,bgwriter这些子进程的流程。startup进程本身是为了宕机恢复读wal的进程，但是它还做了很多事情

	switch (MyAuxProcType)
	{
		case CheckerProcess:
			/* don't set signals, they're useless here */
			CheckerModeMain();
			proc_exit(1);		/* should never return */

		case BootstrapProcess:

			/*
			 * There was a brief instant during which mode was Normal; this is
			 * okay. We need to be in bootstrap mode during BootStrapXLOG for
			 * the sake of multixact initialization.
			 */
			SetProcessingMode(BootstrapProcessing);
			bootstrap_signals();
			BootStrapXLOG();
			BootstrapModeMain();
			proc_exit(1);		/* should never return */

		case StartupProcess: //这里这里这里这里
			/* don't set signals, startup process has its own agenda */
			StartupProcessMain();
			proc_exit(1);		/* should never return */

		case BgWriterProcess:
			/* don't set signals, bgwriter has its own agenda */
			BackgroundWriterMain();
			proc_exit(1);		/* should never return */

		case CheckpointerProcess:
			/* don't set signals, checkpointer has its own agenda */
			CheckpointerMain();
			proc_exit(1);		/* should never return */

		case WalWriterProcess:
			/* don't set signals, walwriter has its own agenda */
			InitXLOGAccess();
			WalWriterMain();
			proc_exit(1);		/* should never return */

		case WalReceiverProcess:
			/* don't set signals, walreceiver has its own agenda */
			WalReceiverMain();
			proc_exit(1);		/* should never return */

		default:
			elog(PANIC, "unrecognized process type: %d", (int) MyAuxProcType);
			proc_exit(1);
	}

7：StartupProcessMain：主要是为了调用StartupXLOG()

6：StartupXLOG：

函数注释：

This must be called ONCE during postmaster or standalone-backend startup

StartupXLOG无论怎样都会被postmaster调用，无论是否是崩溃停库还是一致性停库

	switch (ControlFile->state)
	{
 ...
			case DB_IN_PRODUCTION:
			ereport(LOG,
					(errmsg("database system was interrupted; last known up at %s",
							str_time(ControlFile->time))));
			break;

这跟log日志能对上，以下是log的停库起库输出：

2024-12-06 17:02:57.534 CST,,,447560,,65693cde.6d448,1325,,2023-12-01 09:54:38 CST,,0,LOG,00000,"database system is shut down",,,,,,,,,"","postmaster"
2024-12-06 17:03:49.536 CST,,,211844,,6752bdf3.33b84,1,,2024-12-06 17:03:47 CST,,0,LOG,00000,"ending log output to stderr",,"Future log output will go to log destination ""csvlog"".",,,,,,,"","postmaster"
2024-12-06 17:03:49.536 CST,,,211844,,6752bdf3.33b84,2,,2024-12-06 17:03:47 CST,,0,LOG,00000,"starting PostgreSQL 13.2 (RaseSQL 1.3) on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39.0.1), 64-bit",,,,,,,,,"","postmaster"
2024-12-06 17:03:49.537 CST,,,211844,,6752bdf3.33b84,3,,2024-12-06 17:03:47 CST,,0,LOG,00000,"listening on IPv4 address ""0.0.0.0"", port 7284",,,,,,,,,"","postmaster"
2024-12-06 17:03:49.539 CST,,,211844,,6752bdf3.33b84,4,,2024-12-06 17:03:47 CST,,0,LOG,00000,"listening on Unix socket ""/tmp/.s.PGSQL.7284""",,,,,,,,,"","postmaster"
2024-12-06 17:03:49.557 CST,,,211995,,6752bdf5.33c1b,1,,2024-12-06 17:03:49 CST,,0,LOG,00000,"database system was interrupted; last known up at 2024-12-06 17:00:10 CST",,,,,,,,,"","startup"

所以，当时停库后，控制文件记录的数据库状态为in production

Database cluster state: in production

in production这个状态是数据库正在运行，而不是正常的shutdown状态，说明当时数据库停库时不是一致性停库。

继续其中关于fsync的关键代码：

	/*----------
	 * If we previously crashed, perform a couple of actions:
	 *
	 * - The pg_wal directory may still include some temporary WAL segments
	 * used when creating a new segment, so perform some clean up to not
	 * bloat this path. This is done first as there is no point to sync
	 * this temporary data.
	 *
	 * - There might be data which we had written, intending to fsync it, but
	 * which we had not actually fsync'd yet. Therefore, a power failure in
	 * the near future might cause earlier unflushed writes to be lost, even
	 * though more recent data written to disk from here on would be
	 * persisted. To avoid that, fsync the entire data directory.
	 */
	if (ControlFile->state != DB_SHUTDOWNED &&
		ControlFile->state != DB_SHUTDOWNED_IN_RECOVERY)
	{
		RemoveTempXlogFiles();
		SyncDataDirectory();
	}

这里因为控制文件记录的状态不是正常停库的，所以走到if中调用SyncDataDirectory()做fsync持久化。

StartupXLOG做了很多很多事，其中跟spill相关的除了SyncDataDirectory()还有StartupReorderBuffer()：

	/*
	 * Initialize replication slots, before there's a chance to remove
	 * required resources.
	 */
	StartupReplicationSlots();

	/*
	 * Startup logical state, needs to be setup now so we have proper data
	 * during crash recovery.
	 */
	StartupReorderBuffer();

StartupReorderBuffer虽然也会被调用，它会调用ReorderBufferCleanupSerializedTXNs清理所有slot目录的spill文件（不是删除目录和state文件）

/*
 * Delete all data spilled to disk after we've restarted/crashed. It will be
 * recreated when the respective slots are reused.
 */
void
StartupReorderBuffer(void)
{
	DIR		 *logical_dir;
	struct dirent *logical_de;

	logical_dir = AllocateDir("pg_replslot");
	while ((logical_de = ReadDir(logical_dir, "pg_replslot")) != NULL)
	{
		if (strcmp(logical_de->d_name, ".") == 0 ||
			strcmp(logical_de->d_name, "..") == 0)
			continue;

		/* if it cannot be a slot, skip the directory */
		if (!ReplicationSlotValidateName(logical_de->d_name, DEBUG2))
			continue;

		/*
		 * ok, has to be a surviving logical slot, iterate and delete
		 * everything starting with xid-*
		 */
		ReorderBufferCleanupSerializedTXNs(logical_de->d_name);
	}
	FreeDir(logical_dir);
}

5：SyncDataDirectory：

这段函数注释非常重要：

/*
 * Issue fsync recursively on PGDATA and all its contents.
 *
 * We fsync regular files and directories wherever they are, but we
 * follow symlinks only for pg_wal and immediately under pg_tblspc.
 * Other symlinks are presumed to point at files we're not responsible
 * for fsyncing, and might not have privileges to write at all.
 *
 * Errors are logged but not considered fatal; that's because this is used
 * only during database startup, to deal with the possibility that there are
 * issued-but-unsynced writes pending against the data directory. We want to
 * ensure that such writes reach disk before anything that's done in the new
 * run. However, aborting on error would result in failure to start for
 * harmless cases such as read-only files in the data directory, and that's
 * not good either.
 *
 * Note that if we previously crashed due to a PANIC on fsync(), we'll be
 * rewriting all changes again during recovery.
 *
 * Note we assume we're chdir'd into PGDATA to begin with.
 */

fsync所有data目录文件使之持久化
这个动作只会发生在起库阶段
这个动作是为了保证在数据库运行前data目录是完全持久化的

SyncDataDirectory主体是递归遍历目录并fsync（link文件稍微特殊处理一下）：

	walkdir(".", datadir_fsync_fname, false, LOG);
	if (xlog_is_symlink)
		walkdir("pg_wal", datadir_fsync_fname, false, LOG);
	walkdir("pg_tblspc", datadir_fsync_fname, true, LOG);

4：walkdir：递归到.

3：walkdir：递归到./pg_replslot

2：walkdir：递归到./pg_replslot/slotname

1：lstat ：C库调用。walkdir不仅要做fsync（入参函数datadir_fsync_fname），walkdir函数本体还要做 lstat获取文件信息，如inode、文件大小、最近修改时间等等，类似linux的stat命令。

0：_lxstat：C库调用

起库逻辑汇总：

pg会启动一个辅助进程startup以协助起库，不同于在常见的childprocess（walwriter、bgwriter、checkpointer等等）进程，它是起库过程中必定会启动的进程，它会做很多事情
StartupXLOG起库时一定会被调用，无论数据库是否一致性停库
只有非正常停库状态下，才会触发SyncDataDirectory
SyncDataDirectory会fsync持久化所有data文件，并查看所有data文件的stat信息
fsync是为了在库启动前保证data文件都一致；stat应该是为了验证文件是否正常和可读（在startup进程启动前只验证过datadir目录可读性）
无论停库状态，StartupReorderBuffer一定会被调用并清理所有复制槽的spill文件

什么时候是ready状态
#

startup进程把活干完后数据库还不是ready状态，在pmState状态机改变状态时会调用reaper回收进程函数。reaper函数本身是为了子进程退出后进行一些回收或者启动工作。pmState状态机记录状态为PM_STARTUP，状态机是控制启停库状态的。

PostmasterMain的最后几步：

	StartupPID = StartupDataBase();
	Assert(StartupPID != 0);
	StartupStatus = STARTUP_RUNNING;
	pmState = PM_STARTUP; //状态机改变状态

	/* Some workers may be scheduled to start now */
	maybe_start_bgworkers();

	status = ServerLoop();

	/*
	 * ServerLoop probably shouldn't ever return, but if it does, close down.
	 */
	ExitPostmaster(status != STATUS_OK);

	abort();					/* not reached */
}

PostmasterMain起库的核心流程会走到reaper以处理startup进程的正常退出，

PMState注释：

/*
 * We use a simple state machine to control startup, shutdown, and
 * crash recovery (which is rather like shutdown followed by startup).
 *
 * After doing all the postmaster initialization work, we enter PM_STARTUP
 * state and the startup process is launched. The startup process begins by
 * reading the control file and other preliminary initialization steps.
 * In a normal startup, or after crash recovery, the startup process exits
 * with exit code 0 and we switch to PM_RUN state. 

PMState会被信号传递和处理，startup进程退出后reaper会被激活以回收进程。

reaper函数处理startup子进程的正常退出态：

		if (pid == StartupPID)
		{
			StartupPID = 0;
...

			/*
			 * Startup succeeded, commence normal operations
			 */
			StartupStatus = STARTUP_NOT_RUNNING; //由STARTUP_RUNNING转成STARTUP_NOT_RUNNING
			FatalError = false; //上面一堆if未命中后，才不是fatal的
			AbortStartTime = 0;
			ReachedNormalRunning = true;
			pmState = PM_RUN; //状态机由PM_STARTUP转成PM_RUN
			connsAllowed = ALLOW_ALL_CONNS;

			/*
			 * Crank up the background tasks, if we didn't do that already
			 * when we entered consistent recovery state. It doesn't matter
			 * if this fails, we'll just try again later.
			 */
 //以下都在启动核心子进程
			if (CheckpointerPID == 0)
				CheckpointerPID = StartCheckpointer();
			if (BgWriterPID == 0)
				BgWriterPID = StartBackgroundWriter();
			if (WalWriterPID == 0)
				WalWriterPID = StartWalWriter();

			/*
			 * Likewise, start other special children as needed. In a restart
			 * situation, some of them may be alive already.
			 */
 //以下都在启动非核心子进程
			if (!IsBinaryUpgrade && AutoVacuumingActive() && AutoVacPID == 0)
				AutoVacPID = StartAutoVacLauncher();
			if (PgArchStartupAllowed() && PgArchPID == 0)
				PgArchPID = pgarch_start();
			if (PgStatPID == 0)
				PgStatPID = pgstat_start();

			/* workers may be scheduled to start now */
			maybe_start_bgworkers();
		 //此时才是正式的可接受连接状态
			/* at this point we are really open for business */
			ereport(LOG,
					(errmsg("database system is ready to accept connections")));

			/* Report status */
			AddToDataDirLockFile(LOCK_FILE_LINE_PM_STATUS, PM_STATUS_READY);
#ifdef USE_SYSTEMD
			sd_notify(0, "READY=1");
#endif

			continue;
		}

“database system is ready to accept connections”信息就在这里了

checkpointer、bgwrite、walwrite、autovacuum、arch（如有）、stat这些进程都需要启动，在这个阶段拉起这些进程不是必须返回成功的，后续也可以在ServerLoop或者再次执行reaper时尝试启动，只有startup进程是必须一次性必须启动并完成所有相关任务的：

	if (pid < 0)
	{
		/* in parent, fork failed */
		int			save_errno = errno;

		errno = save_errno;
		switch (type)
		{
			case StartupProcess:
				ereport(LOG,
						(errmsg("could not fork startup process: %m")));
				break;
			case BgWriterProcess:
				ereport(LOG,
						(errmsg("could not fork background writer process: %m")));
				break;
			case CheckpointerProcess:
				ereport(LOG,
						(errmsg("could not fork checkpointer process: %m")));
				break;
			case WalWriterProcess:
				ereport(LOG,
						(errmsg("could not fork WAL writer process: %m")));
				break;
			case WalReceiverProcess:
				ereport(LOG,
						(errmsg("could not fork WAL receiver process: %m")));
				break;
			default:
				ereport(LOG,
						(errmsg("could not fork process: %m")));
				break;
		}

		/*
		 * fork failure is fatal during startup, but there's no need to choke
		 * immediately if starting other child types fails.
		 */
		if (type == StartupProcess)
			ExitPostmaster(1);
		return 0;
	}

spill文件生成逻辑各版本差异
#

spill在各个版本都是spill最大的事务，这里重点关注啥时候spill的逻辑

PG12：pg12的changes是4096条写死

static const Size max_changes_in_memory = 4096;

/*
 * Check whether the transaction tx should spill its data to disk.
 */
static void
ReorderBufferCheckSerializeTXN(ReorderBuffer *rb, ReorderBufferTXN *txn)
{
	/*
	 * TODO: improve accounting so we cheaply can take subtransactions into
	 * account here.
	 */
	if (txn->nentries_mem >= max_changes_in_memory)
	{
		ReorderBufferSerializeTXN(rb, txn);
		Assert(txn->nentries_mem == 0);
	}
}

PG13:超过logical_decoding_work_mem内存大小就spill

static void
ReorderBufferCheckMemoryLimit(ReorderBuffer *rb)
{
...
	while (rb->size >= logical_decoding_work_mem * 1024L)
	{
		/*
		 * Pick the largest transaction (or subtransaction) and evict it from
		 * memory by serializing it to disk.
		 */
		txn = ReorderBufferLargestTXN(rb);

		ReorderBufferSerializeTXN(rb, txn);
...
}

PG14：多个了一个流式传输ReorderBufferStreamTXN

static void
ReorderBufferCheckMemoryLimit(ReorderBuffer *rb)
{
...
	while (rb->size >= logical_decoding_work_mem * 1024L)
	{
		/*
		 * Pick the largest transaction (or subtransaction) and evict it from
		 * memory by streaming, if possible. Otherwise, spill to disk.
		 */
		if (ReorderBufferCanStartStreaming(rb) &&
			(txn = ReorderBufferLargestTopTXN(rb)) != NULL)
		{...
			ReorderBufferStreamTXN(rb, txn);
		}
		else
		{...
			ReorderBufferSerializeTXN(rb, txn);
		}
...
}

14虽然有了流式复制，但是触发是要一定条件的：

/* Returns true, if the streaming can be started now, false, otherwise. */
static inline bool
ReorderBufferCanStartStreaming(ReorderBuffer *rb)
{
	LogicalDecodingContext *ctx = rb->private_data;
	SnapBuild *builder = ctx->snapshot_builder;

	/* We can't start streaming unless a consistent state is reached. */
	if (SnapBuildCurrentState(builder) < SNAPBUILD_CONSISTENT)
		return false;

	/*
	 * We can't start streaming immediately even if the streaming is enabled
	 * because we previously decoded this transaction and now just are
	 * restarting.
	 */
	if (ReorderBufferCanStream(rb) &&
		!SnapBuildXactNeedsSkip(builder, ctx->reader->EndRecPtr))
		return true;

	return false;
}

	/*
	 * Found a point after SNAPBUILD_FULL_SNAPSHOT where all transactions that
	 * were running at that point finished. Till we reach that we hold off
	 * calling any commit callbacks.
	 */
	SNAPBUILD_CONSISTENT = 2

额外的steam触发条件：

条件1：快照中的事务涵盖的所有事务都已完成（应该指commit or rollback）
条件2：context是私有数据（是不是说两条链路一张表就不会触发steam？）
条件3：快照中的事务是不可忽略的事务（可能指特殊的事务可以忽略，就不做了）

PG15：跟14差不多，只是函数更清晰，套娃少一些了

PG16：差不多

PG17：差不多，新增一个DEBUG_LOGICAL_REP_STREAMING_IMMEDIATE可以强制stream

记忆点：

PG12及以前是写死的4096条changes
PG13新增logical_decoding_work_mem参数，可调整内存大小以减少spill概率
PG14及以后支持流式复制Streaming
触发流式复制也需要一定的条件，所以即使有流式复制也可能会发生spill
PG17新增debug_logical_replication_streaming参数以强制触发流式传输

spill文件清理逻辑
#

起库时清理spill其实只是一种场景，还有启动walsender清理和drop slot清理。

walsender启动时清理
#

ReorderBufferCleanupSerializedTXNs会在数据库启动（walsender还没有启动）、walsender启动（数据库运行中）时被调用，注意这两部分场景是不一样的，只是他们会调用同一个函数。从函数注释部分也可以看出，该函数是为了“删除残留的序列化的reorder buffers”，即清理spill文件。

/*
 * Remove any leftover serialized reorder buffers from a slot directory after a
 * prior crash or decoding session exit.
 */
static void
ReorderBufferCleanupSerializedTXNs(const char *slotname)
{
	DIR		 *spill_dir;
	struct dirent *spill_de;
	struct stat statbuf;
	char		path[MAXPGPATH * 2 + 12];

	sprintf(path, "pg_replslot/%s", slotname);

	/* we're only handling directories here, skip if it's not ours */
	if (lstat(path, &statbuf) == 0 && !S_ISDIR(statbuf.st_mode))
		return;

	spill_dir = AllocateDir(path);
	while ((spill_de = ReadDirExtended(spill_dir, path, INFO)) != NULL)
	{
		/* only look at names that can be ours */
 //只对比前3个字符
		if (strncmp(spill_de->d_name, "xid", 3) == 0)
		{
			snprintf(path, sizeof(path),
					 "pg_replslot/%s/%s", slotname,
					 spill_de->d_name);

			if (unlink(path) != 0)
				ereport(ERROR,
						(errcode_for_file_access(),mkdir 
						 errmsg("could not remove file \"%s\" during removal of pg_replslot/%s/xid*: %m",
								path, slotname)));
		}
	}
	FreeDir(spill_dir);
}

以上清理逻辑需要注意两点：

清理文件名以“xid”开头的文件。很明显state文件是不能清理的
unlink清理，一次清理一个文件。考虑这一点可以帮助我们构建加速起库方案

数据库启动时清理
#

数据库启动时会fork一个startup进程来清理slot，清理函数跟walsender调用的清理函数一致：ReorderBufferCleanupSerializedTXNs。

还有一个区别在于，walsender重启后，只会清理当前同名slot spill；而数据库启动时会顺序清理所有slot spill。

数据库启动startup进程，while顺序清理逻辑：

void
StartupReorderBuffer(void)
{
	DIR		 *logical_dir;
	struct dirent *logical_de;

	logical_dir = AllocateDir("pg_replslot");
	while ((logical_de = ReadDir(logical_dir, "pg_replslot")) != NULL)
	{	//排除.和..
		if (strcmp(logical_de->d_name, ".") == 0 ||
			strcmp(logical_de->d_name, "..") == 0)
			continue;
		//验证slotname是否规范
		/* if it cannot be a slot, skip the directory */
		if (!ReplicationSlotValidateName(logical_de->d_name, DEBUG2))
			continue;

		/*
		 * ok, has to be a surviving logical slot, iterate and delete
		 * everything starting with xid-*
		 */
		ReorderBufferCleanupSerializedTXNs(logical_de->d_name);
	}
	FreeDir(logical_dir);
}

while循环调用ReorderBufferCleanupSerializedTXNs，后面跟walsender启动清理逻辑就一样了。

pg_drop_replication_slot手动清理
#

drop slot清理逻辑跟自动清理spill文件的逻辑不一样，它没有调用到ReorderBufferCleanupSerializedTXNs。

drop slot流程如下：

pg_drop_replication_slot(PG_FUNCTION_ARGS)->ReplicationSlotDrop(const char *name, bool nowait)->ReplicationSlotDropAcquired(void)->ReplicationSlotDropPtr

ReplicationSlotDropPtr清理复制槽的逻辑也很有意思:

/*
 * Permanently drop the replication slot which will be released by the point
 * this function returns.
 */
static void
ReplicationSlotDropPtr(ReplicationSlot *slot)
{
	char		path[MAXPGPATH];
	char		tmppath[MAXPGPATH];

	/*
	 * If some other backend ran this code concurrently with us, we might try
	 * to delete a slot with a certain name while someone else was trying to
	 * create a slot with the same name.
	 */
	LWLockAcquire(ReplicationSlotAllocationLock, LW_EXCLUSIVE);

	/* Generate pathnames. */
	sprintf(path, "pg_replslot/%s", NameStr(slot->data.name));
	sprintf(tmppath, "pg_replslot/%s.tmp", NameStr(slot->data.name));

	/*
	 * Rename the slot directory on disk, so that we'll no longer recognize
	 * this as a valid slot. Note that if this fails, we've got to mark the
	 * slot inactive before bailing out. If we're dropping an ephemeral or a
	 * temporary slot, we better never fail hard as the caller won't expect
	 * the slot to survive and this might get called during error handling.
	 */
	if (rename(path, tmppath) == 0) //rename文件
	{
		/*
		 * We need to fsync() the directory we just renamed and its parent to
		 * make sure that our changes are on disk in a crash-safe fashion. If
		 * fsync() fails, we can't be sure whether the changes are on disk or
		 * not. For now, we handle that by panicking;
		 * StartupReplicationSlots() will try to straighten it out after
		 * restart.
		 */
 //fsync持久化
		START_CRIT_SECTION();
		fsync_fname(tmppath, true);
		fsync_fname("pg_replslot", true);
		END_CRIT_SECTION();
	}
...

	/*
	 * If removing the directory fails, the worst thing that will happen is
	 * that the user won't be able to create a new slot with the same name
	 * until the next server restart. We warn about it, but that's all.
	 */
 
	if (!rmtree(tmppath, true))
		ereport(WARNING,
				(errmsg("could not remove directory \"%s\"", tmppath)));
	/*
	 * We release this at the very end, so that nobody starts trying to create
	 * a slot while we're still cleaning up the detritus of the old one.
	 */
	LWLockRelease(ReplicationSlotAllocationLock);
}

drop slot不是直接去复制槽目录下面去unlink，而是先把复制槽目录slotname/rename成 slotname.tmp/，然后再去做unlink目录下的文件，最后再删除 slotname.tmp/目录本身。

其中rmtree也是在循环unlink文件。

复制槽溢出发生后加速起库方案测试
#

1000w个spill删除起来肯定是很慢的，直接mv目录的话就非常快。但是直接mv需要注意mv后的名称和state文件，以及需要知道mv到底跳过了哪一个源码步骤。

mv的名称注意事项
#

由于是异常停库，startup进程会执行SyncDataDirectoryfsync和stat所有data文件，这一点是比较难绕过的。SyncDataDirectory做完以后，才开始处理复制槽。处理复制槽时会调用StartupReorderBuffer()->ReorderBufferCleanupSerializedTXNs全量清理spill文件。

在进入清理前，会调用ReplicationSlotValidateName校验复制槽名称的有效性，我们可以在ReplicationSlotValidateName上做文章，以骗过startup进程跳过ReorderBufferCleanupSerializedTXNs的过程。

ReplicationSlotValidateName规则：

bool
ReplicationSlotValidateName(const char *name, int elevel)
{
...

	for (cp = name; *cp; cp++)
	{ //关键规则在这里
		if (!((*cp >= 'a' && *cp <= 'z')
			 || (*cp >= '0' && *cp <= '9')
			 || (*cp == '_')))
		{
			ereport(elevel,
					(errcode(ERRCODE_INVALID_NAME),
					 errmsg("replication slot name \"%s\" contains invalid character",
							name),
					 errhint("Replication slot names may only contain lower case letters, numbers, and the underscore character.")));
			return false;
		}
	}
	return true;
}

有效slot name只包含a-z;0-9;_。

所以rename时建议加个点.，

建议slotname.bak,slotname.20241215等。
不建议slotnamebackup,slotname20241215,slotname_bak等等
不建议.tmp后缀，slotname有.tmp后缀有特殊含义

最后rename后，要创建目录和拷贝state，不然启动的slot会表现的很反常（比如重复的slotname、自动生产一个slotname、删不到slot、下游起不来链路等等）。

汇总推荐mv操作如下：

cd pg_replslot
mv slotname slotname.bak 
mkdir slotname
cp slotname.bak/state slotname/

起库时间对比
#

对比不同源码流程起库速度，看看手工mv/rm加速起库到底有没有意义。

参考源码逻辑原理：

正常停库，走fsync和stat
异常停库，走fsync和stat；
有效mv，将slotname目录命名为.bak，不走unlink
无效mv，将slotname目录命名为_bak且spill文件命名为xid开头，走unlink

由于正常spill文件实在太慢，这里手工伪造slot目录和spill文件，总共50个slot，每个slot 40w个spill，总共2000w个spill来测试起库时间（用cp目录的方式要比cp文件、dd文件快很多）。

编号	测试方案	起库时间
1	正常停库；起库不做fsync和stat，不做unlink	0.1秒
2	正常停库，无效mv；起库不做fsync和stat，做unlink	11分41秒
3	异常停库，有效mv；起库做fsync和stat，不做unlink	4分35秒
4	异常停库，无效mv；起库做fsync和stat，做unlink	32分2秒
5	异常停库，rm（创建slot目录并保留state）	13分04秒

对比方案3、5，理论上当时的场景我们有效mv可以做到4分钟左右起库，rm的话13分钟左右。（这是一个粗糙的对比，恢复环境已经观察到有些东西不一样了）

PG停库逻辑和walsender阻止停库问题分析

Sat, 04 Jan 2025 00:00:00 +0000

walsender阻止停库现象
#

生产停库日志输出如下：

2024-12-06 17:00:02.036 CST,,,447560,,65693cde.6d448,1320,,2023-12-01 09:54:38 CST,,0,LOG,00000,"received fast shutdown request",,,,,,,,,"","postmaster"
2024-12-06 17:00:02.295 CST,,,447560,,65693cde.6d448,1322,,2023-12-01 09:54:38 CST,,0,LOG,00000,"background worker ""logical replication launcher"" (PID 448996) exited with exit code 1",,,,,,,,,"","postmaster"
2024-12-06 17:00:10.627 CST,,,448990,,65693ce0.6d9de,213833,,2023-12-01 09:54:40 CST,,0,LOG,00000,"checkpoint complete: wrote 426844 buffers (5.1%); 0 WAL file(s) added, 0 removed, 5 recycled; write=91.427 s, sync=0.055 s, total=91.508 s; sync files=761, longest=0.028 s, average=0.001 s; distance=2197531 kB, estimate=2680783 kB",,,,,,,,,"","checkpointer"
2024-12-06 17:00:10.628 CST,,,448990,,65693ce0.6d9de,213834,,2023-12-01 09:54:40 CST,,0,LOG,00000,"shutting down",,,,,,,,,"","checkpointer"
...
--checkpointer做完checkpoint，并处于shutting down状态，pm没有退出

--160s后pm接收到immediate shutdown，由探活脚本触发
2024-12-06 17:02:43.348 CST,,,447560,,65693cde.6d448,1323,,2023-12-01 09:54:38 CST,,0,LOG,00000,"received immediate shutdown request",,,,,,,,,"","postmaster"
2024-12-06 17:02:43.370 CST,"logicaluser","lzldb",283840,"10.33.77.159:39865",6751a2dc.454c0,7,"idle",2024-12-05 20:55:56 CST,89/847309655,0,WARNING,57P02,"terminating connection because of crash of another server process","The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.","In a moment you should be able to reconnect to the database and repeat your command.",,,,,,,"Debezium Streaming","walsender"
2024-12-06 17:02:43.370 CST,"logicaluser","lzldb",157641,"10.33.77.159:39407",67408354.267c9,7,"idle",2024-11-22 21:12:52 CST,9/3193590104,0,WARNING,57P02,"terminating connection because of crash of another server process","The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.","In a moment you should be able to reconnect to the database and repeat your command.",,,,,,,"Debezium Streaming","walsender"
2024-12-06 17:02:43.370 CST,"logicaluser","lzldb",157916,"10.33.77.159:57038",67408356.268dc,7,"idle",2024-11-22 21:12:54 CST,115/3293293502,0,WARNING,57P02,"terminating connection because of crash of another server process","The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.","In a moment you should be able to reconnect to the database and repeat your command.",,,,,,,"Debezium Streaming","walsender"
2024-12-06 17:02:43.370 CST,"repuser","",164392,"30.151.40.19:41641",66b25869.28228,3,"streaming 42D3B/1732C5F0",2024-08-07 01:07:53 CST,296/0,0,WARNING,57P02,"terminating connection because of crash of another server process","The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.","In a moment you should be able to reconnect to the database and repeat your command.",,,,,,,"standby_6666","walsender"
2024-12-06 17:02:43.371 CST,,,447560,,65693cde.6d448,1324,,2023-12-01 09:54:38 CST,,0,LOG,00000,"archiver process (PID 448994) exited with exit code 2",,,,,,,,,"","postmaster"
2024-12-06 17:02:43.371 CST,"logicaluser","lzldb",57755,"10.33.77.159:38918",67125534.e19b,7,"idle",2024-10-18 20:31:48 CST,243/902018192,0,WARNING,57P02,"terminating connection because of crash of another server process","The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.","In a moment you should be able to reconnect to the database and repeat your command.",,,,,,,"Debezium Streaming","walsender"
2024-12-06 17:02:43.372 CST,"logicaluser","lzldb",157915,"10.33.77.159:43433",67408356.268db,7,"idle",2024-11-22 21:12:54 CST,60/3248014863,0,WARNING,57P02,"terminating connection because of crash of another server process","The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.","In a moment you should be able to reconnect to the database and repeat your command.",,,,,,,"Debezium Streaming","walsender"


--pm停完
2024-12-06 17:02:57.534 CST,,,447560,,65693cde.6d448,1325,,2023-12-01 09:54:38 CST,,0,LOG,00000,"database system is shut down",,,,,,,,,"","postmaster"
2024-12-06 17:03:49.536 CST,,,211844,,6752bdf3.33b84,1,,2024-12-06 17:03:47 CST,,0,LOG,00000,"ending log output to stderr",,"Future log output will go to log destination ""csvlog"".",,,,,,,"","postmaster"

17:00:02 postmaster接到fast停库

17:00:10 checkpoint做完，checkpointer停了

17:02:43 postmaster接到immediate停库

17:02:43 1个物理链路和5个逻辑链路walsender停了

17:02:57 postmaster停了

17:03:49 postmaster接到启动任务

从以上信息可以看出，实际上还是walsender阻止了停库

停库和信号
#

在撸源码前需要先了解信号和pg中的信号注册

pg中的常用信号
#

操作系统信号：

$ kill -l
 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP
 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1
11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM
16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP
...

PG常用的信号：

-1 或-SIGHUP：挂起信号，在PG中通常是通知进程重新加载配置。
-2 或-SIGINT：中断信号（通常是Ctrl+C），在pg中同城对应取消命令。
-3或-SIGQUIT：pg中通常是强制退出die
-9 或 -SIGKILL：无条件终止信号。
-15或 -SIGTERM：终止信号，pg_terminate_backend使用的信号，pg中通常是合理退出
-10或-SIGUSR1：自定义信号
-12或-SIGUSR2：自定义信号
-17或SIGCHLD：pm进程使用的信号，一般是子进程退出后pm接受该信号触发回收子进程任务

PG中具体哪种类型的进程注册的信号含义，看各自进程源码基本都能找到。

pg_ctl 定义的停库
#

有几种方法可以关闭pg库。在底层，它们都归结为向postmaster进程发送一个信号。

signal	pg_ctl	含义
`SIGTERM`	Smart Shutdown	不允许新的连接，但允许现有会话正常结束其工作。只有在所有会话终止后，它才会关闭
`SIGINT`	Fast Shutdown	服务器不允许新的连接，并向所有现有的子进程发送SIGTERM，中止当前的事务并迅速退出。等待几乎所有子进程（有几个子进程不需要）退出，最后关闭
`SIGQUIT`	Immediate Shutdown	将向所有子进程发送SIGQUIT，并等待它们终止。如果在5秒内有子进程没有终止，它们将被发送SIGKILL

注意，pg_ctl没有发送SIGKILL（kill -9）的参数，但其实是可以直接对pm发送SIGKILL的，但肯定不推荐这么做，SIGKILL pm时pm不会对子进程、共享内存、信号量做任何处理。因为SIGQUIT pm有兜底逻辑做子进程的SIGKILL，所以SIGQUIT pm基本能保证pm能停下来。

在源码中，停库状态总共只有3种，跟停库方式相对应：

/* Startup/shutdown state */
#define			NoShutdown		0
#define			SmartShutdown	1
#define			FastShutdown	2
#define			ImmediateShutdown	3

这些状态会在停库routine源码中常见，一般通过变量Shutdown来判断当前停库状态，如：

Shutdown >= FastShutdown

pm信号
#

当pm收到对应信号时做相应的处理：

void
PostmasterMain(int argc, char *argv[])
{...
	pqsignal_pm(SIGHUP, SIGHUP_handler);	/* reread config file and have
											 * children do same */
	pqsignal_pm(SIGINT, pmdie); /* send SIGTERM and shut down */
	pqsignal_pm(SIGQUIT, pmdie);	/* send SIGQUIT and die */
	pqsignal_pm(SIGTERM, pmdie);	/* wait for children and shut down */
	pqsignal_pm(SIGALRM, SIG_IGN);	/* ignored */
	pqsignal_pm(SIGPIPE, SIG_IGN);	/* ignored */
	pqsignal_pm(SIGUSR1, sigusr1_handler);	/* message from child process */
	pqsignal_pm(SIGUSR2, dummy_handler);	/* unused, reserve for children */
	pqsignal_pm(SIGCHLD, reaper);	/* handle child termination */

pmdie：停库的三种信号会调用pmdie函数，pmdie是停库的关键函数，下面会重点分析。
reaper：停库时会处理子进程退出清理，所以在停库的逻辑中。子进程退出会给pm发生SIGCHLD信号，然后进入reaper清理子进程，每种子进程的清理也有自己的逻辑，比如checkpointer进程的正常退出会判断archiver和walsender是否完成了各自的任务。
sigusr1、sigusr2：sigusr1_handler是SIGUSER1的标准routine，每种子进程对于SIGUSR1的处理行为各不同；SIGUSR2完全是子进程自定义行为了，有些子进程没有注册这个信号。

walsender的信号
#

子进程fork出来时，首先就要注册信号。

WalSndSignals注册walsender进程的信号：

/* Set up signal handlers */
void
WalSndSignals(void)
{
	/* Set up signal handlers */
	pqsignal(SIGHUP, SignalHandlerForConfigReload);
	pqsignal(SIGINT, StatementCancelHandler);	/* query cancel */
	pqsignal(SIGTERM, die);		/* request shutdown */
	pqsignal(SIGQUIT, quickdie);	/* hard crash time */
	InitializeTimeouts();		/* establishes SIGALRM handler */
	pqsignal(SIGPIPE, SIG_IGN);
	pqsignal(SIGUSR1, procsignal_sigusr1_handler);
	pqsignal(SIGUSR2, WalSndLastCycleHandler);	/* request a last cycle and
												 * shutdown */
}

要注意SIGUSR1和SIGUSR2

checkpointer的信号
#

CheckpointerMain注册checkpointer的信号：

void
CheckpointerMain(void)
{
...
 //checkpointer会屏蔽SIGTERM，真正的停止是SIGUSR2
	pqsignal(SIGHUP, SignalHandlerForConfigReload);
	pqsignal(SIGINT, ReqCheckpointHandler); /* request checkpoint */
	pqsignal(SIGTERM, SIG_IGN); /* ignore SIGTERM */
	pqsignal(SIGQUIT, SignalHandlerForCrashExit);
	pqsignal(SIGALRM, SIG_IGN);
	pqsignal(SIGPIPE, SIG_IGN);
	pqsignal(SIGUSR1, procsignal_sigusr1_handler);
	pqsignal(SIGUSR2, SignalHandlerForShutdownRequest);

要注意SIGUSR1和SIGUSR2，同时要注意checkpointer是没有注册SIGTERM的

停库源码分析
#

pm信号处理和状态机
#

pmdie函数用于处理不同的postmaster signals，包括子进程给pm发送的SIGCHILD和pg_ctl发送的停库信号。pm信号处理主体逻辑是根据signal转换pmState状态机状态，并进入状态机PostmasterStateMachine处理。

pmdie：

/*
 * pmdie -- signal handler for processing various postmaster signals.
 */
static void
pmdie(SIGNAL_ARGS)
{
	int			save_errno = errno;

...

	switch (postgres_signal_arg)
	{
		case SIGTERM://Smart Shutdown
			...
			if (pmState == PM_RUN)
				connsAllowed = ALLOW_SUPERUSER_CONNS;
			...
 //smart shutdown没有处理pmstate，直接交给状态机处理
			//此时正常情况pmState = PM_RUN
			PostmasterStateMachine();
			break;

		case SIGINT://Fast Shutdown
			...
			else if (pmState == PM_RUN ||
					 pmState == PM_HOT_STANDBY)
			{
				/* Report that we're about to zap live client sessions */
				ereport(LOG,
						(errmsg("aborting any active transactions")));
				pmState = PM_STOP_BACKENDS;
			}

			//Fast Shutdown将pmstate转换为PM_STOP_BACKENDS
 //然后交给状态机处理
			PostmasterStateMachine();
			break;

		case SIGQUIT://Immediate Shutdown
			...

			TerminateChildren(SIGQUIT);//abort all children with SIGQUIT, wait for them to exit
			pmState = PM_WAIT_BACKENDS;

			/* set stopwatch for them to die */
			AbortStartTime = time(NULL);

 //Immediate Shutdown将pmstate转换为PM_WAIT_BACKENDS
 //进入状态机前处理也会children
 //先用SIGQUIT中断children，等待他们退出
 //然后用SIGKILL处理还在的children
 //最后非一致性退出
			PostmasterStateMachine();
			break;
	}
...
}

在进入状态机处理函数前先看下postmaster的状态有哪些：

typedef enum
{
	PM_INIT,					/* postmaster starting */
	PM_STARTUP,					/* waiting for startup subprocess */
	PM_RECOVERY,				/* in archive recovery mode */
	PM_HOT_STANDBY,				/* in hot standby mode */
	PM_RUN,						/* normal "database is alive" state */
	PM_STOP_BACKENDS,			/* need to stop remaining backends */
	PM_WAIT_BACKENDS,			/* waiting for live backends to exit */
	PM_SHUTDOWN,				/* waiting for checkpointer to do shutdown
								 * ckpt */
	PM_SHUTDOWN_2,				/* waiting for archiver and walsenders to
								 * finish */
	PM_WAIT_DEAD_END,			/* waiting for dead_end children to exit */
	PM_NO_CHILDREN				/* all important children have exited */
} PMState;

由于正常都是running态关库，这里只需要关注PM_RUN以下的状态即可。

PostmasterStateMachine的执行函数实际上有顺序逻辑：

/*
 * Advance the postmaster's state machine and take actions as appropriate
 *
 * This is common code for pmdie(), reaper() and sigusr1_handler(), which
 * receive the signals that might mean we need to change state.
 */
static void
PostmasterStateMachine(void)
{
	//smart shutdown，此时的pmState应是PM_RUN
	if (pmState == PM_RUN || pmState == PM_HOT_STANDBY)
	{
	...

		if (connsAllowed == ALLOW_NO_CONNS)
		{
 //当所有normal backend都退出后，pmState转换PM_STOP_BACKENDS
			if (CountChildren(BACKEND_TYPE_NORMAL) == 0)
				pmState = PM_STOP_BACKENDS;
		}
	}

 //PM_STOP_BACKENDS会中止一些比较核心的子进程，有些子进程会继续运行
 //autovacuum，bgwriter，walwriter，startup，walreiver会停止
 //walsender，checkpointer, archiver, stats, and syslogger会继续跑
 //smart shutdown后段会进入此逻辑，fast shutdown直接进入此逻辑
	if (pmState == PM_STOP_BACKENDS)
	{
		...		
		//注意walsender这句话！
		/* Signal all backend children except walsenders */
		SignalSomeChildren(SIGTERM,
						 BACKEND_TYPE_ALL - BACKEND_TYPE_WALSND);
		/* and the autovac launcher too */
		if (AutoVacPID != 0)
			signal_child(AutoVacPID, SIGTERM);
		/* and the bgwriter too */
		if (BgWriterPID != 0)
			signal_child(BgWriterPID, SIGTERM);
		/* and the walwriter too */
		if (WalWriterPID != 0)
			signal_child(WalWriterPID, SIGTERM);
		/* If we're in recovery, also stop startup and walreceiver procs */
		if (StartupPID != 0)
			signal_child(StartupPID, SIGTERM);
		if (WalReceiverPID != 0)
			signal_child(WalReceiverPID, SIGTERM);
		/* checkpointer, archiver, stats, and syslogger may continue for now */

 //将pmState从PM_STOP_BACKENDS转换为PM_WAIT_BACKEND
 //PM_WAIT_BACKEND表示等待backend退出
		pmState = PM_WAIT_BACKENDS;
	}

	/*
	 * If we are in a state-machine state that implies waiting for backends to
	 * exit, see if they're all gone, and change state if so.
	 */
 //
 //smart shutdown,fast shutdown后段会进入此逻辑
 //immediate shutdown进入状态机处理时，直接进入此逻辑
	if (pmState == PM_WAIT_BACKENDS)
	{
 //crash recovery和immediate shutdown时，checkpointer需要妥善退出
 //archiver, stats, and syslogger不需要处理，因为他们没有连到shared memory
 //Walsenders也不需要处理，它将在checkpoint记录写入之后退出，就像archiver进程一样
		if (CountChildren(BACKEND_TYPE_ALL - BACKEND_TYPE_WALSND) == 0 &&
			StartupPID == 0 &&
			WalReceiverPID == 0 &&
			BgWriterPID == 0 &&
			(CheckpointerPID == 0 ||
			 (!FatalError && Shutdown < ImmediateShutdown)) &&
			WalWriterPID == 0 &&
			AutoVacPID == 0)
		{
			if (Shutdown >= ImmediateShutdown || FatalError)
			{
				//ImmediateShutdown会等待dead end进程结束
				pmState = PM_WAIT_DEAD_END;

				/*
				 * We already SIGQUIT'd the archiver and stats processes, if
				 * any, when we started immediate shutdown or entered
				 * FatalError state.
				 */
			}
			else
			{
 //smart，fast shutdown走此逻辑
 //常规子进程都退出了，此时该通知checkpointer做shutdown checkpoint
				Assert(Shutdown > NoShutdown);
				//如果checkpointer进程没有，就启动
				if (CheckpointerPID == 0)
					CheckpointerPID = StartCheckpointer();
				/* And tell it to shut down */
				if (CheckpointerPID != 0)
				{
 //向Checkpointer发送SIGUSR2
 //pmState = PM_SHUTDOWN
					signal_child(CheckpointerPID, SIGUSR2);
					pmState = PM_SHUTDOWN;
				}
				else
				{
 //没有启动起来Checkpointer是一个比较严重的问题
					FatalError = true;
					pmState = PM_WAIT_DEAD_END;

					/* Kill the walsenders, archiver and stats collector too */ 
 //注释说kill walsender，实际上根本没有；至少不是SIGQUIT去停的
					SignalChildren(SIGQUIT);
					if (PgArchPID != 0)
						signal_child(PgArchPID, SIGQUIT);
					if (PgStatPID != 0)
						signal_child(PgStatPID, SIGQUIT);
				}
			}
		}
	}
	
 //pmdie函数和状态机函数不会制造PM_SHUTDOWN_2这个状态，但是reaper会
 //reaper在处理checkpointer的退出时，会设置pmState = PM_SHUTDOWN_2；当然在reaper函数最后会进入状态机函数，也就是这里
	if (pmState == PM_SHUTDOWN_2)
	{
		/*
		 * PM_SHUTDOWN_2 state ends when there's no other children than
		 * dead_end children left. There shouldn't be any regular backends
		 * left by now anyway; what we're really waiting for is walsenders and
		 * archiver.
		 */
 //PM_SHUTDOWN_2本质上是等待walsender和archiver
 //只是更改了pmState状态
		if (PgArchPID == 0 && CountChildren(BACKEND_TYPE_ALL) == 0)
		{
			pmState = PM_WAIT_DEAD_END;
		}
	}

	if (pmState == PM_WAIT_DEAD_END)
	{
 //PM_WAIT_DEAD_END表示BackendList已经完全清空
		if (dlist_is_empty(&BackendList) &&
			PgArchPID == 0 && PgStatPID == 0)
		{
			/* These other guys should be dead already */
			Assert(StartupPID == 0);
			Assert(WalReceiverPID == 0);
			Assert(BgWriterPID == 0);
			Assert(CheckpointerPID == 0);
			Assert(WalWriterPID == 0);
			Assert(AutoVacPID == 0);
			/* syslogger is not considered here */
			pmState = PM_NO_CHILDREN;
		}
	}

 //PM_NO_CHILDREN是停库的最后一个状态，表示可以正常停库了
	if (Shutdown > NoShutdown && pmState == PM_NO_CHILDREN)
	{
		if (FatalError)
		{
			ereport(LOG, (errmsg("abnormal database system shutdown")));
 //异常退出pm
			ExitPostmaster(1);
		}
		...

		 	//正常退出pm
			ExitPostmaster(0);
		}
	}
	...
}

reaper是进程回收函数，子进程退出后会发送pm SIGCHLD信号，pm通过reaper函数清理进程。如backend、startup、checkpointer等进程都有自己的清理流程。

这里只看checkpointer的清理，另外reaper中没有关于walsender的清理逻辑：

		if (pid == CheckpointerPID)
		{
			CheckpointerPID = 0;
 //Checkpointer进程是正常退出，且pmState为PM_SHUTDOWN:等待checkpoint完成态
			if (EXIT_STATUS_0(exitstatus) && pmState == PM_SHUTDOWN)
			{
				/*
				 * OK, we saw normal exit of the checkpointer after it's been
				 * told to shut down. We expect that it wrote a shutdown
				 * checkpoint. (If for some reason it didn't, recovery will
				 * occur on next postmaster start.)
				 *
				 * At this point we should have no normal backend children
				 * left (else we'd not be in PM_SHUTDOWN state) but we might
				 * have dead_end children to wait for.
				 *
				 * If we have an archiver subprocess, tell it to do a last
				 * archive cycle and quit. Likewise, if we have walsender
				 * processes, tell them to send any remaining WAL and quit.
				 */
				Assert(Shutdown > NoShutdown);

				//最后一次唤醒pgarch
				if (PgArchPID != 0)
					signal_child(PgArchPID, SIGUSR2); //pgarch SIGUSR2=pgarch_waken_stop

 //最后一次唤醒walsender
				SignalChildren(SIGUSR2);//walsender SIGUSR2=WalSndLastCycleHandler
 
 //这里设置了PM_SHUTDOWN_2
 //此时Checkpointer正常退出完成了，这里应该等pgarch和walsender最后一个任务完成
 //即PM_SHUTDOWN_2态
 pmState = PM_SHUTDOWN_2;

				...
			}
			else
			{
 //checkpointer进程异常退出都认为是crash
				HandleChildCrash(pid, exitstatus,
								 _("checkpointer process"));
			}

			continue;
		}
...
	//最后reaper还是会进入状态机函数
	PostmasterStateMachine();

...
}

checkpointer和walsender进程的退出
#

checkpointer主循环处理请求和关闭进程：

void
CheckpointerMain(void)
{
	/*
	 * Loop forever
	 */
	for (;;)
	{
		bool		do_checkpoint = false;
		int			flags = 0;
		pg_time_t	now;
		int			elapsed_secs;
		int			cur_timeout;

		/* Clear any already-pending wakeups */
		ResetLatch(MyLatch);

		/*
		 * Process any requests or signals received recently.
		 */
 //处理近期的同步请求和信号
		AbsorbSyncRequests();
		HandleCheckpointerInterrupts();

checkpointer关闭函数：

/*
 * Process any new interrupts.
 */
static void
HandleCheckpointerInterrupts(void)
{
 ...
	if (ShutdownRequestPending)
	{
		/*
		 * From here on, elog(ERROR) should end with exit(1), not send control
		 * back to the sigsetjmp block above
		 */
		ExitOnAnyError = true;
		
		ShutdownXLOG(0, 0);//这里会写shutdown checkpoint 
		
		proc_exit(0);//正常退出态为0
	}
}

checkpointer的退出需要等待ShutdownXLOG完成。

ShutdownXLOG：

/*
 * This must be called ONCE during postmaster or standalone-backend shutdown
 */
void
ShutdownXLOG(int code, Datum arg)
{
...

	//这里有个checkpointer的shutting down的日志，这个日志一般都会看到
	ereport(IsPostmasterEnvironment ? LOG : NOTICE,
			(errmsg("shutting down")));

	/*
	 * Signal walsenders to move to stopping state.
	 */
 //walsender初始化stopping
	WalSndInitStopping();

 //等待所有walsender处于stopping状态
	WalSndWaitStopping();

	if (RecoveryInProgress())
		CreateRestartPoint(CHECKPOINT_IS_SHUTDOWN | CHECKPOINT_IMMEDIATE);
	else
	{
		/*
		 * If archiving is enabled, rotate the last XLOG file so that all the
		 * remaining records are archived (postmaster wakes up the archiver
		 * process one more time at the end of shutdown). The checkpoint
		 * record will go to the next XLOG file and won't be archived (yet).
		 */
		if (XLogArchivingActive() && XLogArchiveCommandSet())
			RequestXLogSwitch(false);
		//这里就是shutdown checkpoint的创建函数
		CreateCheckPoint(CHECKPOINT_IS_SHUTDOWN | CHECKPOINT_IMMEDIATE);
	}
	ShutdownCLOG();
	ShutdownCommitTs();
	ShutdownSUBTRANS();
	ShutdownMultiXact();
}

checkpointer通知所有walsender开始stopping：

/*
 * Signal all walsenders to move to stopping state.
 *
 * This will trigger walsenders to move to a state where no further WAL can be
 * generated. See this file's header for details.
 */
void
WalSndInitStopping(void)
{
	int			i;

	for (i = 0; i < max_wal_senders; i++)
	{
		WalSnd	 *walsnd = &WalSndCtl->walsnds[i];
		pid_t		pid;

		SpinLockAcquire(&walsnd->mutex);
		pid = walsnd->pid;
		SpinLockRelease(&walsnd->mutex);

		if (pid == 0)
			continue;

		SendProcSignal(pid, PROCSIG_WALSND_INIT_STOPPING, InvalidBackendId);
	}
}

walsender通过SendProcSignal函数收到信号，信号为SIGUSR1

/*
 * SendProcSignal
 *		Send a signal to a Postgres process
 *
 * Providing backendId is optional, but it will speed up the operation.
 *
 * On success (a signal was sent), zero is returned.
 * On error, -1 is returned, and errno is set (typically to ESRCH or EPERM).
 *
 * Not to be confused with ProcSendSignal
 */
int
SendProcSignal(pid_t pid, ProcSignalReason reason, BackendId backendId)
{
	else
	{
		/*
		 * BackendId not provided, so search the array using pid. We search
		 * the array back to front so as to reduce search overhead. Passing
		 * InvalidBackendId means that the target is most likely an auxiliary
		 * process, which will have a slot near the end of the array.
		 */
		int			i;

		for (i = NumProcSignalSlots - 1; i >= 0; i--)
		{
			slot = &ProcSignal->psh_slot[i];

			if (slot->pss_pid == pid)
			{
				/* the above note about race conditions applies here too */

				/* Atomically set the proper flag */
				slot->pss_signalFlags[reason] = true;
				/* Send signal */
				return kill(pid, SIGUSR1);
			}
		}
	}

	errno = ESRCH;
	return -1;
}

walsender中SIGUSR1的注册为如下：

	pqsignal(SIGUSR1, procsignal_sigusr1_handler);
	pqsignal(SIGUSR2, WalSndLastCycleHandler);	/* request a last cycle and
												 * shutdown */

sigusr1根据信号的reason来分类处理

/*
 * procsignal_sigusr1_handler - handle SIGUSR1 signal.
 */
void
procsignal_sigusr1_handler(SIGNAL_ARGS)
{
...
	if (CheckProcSignal(PROCSIG_WALSND_INIT_STOPPING))
		HandleWalSndInitStopping();
...
}

处理PROCSIG_WALSND_INIT_STOPPING的函数为HandleWalSndInitStopping

/*
 * Handle PROCSIG_WALSND_INIT_STOPPING signal.
 */
void
HandleWalSndInitStopping(void)
{
	Assert(am_walsender);

	/*
	 * If replication has not yet started, die like with SIGTERM. If
	 * replication is active, only set a flag and wake up the main loop. It
	 * will send any outstanding WAL, wait for it to be replicated to the
	 * standby, and then exit gracefully.
	 */
	if (!replication_active)
		kill(MyProcPid, SIGTERM);
	else
		got_STOPPING = true;//如果walsender是active的，initstopping函数只会设置状态，让主循环去处理
}

这个注释中的main loop有点意义不明，walsender有主循环ServerLoop，但实际上只有WalSndWaitForWal中的循环才有关于got_STOPPING的判断。

WalSndWaitForWal函数是walsender等待新的wal日志的主循环函数。由于wal record生成之初还在内存中，walwriter会根据一定的条件flush，不是随时都flush。WalSndWaitForWal函数通过对比当前sent的LSN和flushed的LSN，以判断是否需要send新的wal日志。换句话说，没有flush的wal不会传递，flush过的wal才会传给下游。

WalSndWaitForWal关于stopping的代码段：

/*
 * Wait till WAL < loc is flushed to disk so it can be safely sent to client.
 *
 * Returns end LSN of flushed WAL. Normally this will be >= loc, but
 * if we detect a shutdown request (either from postmaster or client)
 * we will return early, so caller must always check.
 */
static XLogRecPtr
WalSndWaitForWal(XLogRecPtr loc)
{
 ...
	for (;;)
	{
 ...
 //收到got_STOPPING信息后，做一次flush wal操作
 //这是必须的！因为walwriter进程在此时可能已经关闭了，可能还有wal没有刷盘
		if (got_STOPPING)
			XLogBackgroundFlush();

		/* Update our idea of the currently flushed position. */
		if (!RecoveryInProgress())
			RecentFlushPtr = GetFlushRecPtr();
		else
			RecentFlushPtr = GetXLogReplayRecPtr(NULL);

 //跳出for循环
 //有了新的RecentFlushPtr位置后，还需要send
		if (got_STOPPING)
			break;
 ...
	}
	/* reactivate latch so WalSndLoop knows to continue */
	SetLatch(MyLatch);
	return RecentFlushPtr;
}

回到walsender主循环：WalSndLoop(XLogSendLogical);

/* Main loop of walsender process that streams the WAL over Copy messages. */
static void
WalSndLoop(WalSndSendDataCallback send_data)
{
...
	for (;;)
	{
		/* Clear any already-pending wakeups */
		ResetLatch(MyLatch);
		...

		//处理下游返回的信息
		ProcessRepliesIfAny();

		/*
		 * If we have received CopyDone from the client, sent CopyDone
		 * ourselves, and the output buffer is empty, it's time to exit
		 * streaming.
		 */
 //streaming做完就退出循环
		if (streamingDoneReceiving && streamingDoneSending &&
			!pq_is_send_pending())
			break;

 //output buffer是否还有pending的data，有就send
		if (!pq_is_send_pending())
			send_data();
		else
			WalSndCaughtUp = false;

		/* Try to flush pending output to the client */
		if (pq_flush_if_writable() != 0)
			WalSndShutdown();//下游不可写入，下游端关闭了，正常关闭walsender，退出码0

		/* If nothing remains to be sent right now ... */
		if (WalSndCaughtUp && !pq_is_send_pending())
		{
			/*
			 * If we're in catchup state, move to streaming. This is an
			 * important state change for users to know about, since before
			 * this point data loss might occur if the primary dies and we
			 * need to failover to the standby. The state change is also
			 * important for synchronous replication, since commits that
			 * started to wait at that point might wait for some time.
			 */
 //数据已经传完了，但是仍然要发送提交信息
			if (MyWalSnd->state == WALSNDSTATE_CATCHUP)
			{
				ereport(DEBUG1,
						(errmsg("\"%s\" has now caught up with upstream server",
								application_name)));
				WalSndSetState(WALSNDSTATE_STREAMING);
			}

 //收到SIGUSR2，表示shutdown checkpoint做完了。
 //把shutdown checkpoint record发出去，等待完成再退出
			if (got_SIGUSR2)
				WalSndDone(send_data);//退出码0
		}
		
		...
	}
}

走远了，回到checkpointer的ShutdownXLOG逻辑，以上只是在分析WalSndInitStopping()。这个信号发送给walsender后，会执行WalSndWaitStopping以等待walsender。

只要有walsender没有退出，这里就是一个死循环不会return：

/*
 * Wait that all the WAL senders have quit or reached the stopping state. This
 * is used by the checkpointer to control when the shutdown checkpoint can
 * safely be performed.
 */
void
WalSndWaitStopping(void)
{
	for (;;)
	{
		int			i;
		bool		all_stopped = true;

		for (i = 0; i < max_wal_senders; i++)
		{
			WalSnd	 *walsnd = &WalSndCtl->walsnds[i];

			SpinLockAcquire(&walsnd->mutex);

			if (walsnd->pid == 0)
			{
				SpinLockRelease(&walsnd->mutex);
				continue;
			}

			if (walsnd->state != WALSNDSTATE_STOPPING)
			{
				all_stopped = false;
				SpinLockRelease(&walsnd->mutex);
				break;
			}
			SpinLockRelease(&walsnd->mutex);
		}

		/* safe to leave if confirmation is done for all WAL senders */
		if (all_stopped)
			return;

		pg_usleep(10000L);		/* wait for 10 msec */
	}
}

最后结合walsender.c的注释：

 * If the server is shut down, checkpointer sends us
 * PROCSIG_WALSND_INIT_STOPPING after all regular backends have exited. If
 * the backend is idle or runs an SQL query this causes the backend to
 * shutdown, if logical replication is in progress all existing WAL records
 * are processed followed by a shutdown. Otherwise this causes the walsender
 * to switch to the "stopping" state. In this state, the walsender will reject
 * any further replication commands. The checkpointer begins the shutdown
 * checkpoint once all walsenders are confirmed as stopping. When the shutdown
 * checkpoint finishes, the postmaster sends us SIGUSR2. This instructs
 * walsender to send any outstanding WAL, including the shutdown checkpoint
 * record, wait for it to be replicated to the standby, and then exit.

当所有的常规backend都退出后，checkpointer会发送PROCSIG_WALSND_INIT_STOPPING给walsender
walsender可能进入stopping状态
当所有walsender都进入stopping状态后，checkpointer才会做shutdown checkpoint
当shutdown checkpoint完成后，pm发送SIGUSR2给walsender，walsender会发送额外的wal，包括shutdown checkpoint记录本身，并等待standby完成再退出

停库流程图
#

撸完源码好像懂了又好像没懂，需要一个停库流程图来理清思路。汇总fast shutdown停库流程图：

（高清大图：https://www.processon.com/view/link/6778a73a04a8344b9502637a）

PG通过信号、各进程主循环、PM状态机、pmdie进程回收函数来共同管理停库逻辑
还需注意：信号本身是异步的。如果需要等待目标进程处理信号的结果，通常需要通过其他同步机制（如管道、信号量、共享内存等）来实现。PG主要通过进程依赖和进程是否正常退出来判断信号是否被正确处理。
pgarch、walsender被认为是同一类进程，与其他进程（walwriter、bgwriter）等处理不同。pgarch、walsender需要额外做“最后一个任务”这件事。“最后一个任务”的信号通常定义为SIGUSR2
checkpointer的正常退出依赖pgarch、walsender的正常退出
pgarch的最后一个任务是最后一次归档。所以归档会影响停库
walsender的倒数第二个任务是传递最后的wal，最后一个任务是传递checkpoint shutdown信息。且这些任务需要下游回复消息，所以walsender会影响停库。

测试复现
#

测试：复现walsender阻止停库
#

在fast stop停库后，walsender可能阻止停库。

测试了各自场景去复现walsender阻止停库，目前来看以下条件同时满足比较容易触发停库异常：

发布订阅一个walsender
dts一个walsender
大量子事务导致复制槽spill中

这个三合一场景不代表唯一场景，只是测试了很多场景这个好复现一点。

--复现命令（不是特别稳定的复现）
1.建表
--pg
create table lzlpg(id bigserial primary key,a char(2000),b char(2000),c char(2000));
--oracle
create table lzl.lzloracle(id number primary key ,a char(2000),b char(2000),c char(2000)) tablespace FADATA;
2.搭建2条逻辑链路（1条发布订阅，一条dts到oracle）

3.改小logical_decoding_work_mem
logical_decoding_work_mem=1MB

4.写入大量数据（推荐子事务spill）
--一次insert一行，每个insert一个子事务
echo "begin;">subtx.sql
for i in {1..500000}
do
 echo "savepoint p$i;">>subtx.sql
 echo "insert into lzlpg(column1,column2,column3) select 'a','b','c';">>subtx.sql
done

nohup psql -d lzl -f subtx.sql &

5.没写入完就停库
pg_ctl stop -D $PGDATA -m fast

此时fast停库，数据库处于一个非完整停库状态，如下:

~/lzl/slot]$ ps -axjf|grep 110402
150696 64964 64961 146782 pts/42 64961 S+ 6001 0:00 \_ grep --color=auto 110402
 1 110402 110402 110402 ? -1 Ss 6001 0:00 /myhost/postgres/base/rasesql1.5.6/bin/postgres -D /myhost/pg8094/data
110402 110599 110599 110599 ? -1 Ss 6001 0:00 \_ postgres: lzlpg: logger 
110402 117803 117803 117803 ? -1 Ss 6001 0:00 \_ postgres: lzlpg: checkpointer 
110402 117807 117807 117807 ? -1 Ss 6001 0:00 \_ postgres: lzlpg: stats collector 
110402 118563 118563 118563 ? -1 Rs 6001 3:29 \_ postgres: lzlpg: walsender lzl 127.0.0.1(62971) idle
110402 222918 222918 222918 ? -1 Rs 6001 2:59 \_ postgres: lzlpg: walsender dtssync 30.181.46.203(57218) idle

walsender、checkpointer、postmaster都在，logger、stats也没有退出。

控制文件的状态为in production：生产运行中，说明checkpoint做的本地shutdown checkpoint没有做完：

~/lzl/slot]$ pg_controldata|grep -i state
Database cluster state: in production

checkpointer堆栈：

pstack 117803
#0 0x00002b879fe0b983 in __select_nocancel () from /lib64/libc.so.6
#1 0x00000000008fd04a in pg_usleep (microsec=microsec@entry=10000) at pgsleep.c:56
#2 0x00000000007610c8 in WalSndWaitStopping () at walsender.c:3209
#3 0x000000000051fa86 in ShutdownXLOG (code=code@entry=0, arg=arg@entry=0) at xlog.c:8596
#4 0x00000000007215ff in HandleCheckpointerInterrupts () at checkpointer.c:566
#5 CheckpointerMain () at checkpointer.c:343
...

此时的checkpointer堵在WalSndWaitStopping函数，代表checkpointer在等待walsender进程进入stopping状态。

此时的walsender堆栈：

#0 0x00000000007484fb in ReorderBufferLargestTXN (rb=<optimized out>) at reorderbuffer.c:2345
#1 ReorderBufferCheckMemoryLimit (rb=0x2b8808b94118) at reorderbuffer.c:2390
#2 ReorderBufferQueueChange (rb=0x2b8808b94118, xid=<optimized out>, lsn=1676456602544, change=change@entry=0x2b87a229f408) at reorderbuffer.c:649
#3 0x000000000073ec99 in DecodeTruncate (buf=<optimized out>, buf=<optimized out>, ctx=<optimized out>) at decode.c:872
#4 DecodeHeapOp (buf=0x7ffda7d35180, ctx=0x2b87a224b118) at decode.c:455
#5 LogicalDecodingProcessRecord (ctx=0x2b87a224b118, record=<optimized out>) at decode.c:126
#6 0x000000000075f502 in XLogSendLogical () at walsender.c:2886
#7 0x0000000000761822 in WalSndLoop (send_data=send_data@entry=0x75f4c0 <XLogSendLogical>) at walsender.c:2287
...

walsender堵在事务溢出函数。（为什么堵还没有搞清楚！！！）

checkpointer进程阻塞在WalSndWaitStopping函数：

/*
 * Wait that all the WAL senders have quit or reached the stopping state. This
 * is used by the checkpointer to control when the shutdown checkpoint can
 * safely be performed.
 */
void
WalSndWaitStopping(void)
{
	for (;;)
	{
		int			i;
		bool		all_stopped = true;

		for (i = 0; i < max_wal_senders; i++)
		{
			WalSnd	 *walsnd = &WalSndCtl->walsnds[i];

			SpinLockAcquire(&walsnd->mutex);

			if (walsnd->pid == 0)
			{
				SpinLockRelease(&walsnd->mutex);
				continue;
			}

			if (walsnd->state != WALSNDSTATE_STOPPING)
			{
				all_stopped = false;
				SpinLockRelease(&walsnd->mutex);
				break;
			}
			SpinLockRelease(&walsnd->mutex);
		}

		/* safe to leave if confirmation is done for all WAL senders */
		if (all_stopped)
			return;

		pg_usleep(10000L);		/* wait for 10 msec */
	}
}

从代码和堆栈来看肯定是进入了条件walsnd->state != WALSNDSTATE_STOPPIN才会出现跳不出死循环。

测试：停库中间态的处理方案
#

以上是个尴尬的停库停一半的状态，除了kill -9 外，实际上还有其他好办法可以一致性停库。

方案1：关闭下游进程
方案2：发送SIGTERM给walsender

方案1测试：

由于下游退出后，walsender也会跟随退出：

static void
ProcessRepliesIfAny(void)
{...
				/*
				 * 'X' means that the standby is closing down the socket.
				 */
			case 'X':
				proc_exit(0);

如果是发布订阅，在订阅端执行以下命令即可，即使是上游处于停库中间态也会将walsender退出。

\c lzldb
alter SUBSCRIPTION sub_lzl disable;

不过这依赖下游自身的处理，我们也不能快速地关闭dts等同步工具的下游接收进程。

方案2测试：

由于walsender注册了SIGTERM信号，库运行时跑的select pg_terminate_backend($walsender_pid)命令也是发送SIGTERM给walsender，所以理论上只要发送SIGTERM给walsender应该可以处理这个问题，而不必发送kill -9。

命令如下：

kill -SIGTERM 62834
#同 kill -15 62834
#同 kill 62834

正常kill后pm等进程全部退出。

查看控制文件和wal日志信息以确认是否是一致性停库：

1.pg_controldata的数据库state从in production转换为shut down一致性停库：

$ pg_controldata|grep -i state
Database cluster state: shut down

2.wal日志的最后一个record是CHECKPOINT_SHUTDOWN：

pg_waldump 000000010000018600000012|tail -1
pg_waldump: fatal: error in WAL record at 186/915D7920: invalid record length at 186/915D7998: wanted 24, got 0
rmgr: XLOG len (rec/tot): 114/ 114, tx: 0, lsn: 186/915D7920, prev 186/915D78A8, desc: CHECKPOINT_SHUTDOWN redo 186/915D7920; tli 1; prev tli 1; fpw true; xid 0:13431045; oid 3808147; multi 3; offset 6; oldest xid 485 in DB 1; oldest multi 1 in DB 1; oldest/newest commit timestamp xid: 494/13431044; oldest running xid 0; shutdown

测试：复现只有主库有CHECKPOINT_SHUTDOWN
#

生产现场有个现象是，本地wal有shutdown checkpoint但是从库没有。生产是在半停库状态时做的immediate stop，随后启动库没有启动起来。

当时主从的wal日志最后2条record类似如下：

#主库wal：
CHECKPOINT_ONLINE
CHECKPOINT_SHUTDOWN
#从库wal：
CHECKPOINT_ONLINE

复现命令：

## 1. 先复现walsender阻止停库
略
## 2. 查看最后一条wal record
rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 188/307ABE00, prev 188/307ABDC8, desc: RUNNING_XACTS nextXid 13432445 latestCompletedXid 13432444 oldestRunningXid 13432445
## 3. pg_ctl stop -D $PGDATA -m i
## 4. 查看最后一条wal record
不变，同2
## 5. pg_ctl start -D $PGDATA
## 6. 查看最后两条wal record
rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 188/307ABE00, prev 188/307ABDC8, desc: RUNNING_XACTS nextXid 13432445 latestCompletedXid 13432444 oldestRunningXid 13432445 #同2
rmgr: XLOG len (rec/tot): 114/ 114, tx: 0, lsn: 188/307ABE38, prev 188/307ABE00, desc: CHECKPOINT_SHUTDOWN redo 188/307ABE38; tli 1; prev tli 1; fpw true; xid 0:13432445; oid 3832732; multi 3; offset 6; oldest xid 485 in DB 1; oldest multi 1 in DB 1; oldest/newest commit timestamp xid: 494/13432444; oldest running xid 0; shutdown #出现CHECKPOINT_SHUTDOWN

从该复现来看，CHECKPOINT_SHUTDOWN其实是起库的时候做！

这与现场的动作一致：1.fast停库没停下来 2.immediate停库 3.起库没启起来。

疑问1：起库什么时候做的CHECKPOINT_SHUTDOWN？

疑问2：CHECKPOINT_ONLINE的触发时机？复现表象来看，偶现fast shutdown出现最后一个wal record为CHECKPOINT_ONLINE

疑问1分析：

起库做shutdown checkpoint，这很容易联想到是startup进程做的。由于之前分析过startup进程的起库流程，我们可以直接定位到函数StartupXLOG：

/*
 * This must be called ONCE during postmaster or standalone-backend startup
 */
void
StartupXLOG(void)
{...
	if (InRecovery) //因为是shutdown停库所以会做实例恢复
	{
		/*
		 * Perform a checkpoint to update all our recovery activity to disk.
		 *
		 * Note that we write a shutdown checkpoint rather than an on-line
		 * one. This is not particularly critical, but since we may be
		 * assigning a new TLI, using a shutdown checkpoint allows us to have
		 * the rule that TLI only changes in shutdown checkpoints, which
		 * allows some extra error checking in xlog_redo.
		 *
		 * In fast promotion, only create a lightweight end-of-recovery record
		 * instead of a full checkpoint. A checkpoint is requested later,
		 * after we're fully out of recovery mode and already accepting
		 * queries.
		 */
		if (bgwriterLaunched) //这个if明显是从库流复制用的逻辑
		{...
		}
		else //主库的startup会走到这里
			CreateCheckPoint(CHECKPOINT_END_OF_RECOVERY | CHECKPOINT_IMMEDIATE);
	}

做shutdown checkpoint是故意的，主要是为了TLI逻辑的代码健壮性
只要是非一致性停库，起库的时候就会做shutdown checkpoint

所以，直接-m i暴力停库再起库，也会出现CHECKPOINT_SHUTDOWN，自测。

疑问2分析：

多次测试，偶现，推测是刚好停库前满足checkpoint条件触发了一次online checkpoint，纯属巧合。

联想数据库停库失败后，无论是脚本、HA还是人工介入都有可能做暴力停库，所以停库前推荐至少做一次checkpoint。

测试：归档对停库的影响
#

在分析停库代码的时候，还发现checkpointer进程退出后，reaper checkpointer会发送SIGUSR2给pgarch让其最后一次归档并退出：

static void
reaper(SIGNAL_ARGS)
{...
		if (pid == CheckpointerPID)
		{
			CheckpointerPID = 0;
			if (EXIT_STATUS_0(exitstatus) && pmState == PM_SHUTDOWN)
			{...

				/* Waken archiver for the last time */
				if (PgArchPID != 0)
					signal_child(PgArchPID, SIGUSR2);
 ...
			}
...

而pm的退出依赖除syslogger外所有进程的退出：

	if (pmState == PM_WAIT_DEAD_END)
	{
		if (dlist_is_empty(&BackendList) &&
			PgArchPID == 0 && PgStatPID == 0)
		{
			/* These other guys should be dead already */
			Assert(StartupPID == 0);
			Assert(WalReceiverPID == 0);
			Assert(BgWriterPID == 0);
			Assert(CheckpointerPID == 0);
			Assert(WalWriterPID == 0);
			Assert(AutoVacPID == 0);
			/* syslogger is not considered here */
			pmState = PM_NO_CHILDREN;
		}
	}

所以在生产环境中还发现了归档慢对停库有影响。

复现命令：

#配置归档
archive_mode = on
archive_command = '/bin/false ;sleep 1000'#配置归档永远为false且设置sleep以绕过NUM_ARCHIVE_RETRIES逻辑

#停库
pg_ctl stop -D $PGDATA -m fast

停库后进程如下：

$ ps -axjf|grep 61470
88406 88405 68705 pts/48 88405 S+ 6001 0:00 \_ grep --color=auto 61470
61470 61470 61470 ? -1 Ss 6001 0:00 /myhost/postgres/base/rasesql1.5.6/bin/postgres -D /myhost/pg8094/data
61772 61772 61772 ? -1 Ss 6001 0:00 \_ postgres: lzlpg: logger 
63880 63880 63880 ? -1 Ss 6001 0:00 \_ postgres: lzlpg: archiver archiving 000000010000018800000007

因为这里的checkpointer已经完整停下来了，数据库是一致状态，所以archiver直接kill -9也没有关系

一句话总结
#

问题1.为什么停库没有停下来？

walsender阻止了停库。checkpointer给walsender发送SIGUSR1，并无限等待所有walsender进程stopping状态，checkpointer卡在这一步。

后面停库停下来是因为-m i暴力停库

问题2.walsender阻止停库中间态是否有其他方案优雅停库？

有。给所有walsender发送SIGTERM信号，既kill（or kill -15、kill -SIGTERM)。随后checkpointer、postmaster会完整停库。

walsender启动时注册过SIGTERM信号，测试来看没有处理不了的情况。

SIGTERM也是pg_terminate_backend(pid)所发送的信号，也是标准停库时应该执行的命令以停止walsender。

问题3.为什么主从库只差一条shutdown checkpoint？

3.1主从库都有CHECKPOINT_ONLINE 的解释：

主库触发CHECKPOINT_ONLINE纯属巧合
由于物理walsender还在，这条wal record传输到了从库

3.2只有主库有CHECKPOINT_SHUTDOWN的解释：

这条CHECKPOINT_SHUTDOWN是主库起库的时候做的
由于主库没有起完，这条wal record没有传到从库

问题4.archiver为什么会阻止停库？

在reaper checkpointer进程时，pm会让archiver做最后一次归档，而pm依赖除syslogger之外的所有进程退出，所以最后一次归档如果够慢或者其他问题，会阻止停库。归档失败不会，归档进程会很快退出。

问题5.哪些进程会阻止停库？

references
#

https://www.postgresql.org/docs/current/server-shutdown.html https://wiki.postgresql.org/wiki/Signals postgres.c postmaster.c walsender.c xlog.c checkpointer.c startup.c pgarch.c

读书笔记——DDIA-v2 设计数据密集型应用（第二版）

Fri, 20 Sep 2024 00:00:00 +0000

ddia-v2中文版地址：https://github.com/Vonng/ddia/tree/v2 ddia-v2看完感觉爱不释手，只要是数据相关的知识都娓娓道来，为什么会这样？现在是怎样的？这样有什么问题？其中的看法和想法实在精辟、干练，甚至连每个章节的航海图都很有意思。

注意：本文只是对原作的一点摘抄，基本没有自己的思路和想法。仅仅是把一些非常爱的东西摘下来，有些已经掌握和太遥远的知识是略过的！

ch1 数据系统架构中的利弊权衡
#

OLTP&OLAP
#

OLTP和分析之间的区别并不总是明确的，但下表列出了一些典型的特征

属性	业务系统 (OLTP)	分析系统 (OLAP)
主要读取模式	点查询（按键提取个别记录）	在大量记录上聚合
主要写入模式	创建、更新和删除个别记录	批量导入（ETL）或事件流
人类用户示例	网络/移动应用的终端用户	内部分析师，用于决策支持
机器使用示例	检查是否授权某项行动	检测欺诈/滥用模式
查询类型	固定的查询集合，由应用预定义	分析师可以进行任意查询
数据表示	数据的最新状态（当前时间点）	随时间发生的事件历史
数据集大小	GB,TB	TB,PB

数据仓库是一个单独的数据库，分析师可以尽情查询，而不影响OLTP操作.数据仓库通常以与OLTP数据库非常不同的方式存储数据，以优化常见于分析的查询类型将数据获取到数据仓库的过程称为提取-转换-加载（Extract–Transform–Load,ETL）有些数据库系统提供混合事务/分析处理（HTAP），旨在在单一系统中同时启用OLTP和分析，无需从一个系统向另一个系统进行ETL 。 尽管存在HTAP，由于它们目标和要求的不同，事务性和分析性系统之间的分离仍然很常见。特别是，每个业务系统拥有自己的数据库被视为良好的实践，导致有数百个独立的操作数据库；另一方面，一个企业通常只有一个数据仓库，这样业务分析师可以在单个查询中合并来自几个业务系统的数据。 数据湖一个集中的数据存储库，存放可能对分析有用的任何数据，通过ETL过程从业务系统获取。与数据仓库的不同之处在于，数据湖只包含文件，不强加任何特定的文件格式或数据模型。数据仓库通常使用关系数据模型，通过SQL查询。 数据湖仓不仅是单独的数据仓库，还可以直接在数据湖中的文件上运行典型的数据仓库工作负载（SQL查询和商业分析），以及数据科学/机器学习工作负载，这种架构被称为数据湖仓。它需要一个查询执行引擎和一个元数据（例如，模式管理）层来扩展数据湖的文件存储。Apache Hive、Spark SQL、Presto和Trino是这种方法的例子。

云服务和自托管
#

云服务的优缺点使用云服务，而不是自己运行可比软件，本质上是将该软件的运营外包给云提供商。支持和反对使用云服务的理由都很充分。优势：

当你使用云时，仍然需要一个运营团队，但将基本的系统管理外包可以释放你的团队，专注于更高层次的问题
如果你的系统负载随时间变化很大，云服务特别有价值。如果你配置你的机器能够处理高峰负载，但这些计算资源大部分时间都处于空闲状态，系统的成本效益就会降低。
与物理机相比，云实例可以更快地配置，并且大小种类更多

缺点：

云服务最大的缺点是你对它没有控制权
如果你已经有设置和操作所需系统的经验，并且你的负载相当可预测（即，你需要的机器数量不会剧烈波动），那么通常购买自己的机器并自己运行软件会更便宜。
如果它缺少你需要的功能，你唯一能做的就是礼貌地询问供应商是否会添加它；你通常无法自己实现它。
如果服务出现故障，你只能等待它恢复。
如果你以某种方式使用服务，触发了一个错误或导致性能问题，你很难诊断问题。对于你自己运行的软件，你可以从业务系统获取性能指标和调试信息来帮助你了解其行为，你可以查看服务器日志，但使用供应商托管的服务时，你通常无法访问这些内部信息。
此外，如果服务关闭或变得无法接受地昂贵，或者如果供应商决定以你不喜欢的方式更改其产品，你将受制于他们——继续运行软件的旧版本通常不是一个选项，因此你将被迫迁移到另一个服务。如果有提供兼容API的替代服务，这种风险可以缓解，但对于许多云服务，没有标准的API，这增加了切换的成本，使供应商锁定成为一个问题。
像高频交易这样对延迟极其敏感的应用需要完全控制硬件，这样的业务上云不是一个好的选择。

云原生
#

类别	自托管系统	云原生系统
事务型/OLTP	MySQL, PostgreSQL, MongoDB	AWS Aurora , Azure SQL DB Hyperscale , Google Cloud Spanner
分析型/OLAP	Teradata, ClickHouse, Spark	Snowflake , Google BigQuery, Azure Synapse Analytics

云原生服务的关键思想是不仅使用由业务系统管理的计算资源，还要构建在更低层级的云服务之上，创建更高层级的服务。例如：

对象存储服务，如亚马逊 S3、Azure Blob 存储和 Cloudflare R2 存储大文件。它们提供的 API 比典型文件系统的 API 更有限（基本的文件读写），但它们的优势在于隐藏了底层的物理机器：服务自动将数据分布在许多机器上，因此你无需担心任何一台机器上的磁盘空间耗尽。即使某些机器或其磁盘完全失败，也不会丢失数据。
许多其他服务又是建立在对象存储和其他云服务之上的：例如，Snowflake 是一种基于云的分析数据库（数据仓库），依赖于 S3 进行数据存储，还有一些服务又建立在 Snowflake 之上。

云原生系统通常是多租户的，这意味着它们不是为每个客户配置单独的机器，而是在同一共享硬件上由同一服务处理来自几个不同客户的数据和计算。多租户可以实现更好的硬件利用率、更容易的可扩展性和云提供商更容易的管理。

云时代的运营
#

传统上，管理组织服务器端数据基础设施的人被称为数据库管理员（DBAs）或系统管理员（sysadmins）。近年来，许多组织试图将软件开发和运营的角色整合到一个团队中，共同负责后端服务和数据基础设施；DevOps哲学指导了这一趋势。站点可靠性工程师（SREs）是谷歌实施这一理念的方式。 DevOps/SRE哲学更加强调：

自动化——偏好可重复的过程而不是一次性的手工作业，
偏好短暂的虚拟机和服务而不是长时间运行的服务器，
促进频繁的应用更新，
从事件中学习，
即使个别人员来去，也要保留组织对系统的知识。

基础设施公司的运营团队专注于向大量客户提供可靠服务的细节，而服务的客户尽可能少地花时间和精力在基础设施上。除了传统意义上的容量规划的需要，采用云服务可能比运行自己的基础设施更容易且更快。虽然云正在改变运营的角色，但运营的需求依旧迫切。

ch2 定义非功能性要求
#

硬件和软件缺陷
#

在大规模系统中，硬件故障发生得足够频繁，以至于它们成为正常系统运作的一部分：

每年大约有 2-5% 的磁盘硬盘出现故障；在一个拥有 10,000 块硬盘的存储集群中，我们因此可以预计平均每天会有一块硬盘故障。
每年大约有 0.5-1% 的固态硬盘（SSD）故障。不可纠正的错误大约每年每块硬盘发生一次
大约每 1,000 台机器中就有一台的 CPU 核心偶尔计算出错误的结果
RAM 中的数据也可能被破坏，原因可能是宇宙射线等随机事件，或是永久性物理缺陷。此外，某些病态的内存访问模式可以高概率地翻转位。
其他硬件组件如电源供应器、RAID 控制器和内存模块也会发生故障
整个数据中心可能变得不可用（例如，由于停电或网络配置错误）或甚至被永久性破坏（例如火灾或洪水）。

软件故障往往是难以预料，而且因为是跨节点相关的，所以硬件故障往往可能造成更多的系统失效：

接受特定的错误输入，便导致所有应用服务器实例崩溃的 BUG。例如 2012 年 6 月 30 日的闰秒，由于 Linux 内核中的一个错误，许多应用同时挂掉了。
失控进程会用尽一些共享资源，包括 CPU 时间、内存、磁盘空间或网络带宽。
系统依赖的服务变慢，没有响应，或者开始返回错误的响应。
级联故障，一个组件中的小故障触发另一个组件中的故障，进而触发更多的故障

运维配置错误是导致服务中断的首要原因，而硬件故障（服务器或网络）仅导致了 10-25% 的服务中断。

可伸缩性原则
#

一个关于可扩展性的好的一般原则是将系统分解成可以相对独立运行的小组件。这是微服务背后的基本原则。然而，挑战在于知道应该在一起的事物和分开的事物之间划线的位置。

如果单机数据库可以完成工作，它可能比复杂的分布式设置更可取。一个拥有五个服务的系统比拥有五十个服务的系统简单。好的架构通常涉及到方法的混合使用。

运维
#

运维团队对于保持软件系统顺利运行至关重要。一个优秀运维团队的典型职责如下（或者更多）：

监控系统的运行状况，并在服务状态不佳时快速恢复服务。
跟踪问题的原因，例如系统故障或性能下降。
及时更新软件和平台，比如安全补丁。
了解系统间的相互作用，以便在异常变更造成损失前进行规避。
预测未来的问题，并在问题出现之前加以解决（例如，容量规划）。
建立部署、配置、管理方面的良好实践，编写相应工具。
执行复杂的维护任务，例如将应用程序从一个平台迁移到另一个平台。
当配置变更时，维持系统的安全性。
定义工作流程，使运维操作可预测，并保持生产环境稳定。
铁打的营盘流水的兵，维持组织对系统的了解。

良好的可操作性意味着更轻松的日常工作，进而运维团队能专注于高价值的事情。数据系统可以通过各种方式使日常任务更轻松：

通过良好的监控，提供对系统内部状态和运行时行为的可见性。
为自动化提供良好支持，将系统与标准化工具相集成。
避免依赖单台机器（在整个系统继续不间断运行的情况下允许机器停机维护）。
提供良好的文档和易于理解的操作模型（“如果做 X，会发生 Y”）。
提供良好的默认行为，但需要时也允许管理员自由覆盖默认值。
有条件时进行自我修复，但需要时也允许管理员手动控制系统状态。
行为可预测，最大限度减少意外。

运维的某些方面可以，而且应该是自动化的，但在最初建立正确运作的自动化机制仍然取决于人。

带有太强个人色彩的系统无法成功。当最初的设计完成并且相对稳定时，不同的人们以自己的方式进行测试，真正的考验才开始。 —— 高德纳

ch3 数据模型与查询语言
#

大多数应用程序是通过在一个数据模型之上层叠另一个数据模型来构建的。

作为应用开发者，你观察现实世界（其中有人、组织、商品、行动、资金流动、传感器等），并以对象或数据结构以及操作这些数据结构的 API 的形式对其进行建模。这些结构通常是针对你的应用特定的。
当你想存储这些数据结构时，你会用通用数据模型来表达它们，比如 JSON 或 XML 文档、关系数据库中的表，或图中的顶点和边。这些数据模型是本章的主题。
构建你的数据库软件的工程师决定了一种将该 JSON/关系/图数据表示为内存、磁盘或网络上的字节的方式。这种表现可能允许数据被查询、搜索、操作和以各种方式处理。我们将在[后续链接]中讨论这些存储引擎设计。
在更低的层次上，硬件工程师已经找出了如何将字节以电流、光脉冲、磁场等形式表示。

SQL & NOSQL
#

数据库能够在多个 CPU 核心和机器上并行执行声明式查询，而你无需担心如何实现该并行性。在手工编码的算法中，自行实现这种并行执行将是一项巨大的工作。

关系模型，尽管已有半个世纪之久，仍然是许多应用程序的重要数据模型——特别是在数据仓库和商业分析中，关系星型或雪花型架构和SQL查询无处不在。然而，在其他领域，几种替代关系数据的模型也变得流行：

文档模型 针对数据以自包含的 JSON 文档形式出现，且文档之间的关系罕见的用例。
图数据模型 则走向相反方向，针对任何事物都可能与一切相关的用例，查询可能需要跨多个跳点寻找感兴趣的数据（这可以通过在 Cypher、SPARQL 或 Datalog 中使用递归查询来表达）。
dataframe 将关系数据概括为大量的列，从而在数据库和构成大部分机器学习、统计数据分析和科学计算基础的多维数组之间架起了一座桥梁。

数据库也趋向于通过添加对其他数据模型的支持来扩展到相邻领域：例如，关系数据库增加了对文档数据的支持，以 JSON 列的形式，文档数据库增加了类似关系的连接，对 SQL 中图数据的支持也在逐渐改进。

ch4 存储和索引
#

散列索引
#

键值存储与在大多数编程语言中可以找到的 字典（dictionary） 类型非常相似，通常字典都是用 散列映射（hash map） 或 散列表（hash table） 实现的。

一般来说，HASH索引的散列映射完全保留在内存中。而数据值可以使用比可用内存更多的空间，因为可以在硬盘上通过一次硬盘查找操作来加载所需部分。

散列索引的缺陷：

原则上可以在硬盘上维护一个散列映射，不幸的是硬盘散列映射很难表现优秀。它需要大量的随机访问 I/O，而后者耗尽时想要再扩充是很昂贵的，并且需要很烦琐的逻辑去解决散列冲突
范围查询效率不高。例如，你无法轻松扫描 kitty00000 和 kitty99999 之间的所有键 —— 你必须在散列映射中单独查找每个键

B树索引
#

B树索引在1970年就已经出现，并且广泛被行业接受和使用。该部分内容大部分人较为熟悉，略。

SStables & LSM tree
#

HASH索引中键值对的顺序并不重要，但我们可以要求键值对的序列按键排序。这个格式称为排序字符串表（Sorted String Table），简称 SSTable。与使用散列索引的日志段相比，SSTable 有几个大的优势：

即使文件大于可用内存，合并段的操作仍然是简单而高效的。这种方法就像归并排序算法中使用的方法一样，如图 3-4 所示：你开始并排读取多个输入文件，查看每个文件中的第一个键，复制最低的键（根据排序顺序）到输出文件，不断重复此步骤，将产生一个新的合并段文件，而且它也是也按键排序的。
为了在文件中找到一个特定的键，你不再需要在内存中保存所有键的索引。你仍然需要一个内存中的索引来告诉你一些键的偏移量，但它可以是稀疏的：每几千字节的段文件有一个键就足够了，因为几千字节可以很快地被扫描完。

使用这些数据结构，你可以按任何顺序插入键，并按排序顺序读取它们。现在我们可以让我们的存储引擎以如下方式工作：

有新写入时，将其添加到内存中的平衡树数据结构（例如红黑树）。这个内存树有时被称为内存表（memtable）。
当内存表大于某个阈值（通常为几兆字节）时，将其作为 SSTable 文件写入硬盘。这可以高效地完成，因为树已经维护了按键排序的键值对。新的 SSTable 文件将成为数据库中最新的段。当该 SSTable 被写入硬盘时，新的写入可以在一个新的内存表实例上继续进行。
收到读取请求时，首先尝试在内存表中找到对应的键，如果没有就在最近的硬盘段中寻找，如果还没有就在下一个较旧的段中继续寻找，以此类推。
时不时地，在后台运行一个合并和压缩过程，以合并段文件并将已覆盖或已删除的值丢弃掉。

这里描述的算法本质上是LevelDB和RocksDB这些键值存储引擎库所使用的技术，这些存储引擎被设计嵌入到其他应用程序中。在 Cassandra和HBase中也使用了类似的存储引擎，而且他们都受到了Google的Bigtable 论文（引入了术语 SSTable 和 memtable ）的启发。

内存数据库
#

内存数据库：随着 RAM 变得更便宜，每GB成本比RAM低的论据被侵蚀了。许多数据集不是那么大，所以将它们全部保存在内存中是非常可行的，包括可能分布在多个机器上。这导致了内存数据库的发展。在重新启动计算机时丢失的数据是可以接受的。也可以通过特殊的硬件（例如电池供电的 RAM）来实现持久性，也可以将更改日志写入硬盘，还可以将定时快照写入硬盘或者将内存中的状态复制到其他机器上。

典型的内存数据库Redis通过异步写入硬盘提供了较弱的持久性。其他内存数据库还有Memcached、VoltDB、MemSQL、Oracle TimesTen、RAM Cloud。

反直觉的是，内存数据库的性能优势并不是因为它们不需要从硬盘读取，相反，它们更快的原因在于省去了将内存数据结构编码为硬盘数据结构的开销。

物化视图与OLAP
#

如 SQL 中的 COUNT、SUM、AVG、MIN 或 MAX。如果相同的聚合被许多不同的查询使用，那么每次都通过原始数据来处理可能太浪费了。为什么不将一些查询使用最频繁的计数或总和缓存起来？创建这种缓存的一种方式是物化视图（Materialized View）。

当底层数据发生变化时，物化视图需要更新，因为它是数据的非规范化副本。数据库可以自动完成该操作，但是这样的更新使得写入成本更高，这就是在 OLTP 数据库中不经常使用物化视图的原因。在读取繁重的数据仓库中，它们可能更有意义，因为数仓不会有小而多的更新。

物化数据立方体的优点是可以让某些查询变得非常快，因为它们已经被有效地预先计算了。例如，如果你想知道每个商店的总销售额，则只需查看合适维度的总计，而无需扫描数百万行的原始数据。

数据立方体的缺点是不具有查询原始数据的灵活性。例如，没有办法计算有多少比例的销售来自成本超过 100 美元的项目，因为价格不是其中的一个维度。因此，大多数数据仓库试图保留尽可能多的原始数据，并将聚合数据（如数据立方体）仅用作某些查询的性能提升手段。

列式存储
#

列式存储背后的想法很简单：不要将所有来自一行的值存储在一起，而是将来自每一列的所有值存储在一起。列式存储在关系数据模型中是最容易理解的，但它同样适用于非关系数据。例如，Parquet是一种列式存储格式，支持基于 Google 的 Dremel 的文档数据模型。这些优化（列压缩、排序等等）在数据仓库中是有意义的，因为其负载主要由分析人员运行的大型只读查询组成。列式存储、压缩和排序都有助于更快地读取这些查询。然而，他们的缺点是写入更加困难。

ch5 编码和演化
#

REST与RPC
#

服务器通过网络公开 API，并且客户端可以连接到服务器以向该 API 发出请求。服务器公开的 API 被称为服务。通过 GET 请求下载，通过 POST 请求提交数据到服务器。当服务使用 HTTP 作为底层通信协议时，可称之为 Web 服务。有两种流行的 Web 服务方法：REST 和 SOAP。REST 不是一个协议，而是一个基于 HTTP 原则的设计哲学，根据 REST 原则设计的 API 称为 RESTful。远程过程调用（RPC）与本地函数调用非常不同

本地函数调用是可预测的，并且成功或失败仅取决于受你控制的参数。网络请求是不可预测的：请求或响应可能由于网络问题会丢失，或者远程计算机可能很慢或不可用
本地函数调用要么返回结果，要么抛出异常，或者永远不返回（因为进入无限循环或进程崩溃）。网络请求有另一个可能的结果：由于超时，它返回时可能没有结果。
等等。

REST 似乎是公共 API 的主要风格，RPC 框架的主要重点在于同一组织拥有的服务之间的请求，通常在同一数据中心内。

ch6 复制
#

复制日志、failover、单主模式，内容比较简单，略。

多主复制
#

多主复制在许多数据库中都属于改装的功能，所以常常存在微妙的配置缺陷，且经常与其他数据库功能之间出现意外的反应。比如自增主键、触发器、完整性约束等都可能会有麻烦。因此，多主复制往往被认为是危险的领域，应尽可能避免。但是多主复制确实有一定的优势，例如分散写入IO、容灾、异地多中心减少网络开销（本地写入）等等。写冲突：多主复制的最大问题是可能发生写冲突，解决起来也比较棘手。原则上，可以使冲突检测同步 - 即等待写入被复制到所有副本，然后再告诉用户写入成功。但是这可能违背了多主的初衷，如果你想要同步冲突检测，那么可能不如直接使用单主复制。解决多主写冲突：

避免冲突。例如应用程序控制用户仅编辑自己的数据。
收敛一致
- 最后写入胜利（LWW, last write wins）。按时间戳写入，可能会有数据丢失。
- 优先级写入。高优先级的写入，可能会有数据丢失。
- 额外的代码。保持冲突信息，编写额外的冲突解决代码

实时协作编辑应用程序允许多个人同时编辑文档，如Etherpad、Google Docs有许多成熟案例。数据库在多主写入方面还很年轻。数据库多主写入冲突大部分情况都在应用层面解决或避免，以下比较成熟的写入冲突的研究供参考：

无冲突复制数据类型（Conflict-free replicated datatypes，CRDT）是可以由多个用户同时编辑的集合、映射、有序列表、计数器等一系列数据结构，它们以合理的方式自动解决冲突。一些 CRDT 已经在 Riak 2.0 中实现。
可合并的持久数据结构（Mergeable persistent data structures）显式跟踪历史记录，类似于 Git 版本控制系统，并使用三向合并功能（而 CRDT 使用双向合并）。
操作转换（operational transformation）是 Etherpad 和 Google Docs 等协同编辑应用背后的冲突解决算法。它是专为有序列表的并发编辑而设计的，例如构成文本文档的字符列表。

ch7 分区
#

范围分区和hash分区
#

范围分区分区的缺点是某些特定的访问模式会导致热点。如果主键是时间戳，则分区对应于时间范围，写入操作都会转到同一个分区（即今天的分区），这样分区可能会因写入而过载，而其他分区则处于空闲状态。可以使用除了时间戳以外的其他东西作为主键的第一个部分以打散热点，缺点在于范围查询不会受益。 hash分区可以缓解偏斜和热点的风险。出于分区的目的，散列函数不需要多么强壮的加密算法。 hash分区的缺陷是，通过使用键散列进行分区，我们失去了键范围分区的一个很好的属性：高效执行范围查询的能力。哈希分区可以帮助减少热点。但是，它不能完全避免。例如，在社交媒体网站上，一个拥有数百万追随者的名人用户在做某事时可能会引发一场风暴。这个事件可能导致同一个键的大量写入（键可能是名人的用户 ID，或者人们正在评论的动作的 ID。此时哈希策略不起作用，因为两个相同 ID 的哈希值仍然是相同的。 如果一个主键很热，一个简单的解决方法是在主键的开始或结尾添加一个随机数。只要一个两位数的十进制随机数就可以将主键分散为 100 种不同的主键，从而存储在不同的分区中。总之还是打散热点，并且要考虑范围查询等副作用。

ch8 事务
#

ACID、BASE
#

ACID其实是一个很古老的定义，由于后期发现了很多的“异象”，所以一个系统说自己保证ACID实际上他说不清自己保证了什么。 ACID不管怎样还是深入人心的，他代表了事务的最基本的原则。相反的，不符合 ACID标准的系统有时被称为 BASE，他代表基本可用性（Basically Available），软状态（Soft State）和最终一致性（Eventual consistency）。BASE是NOSQL常提及的概念。 BASE的定义比ACID还要模糊，一个简单、易理解、容易记忆的BASE理论：BASE（英文含义为碱）是反ACID（英文含义为酸）的概念。可以简单地这么理解：


关系型数据库	非关系型数据库
事务	无事务
ACID	BASE
SQL	NOSQL

ACID中的原子性和隔离性比较好理解。一致性概念实际上很模糊，而且看起来跟数据库关系不大。书中一段引用非常经典：

Joe Hellerstein指出，在 Härder 与 Reuter 的论文中，“ACID 中的 C” 是被 “扔进去凑缩写单词的”，而且那时候大家都不怎么在乎一致性

而隔离性的定义非常模糊，可串行话的工业化的实践也停滞不前。事务的隔离性可谓“一团浆糊”，但是可串行化是灵丹妙药为什么没人用呢？参考这篇文章事务的历史与SSI

非可串行化隔离级别的异常现象，一般都需要在高并发情况下才会发生，低并发数据库不太会出现问题；
当异常现象真的发生的时候，有些应用可能没发现异常现象或检查到异常但对他们不重要；
有可能数据异常了，但应用只是返回报错，并进入数据异常处理程序；
成本过高。不仅是数据库串行化隔离级别开发成本高，应用对可串行化也需要适应成本。光是理解这部分复杂的理论就不是一件容易的事；
高级别的隔离会丢失一些性能。大量的改造工作可能是吃力不讨好的，应用需要在“高并发”和“无异常现象”间做抉择；
业务基于机制开发，而不是规则开发。业务多少有点适应弱隔离级别的异常现象，特别是RC 。

总结为一句话的话：又不是不能用！

悲观和乐观事务模型
#

两阶段锁是一种所谓的悲观并发控制机制（pessimistic）：它是基于这样的原则：如果有事情可能出错（如另一个事务持有锁），最好等到情况安全后再做事情。这就像互斥，用于保护多线程编程中的数据结构。从某种意义上说，串行执行可以称为悲观到了极致：在事务持续期间，每个事务对整个数据库（或数据库的一个分区）具有排它锁，作为对悲观的补偿，我们让每笔事务执行得非常快，所以只需要短时间持有“锁”。相比之下，串行化快照隔离是一种乐观（optimistic）的并发控制技术。在这种情况下，乐观意味着，如果存在潜在的危险也不阻止事务，而是继续执行事务，希望一切都会好起来。当一个事务想要提交时，数据库检查是否有什么不好的事情发生（即违反隔离原则）；如果是的话，事务将被中止，并且必须重试。只有可串行化的事务才被允许提交。如果存在很多争用（contention，即很多事务试图访问相同的对象），则表现不佳，因为这会导致很大一部分事务需要中止。如果系统已经接近最大吞吐量，来自重试事务的额外负载可能会使性能变差。

ch9 分布式系统
#

时钟
#

时钟在分布式系统中十分关键，它可能会直接影响事务的可见性/隔离性/正确性。实际上准确的读取时间点是没有意义的（从量子理论上看就没有绝对的时间点的概念，实际情况要更复杂）。 Spanner 中的 Google TrueTime API 地报告了本地时钟的置信区间。置信区间会报告一个极短且可信的时间范围，而不是一个时间点。例如，如果你有两个置信区间，每个置信区间包含最早和最晚可能的时间戳（$A = [A_{earliest}, A_{latest}]$，$B=[B_{earliest}, B_{latest}]$），这两个区间不重叠（即：$A_{earliest} <A_{latest} <B_{earliest} <B_{latest}$）的话，那么 B 肯定发生在 A 之后 —— 这是毫无疑问的。只有当区间重叠时，我们才不确定 A 和 B 发生的顺序。为了确保事务时间戳反映因果关系，在提交读写事务之前，Spanner 在提交读写事务时，会故意等待置信区间长度的时间。Spanner 为了保持尽可能小的时钟不确定性，Google 在每个数据中心都部署了一个 GPS 接收器或原子钟，这允许时钟同步到大约 7 毫秒以内。 **逻辑时钟（logic clock）**是基于递增计数器而不是振荡石英晶体。逻辑时钟仅测量事件的相对顺序。

实时可能不存在。响应优先级高于一切。对于大多数服务器端数据处理系统来说，实时保证是不经济或不合适的。因此，这些系统必须承受在非实时环境中运行的暂停和时钟不稳定性。

ch10 一致性与共识
#

我们假设的所有问题都可能发生：网络中的数据包可能会丢失、重新排序、重复推送或任意延迟；时钟只是尽其所能地近似；且节点可以暂停（例如，由于垃圾收集）或随时崩溃。

CAP
#

CAP 定理的正式定义仅限于很狭隘的范围，它只考虑了一个一致性模型（即线性一致性）和一种故障（网络分区，或活跃但彼此断开的节点）。它没有讨论任何关于网络延迟，死亡节点或其他权衡的事。因此，尽管 CAP 在历史上有一些影响力，但对于设计系统而言并没有实际价值。

分布式事务和共识
#

迄今为止所讨论的所有共识协议，在内部都以某种形式使用一个领导者，但它们并不能保证领导者是独一无二的。相反，它们可以做出更弱的保证：协议定义了一个纪元编号（epoch number，在 Paxos 中被称为投票编号，即 ballot number，在视图戳复制中被称为视图编号，即 view number，以及在 Raft 中被为任期号码，即 term number），并确保在每个时代中，领导者都是唯一的。每次当现任领导被认为挂掉的时候，节点间就会开始一场投票，以选出一个新领导。这次选举被赋予一个递增的纪元编号，因此纪元编号是全序且单调递增的。如果两个不同的时代的领导者之间出现冲突（也许是因为前任领导者实际上并未死亡），那么带有更高纪元编号的领导说了算。设计能健壮应对不可靠网络的算法仍然是一个开放的研究问题。

ch11 批处理
#

服务（在线系统）服务等待客户的请求或指令到达。每收到一个，服务会试图尽快处理它，并发回一个响应。响应时间通常是服务性能的主要衡量指标，可用性通常非常重要（如果客户端无法访问服务，用户可能会收到错误消息）。
批处理系统（离线系统）一个批处理系统有大量的输入数据，跑一个作业（job）来处理它，并生成一些输出数据，这往往需要一段时间（从几分钟到几天），所以通常不会有用户等待作业完成。相反，批量作业通常会定期运行（例如，每天一次）。批处理作业的主要性能衡量标准通常是吞吐量（处理特定大小的输入所需的时间）。本章中讨论的就是批处理。
流处理系统（准实时系统）流处理介于在线和离线（批处理）之间，所以有时候被称为准实时（near-real-time）或准在线（nearline）处理。像批处理系统一样，流处理消费输入并产生输出（并不需要响应请求）。但是，流式作业在事件发生后不久就会对事件进行操作，而批处理作业则需等待固定的一组输入数据。这种差异使流处理系统比起批处理系统具有更低的延迟。

2004 年发布的批处理算法 Map-Reduce（可能被过分热情地）被称为 “造就 Google 大规模可伸缩性的算法”，MapReduce 是一个相当低级别的编程模型。

MapReduce和分布式文件系统
#

与关系数据库的查询优化器相比，即使 Unix 工具非常简单，但仍然非常有用。 Unix 工具的最大局限在于它们只能在一台机器上运行 —— 而 Hadoop 这样的工具即应运而生 MapReduce 有点像 Unix 工具，但分布在数千台机器上。像 Unix 工具一样，它相当简单粗暴，但令人惊异地管用。 MapReduce 作业在分布式文件系统上读写文件。在 Hadoop 的 MapReduce 实现中，该文件系统被称为 HDFS（Hadoop 分布式文件系统），一个 Google 文件系统（GFS）的开源实现。除 HDFS 外，还有各种其他分布式文件系统，如 GlusterFS 和 Quantcast File System（QFS）。诸如 Amazon S3、Azure Blob 存储和 OpenStack Swift等对象存储服务在很多方面都是相似的

要创建 MapReduce 作业，你需要实现两个回调函数，Mapper 和 Reducer，其行为如下：

Mapper Mapper 会在每条输入记录上调用一次，其工作是从输入记录中提取键值。对于每个输入，它可以生成任意数量的键值对（包括 None）。它不会保留从一个输入记录到下一个记录的任何状态，因此每个记录都是独立处理的。
Reducer MapReduce 框架拉取由 Mapper 生成的键值对，收集属于同一个键的所有值，并在这组值上迭代调用 Reducer。Reducer 可以产生输出记录（例如相同 URL 的出现次数）。

使用 MapReduce 编程模型，能将计算的物理网络通信层面（从正确的机器获取数据）从应用逻辑中剥离出来（获取数据后执行处理）。这种分离与数据库的典型用法形成了鲜明对比，从数据库中获取数据的请求经常出现在应用代码内部。由于 MapReduce 处理了所有的网络通信，因此它也避免了让应用代码去担心部分故障，例如另一个节点的崩溃：MapReduce 在不影响应用逻辑的情况下能透明地重试失败的任务。 “把相关数据放在一起” 的另一种常见模式是，按某个键对记录分组（如 SQL 中的 GROUP BY 子句）。使用 MapReduce 实现这种分组操作的最简单方法是设置 Mapper，以便它们生成的键值对使用所需的分组键。然后分区和排序过程将所有具有相同分区键的记录导向同一个 Reducer。

Hadoop与分布式数据库的对比
#

正如我们所看到的，Hadoop 有点像 Unix 的分布式版本，其中 HDFS 是文件系统，而 MapReduce 是 Unix 进程的怪异实现（总是在 Map 阶段和 Reduce 阶段运行 sort 工具）。我们了解了如何在这些原语的基础上实现各种连接和分组操作。

当 MapReduce 论文发表时，它从某种意义上来说 —— 并不新鲜。我们在前几节中讨论的所有处理和并行连接算法已经在十多年前所谓的大规模并行处理（MPP，massively parallel processing）数据库中实现了。比如 Gamma database machine、Teradata 和 Tandem NonStop SQL 就是这方面的先驱。

最大的区别是，MPP 数据库专注于在一组机器上并行执行分析 SQL 查询，而 MapReduce 和分布式文件系统的组合则更像是一个可以运行任意程序的通用操作系统。

处理模型的多样性
#

只有两种处理模型，SQL 和 MapReduce，还不够，需要更多不同的模型！而且由于 Hadoop 平台的开放性，实施一整套方法是可行的，而这在单体 MPP 数据库的范畴内是不可能的。传统上，MPP 数据库满足了商业智能分析和业务报表的需求，但这只是许多使用批处理的领域之一。自 MapReduce 开始流行的这几年以来，分布式批处理的执行引擎已经很成熟了。

ch12 流处理
#

略。

事件溯源
#

事件溯源是一种强大的数据建模技术：从应用的角度来看，将用户的行为记录为不可变的事件更有意义，而不是在可变数据库中记录这些行为的影响。事件溯源类似于编年史（chronicle）数据模型与变更数据捕获类似，事件溯源涉及到将所有对应用状态的变更存储为变更事件日志。使用事件溯源的应用需要拉取事件日志（表示写系统的数据），并将其转换为适合向用户显示的应用状态。从事件日志中派生出当前状态。

ch13 数据系统的未来
#

lambda架构
#

如果批处理用于重新处理历史数据，而流处理用于处理最近的更新，那么如何将这两者结合起来？Lambda 架构是这方面的一个建议 Lambda 架构的核心思想是通过将不可变事件附加到不断增长的数据集来记录传入数据，这类似于事件溯源。在 Lambda 方法中，流处理器消耗事件并快速生成对视图的近似更新；批处理器稍后将使用同一组事件并生成衍生视图的更正版本。

Unix 发展出的管道和文件只是字节序列，而数据库则发展出了 SQL 和事务。哪种方法更好？当然这取决于你想要的是什么。Unix 是 “简单的”，因为它是对硬件资源相当薄的包装；关系数据库是 “更简单” 的，因为一个简短的声明性查询可以利用很多强大的基础设施（查询优化、索引、连接方法、并发控制、复制等），而不需要查询的作者理解其实现细节。我将 NoSQL 运动解释为，希望将类 Unix 的低级别抽象方法应用于分布式 OLTP 数据存储的领域。

应用代码和状态的分离
#

理论上，数据库可以是任意应用代码的部署环境，就如同操作系统一样。然而实践中它们对这一目标适配的很差。它们不满足现代应用开发的要求，例如依赖和软件包管理、版本控制、滚动升级、可演化性、监控、指标、对网络服务的调用以及与外部系统的集成。我认为让系统的某些部分专门用于持久数据存储并让其他部分专门运行应用程序代码是有意义的。这两者可以在保持独立的同时互动。趋势是将无状态应用程序逻辑与状态管理（数据库）分开：不将应用程序逻辑放入数据库中，也不将持久状态置于应用程序中。

我断言在大多数应用中，完整性比及时性重要得多。违反及时性可能令人困惑与讨厌，但违反完整性的结果可能是灾难性的。

交给算法所带来的问题
#

1.偏见与其实：例如在种族隔离地区中，一个人的邮政编码，甚至是他们的 IP 地址，都是很强的种族指示物。这样的话，相信一种算法可以以某种方式将有偏见的数据作为输入，并产生公平和公正的输出似乎是很荒谬的。然而这种观点似乎常常潜伏在数据驱动型决策的支持者中，这种态度被讽刺为 “在处理偏差上，机器学习与洗钱类似”（machine learning is like money laundering for bias）。预测性分析系统只是基于过去进行推断；如果过去是歧视性的，它们就会将这种歧视归纳为规律 2.责任与问责：自动决策引发了关于责任与问责的问题。如果一个人犯了错误，他可以被追责，受决定影响的人可以申诉。算法也会犯错误，但是如果它们出错，谁来负责？ 3.隐私与监视：让我们做一个思想实验，尝试用 监视（surveillance） 一词替换 数据（data），再看看常见的短语是不是听起来还那么漂亮。比如：“在我们的监视驱动的组织中，我们收集实时监视流并将它们存储在我们的监视仓库中。我们的监视科学家使用高级分析和监视处理来获得新的见解。”

盲目相信数据决策至高无上，这不仅仅是一种妄想，而是有切实危险的。随着数据驱动的决策变得越来越普遍，我们需要弄清楚，如何使算法更负责任且更加透明，如何避免加强现有的偏见，以及如何在它们不可避免地出错时加以修复。用户几乎不知道他们提供给我们的是什么数据，哪些数据被放进了数据库，数据又是怎样被保留与处理的 —— 大多数隐私政策都是模棱两可的，忽悠用户而不敢打开天窗说亮话。如果用户不了解他们的数据会发生什么，就无法给出任何有意义的同意。对于不同意监视的用户，唯一真正管用的备选项，就是简单地不使用服务。但这个选择也不是真正自由的：如果一项服务如此受欢迎，以至于 “被大多数人认为是基本社会参与的必要条件”，那么指望人们选择退出这项服务是不合理的 —— 使用它事实上是强制性的。

总结
#

由于软件和数据对世界产生了如此巨大的影响，我们工程师们必须牢记，我们有责任为我们想要的那种世界而努力：一个尊重人，尊重人性的世界。我希望我们能够一起为实现这一目标而努力。

PostgreSQL CLOG文件及其从库同步解析

Tue, 03 Sep 2024 00:00:00 +0000

放眼所有关系型数据库，PostgreSQL的clog也是很特殊的日志。CLOG的存在跟PG的MVCC机制不无关系。一些事务ID、clog的基础知识本篇不会涉及，感谢兴趣的可参考clog和hintbits。本篇主要讲clog文件的构成、手工定位事务状态、clog的wal日志同步机制，以进一步理解PostgreSQL的clog。

clog segment
#

clog目录
#

为了区别普通日志，PG 10对clog和wal的目录进行了重命名¹：

pg9.6	pg10
pg_clog	pg_xact
pg_xlog	pg_wal

别搞错了，我也有段时间被pg_xlog和pg_xact给困扰···

clog segment name
#

clog也是由slru管理，clog文件命名也在slru.c中

#define SlruFileName(ctl, path, seg) \
	snprintf(path, MAXPGPATH, "%s/%04X", (ctl)->Dir, seg)

%04X表示十六进制（X），宽度为4、不足前面补0（04）。 clog文件名示例如下：

[pg_xact]$ ll
-rw------- 1 postgres postgres 262144 Aug 15 16:29 03C0
-rw------- 1 postgres postgres 262144 Aug 19 23:04 03C1
...

TransactionID与clog位置的转换
#

clog只存储事务ID的状态，不存事务ID本身。通过TransactionID本身是可以直接定位到clog文件及文件中的位置的。在此之前我们需要了解一些基础知识。

CLOG保存的事务状态
#

事务的状态只有4种：

typedef int XidStatus;

#define TRANSACTION_STATUS_IN_PROGRESS		0x00
#define TRANSACTION_STATUS_COMMITTED		0x01
#define TRANSACTION_STATUS_ABORTED		0x02
#define TRANSACTION_STATUS_SUB_COMMITTED	0x03

事务状态只有进行中、已提交、回滚、子事务已提交。注意事务id没有“未开始”这个状态，只要数据库中分配了事务ID，那么这个事务肯定是已经开始了。相反，库中还没有分配的事务ID（实际是少许，参考下面的extend clog章节），在clog中对应in_progress状态。 4个事务状态实际上2个bit位即可存储。那么1个字节（8 bits）可存储4个事务状态，1个页（8k）能放8KB*4=32768个事务状态。这些都在源码中定义了：

 * Defines for CLOG page sizes. A page is the same BLCKSZ as is used
 * everywhere else in Postgres.
//clog页大小=BLCKSZ=8k（默认） 
#define CLOG_BITS_PER_XACT	2 								 //一个事务状态占2个bit
#define CLOG_XACTS_PER_BYTE 4 								 //1个字节可存放4个事务状态
#define CLOG_XACTS_PER_PAGE (BLCKSZ * CLOG_XACTS_PER_BYTE) //1个页可存放32768个事务状态，8KB*4=32768
#define CLOG_XACT_BITMASK ((1 << CLOG_BITS_PER_XACT) - 1) //事务状态的bitmask位=((1<<2)-1)=3，用二进制表达为11

#define SLRU_PAGES_PER_SEGMENT	32 //1个segment有32个pages

汇总：

1个clog segment有32个page
1个clog page有8k（一般）
1个bytes有4个事务状态
1个事务状态占2 bit

clog segment/page/bytes的转换
#

事务id对应在哪个CLOG段不太好找，它藏在注释里：

 * Note: because TransactionIds are 32 bits and wrap around at 0xFFFFFFFF,
 * CLOG page numbering also wraps around at 0xFFFFFFFF/CLOG_XACTS_PER_PAGE,
 * and CLOG segment numbering at
 * 0xFFFFFFFF/CLOG_XACTS_PER_PAGE/SLRU_PAGES_PER_SEGMENT
//segment number=xid/CLOG_XACTS_PER_PAGE/SLRU_PAGES_PER_SEGMENT=xid/32768/32 //事务id对应在哪个CLOG段，xid/32768/32,需要转成16进制

事务id对应对应到page、byte等比较清晰²：

#define TransactionIdToPage(xid)	((xid) / (TransactionId) CLOG_XACTS_PER_PAGE) //事务id对应在哪个CLOG page,xid/32768
#define TransactionIdToPgIndex(xid) ((xid) % (TransactionId) CLOG_XACTS_PER_PAGE) //事务id对应在上面page中的偏移量,xid%32768
#define TransactionIdToByte(xid)	(TransactionIdToPgIndex(xid) / CLOG_XACTS_PER_BYTE) //事务id对应在page中的第几个字节,(xid%32768)/4
#define TransactionIdToBIndex(xid)	((xid) % (TransactionId) CLOG_XACTS_PER_BYTE)		//事务id对应在上面字节中的哪个bit index（注意是bit index不是bit本身）,xid%4

一般来说（8k的BLCKSZ），1个CLOG段有32个页面；1个CLOG段有32*8k字节，即CLOG文件大小固定256K；1个CLOG段可存放4*32*8k个事务状态。

[pg_xact]$ ll # 256k的clog segment
-rw------- 1 postgres postgres 262144 Aug 15 16:29 03C0
-rw------- 1 postgres postgres 262144 Aug 19 23:04 03C1
...

clog bit位的转换
#

设置clog bit和获取clog bit的函数（对应TransactionIdSetStatusBit和TransactionIdGetStatus）都有以下代码以获取事务id对应到clog中的哪两位bit：

	int			bshift = TransactionIdToBIndex(xid) * CLOG_BITS_PER_XACT;
	char	 *byteptr;
...
	byteptr = XactCtl->shared->page_buffer[slotno] + byteno;
	curval = (*byteptr >> bshift) & CLOG_XACT_BITMASK;

bshift表示右移的位置，其中TransactionIdToBIndex=xid%4，CLOG_BITS_PER_XACT=2，CLOG_XACT_BITMASK=3（二进制为11）。 clog bit获取的关键代码curval = (*byteptr >> bshift) & CLOG_XACT_BITMASK分两段来看：

*byteptr >> bshift表示指针右移0、2、4、6位
& CLOG_XACT_BITMASK其实就是右移后取后两位（00&11=00、01&11=01、10&11=10、11&11=11）

so，计算在一个byte中事务id状态的位置：

xid%4=0时，取第7、8位
xid%4=1时，取第5、6位
xid%4=2时，取第3、4位
xid%4=3时，取第1、2位

注意，事务id状态在byte中的bit位是反着取的，不是正着顺序取。byte、page位这些是顺序递增的取的。

手动计算事务id在clog文件中的位置
#

如果我们要手工通过hexdump定位CLOG中的事务，需要计算出三个元素<CLOG的段号、段中的偏移量in bytes、byte上的偏移量in bitindex>。（这里参考了《PostgreSQL数据库内核分析》的说法，不过有一些区别³）

计算之前还需要了解：

clog段文件号是16进制的
hexdump是16进制的，每行存放16个字节，即每行存放16*CLOG_XACTS_PER_BYTE=16*4=64个事务状态
hexdump -s xxx是以byte为单位

下面sql可以计算transactionid对应clog中的位置：

--CLOG的段号
--%4294967296代表事务id回卷，/(8192*4*32)代表一个段文件能包含的最大事务数，to_hex转为文件名的16进制，lpad左补全4位
select lpad(upper(to_hex(txid_current()%4294967296/(8192*4*32))),4,'0') as clog_segmentno;

--段中的偏移量in bytes 
--%4294967296代表事务id回卷，%(8192*32*4)取余下的事务id，/4计算成byte单位
select txid_current()%4294967296%(8192*32*4)/4 as in_clog_offset_bytes;

--byte上的偏移量in bitindex
--%4294967296代表事务id回卷，%4取byte中的bitindex
select txid_current()%4294967296%4 as in_byte_offset_bitindex;


--或者一条sql
select lpad(upper(to_hex(txid_current()%4294967296/(8192*4*32))),4,'0') as clog_segmentno,txid_current()%4294967296%(8192*32*4)/4 as in_clog_offset_bytes,txid_current()%4294967296%4 as in_byte_offset_bitindex;

实操模拟计算一个事务id在clog中的状态

begin;
 select lpad(upper(to_hex(txid_current()%4294967296/(8192*4*32))),4,'0') as clog_segmentno,txid_current()%4294967296%(8192*32*4)/4 as in_clog_offset_bytes,txid_current()%4294967296%4 as in_byte_offset_bitindex;
 clog_segmentno | in_clog_offset_bytes | in_byte_offset_bitindex 
----------------+----------------------+-------------------------
 0002 | 63196 | 3
rollback;
checkpoint; 

rollback把事务回滚，主要是方便观察，因为大部分事务都是提交的。 checkpoint是未来保证clog page刷脏，不然clog page在clog buffer中还没写到clog segment文件。

cd pg_xact/
 hexdump -C 0002 -s 63196 -n 1 -v
0000f6dc 95 |.|
0000f6dd

--十六进制转二进制
> select 'x96'::bit(8);
 bit 
----------
 10010110

xid%4=3时，取第1、2位，所以这个回滚的事务的bit位取10，10代表TRANSACTION_STATUS_ABORTED

为什么clog中一般有很多55和U？
#

一般的业务事务库clog文件，直接hexdump的话结果就像下面这样：

hexdump -C 0001 -v|head -10
00000000 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 |UUUUUUUUUUUUUUUU|
00000010 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 |UUUUUUUUUUUUUUUU|
00000020 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 |UUUUUUUUUUUUUUUU|
00000030 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 |UUUUUUUUUUUUUUUU|
00000040 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 |UUUUUUUUUUUUUUUU|
00000050 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 |UUUUUUUUUUUUUUUU|
00000060 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 |UUUUUUUUUUUUUUUU|
00000070 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 |UUUUUUUUUUUUUUUU|
00000080 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 |UUUUUUUUUUUUUUUU|
00000090 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 |UUUUUUUUUUUUUUUU|

因为事务提交的状态=01=TRANSACTION_STATUS_COMMITTED，一个byte中4个连续的事务都是提交的，那么就是01010101。

二进制为01010101，十六进制为55
十六进制55在ASCII中为U，所以在肉眼看CLOG文件一般可以看到很多U
偶尔有些数组不是55或U，因为生产环境中偶尔有些事务没有完成或者使用了子事务。子事务在clog中的提交状态是x03。

shared clog buffer
#

clog shared buffers的个数很容易理解：

/*
 * Number of shared CLOG buffers.
 *
 * On larger multi-processor systems, it is possible to have many CLOG page
 * requests in flight at one time which could lead to disk access for CLOG
 * page if the required page is not found in memory. Testing revealed that we
 * can get the best performance by having 128 CLOG buffers, more than that it
 * doesn't improve performance.
 *
 * Unconditionally keeping the number of CLOG buffers to 128 did not seem like
 * a good idea, because it would increase the minimum amount of shared memory
 * required to start, which could be a problem for people running very small
 * configurations. The following formula seems to represent a reasonable
 * compromise: people with very low values for shared_buffers will get fewer
 * CLOG buffers as well, and everyone else will get 128.
 */
Size
CLOGShmemBuffers(void)
{
	return Min(128, Max(4, NBuffers / 512));
}

翻译：经过测试128个clog buffers性能是最好的，再多也提升不了性能。但是由于有些库的配置实在是太小了，128个clog buffers显得有点大，所以取shared buffers个数的1/512。也就是说： clog buffers的个数=1/512 shared buffer，最小是4，最大是128。注意这里都是buffer的个数，不是大小！那么单个buffer有多大呢？ clog buffer是slru管理的，slru每个page都是8k：

A page is the same BLCKSZ as is used everywhere

我们可以从clog slru初始化的角度窥探shared clog buffer的大小：

/*
 * Initialization of shared memory for CLOG
 */
Size
CLOGShmemSize(void)
{
	return SimpleLruShmemSize(CLOGShmemBuffers(), CLOG_LSNS_PER_PAGE);
}

传入的CLOGShmemBuffers()是4~128，传入的CLOG_LSNS_PER_PAGE=1024 byte（8k page时）。 SimpleLruShmemSize初始化slru shmem：

Size
SimpleLruShmemSize(int nslots, int nlsns)
{
	Size		sz;

	/* we assume nslots isn't so large as to risk overflow */
	sz = MAXALIGN(sizeof(SlruSharedData));
	sz += MAXALIGN(nslots * sizeof(char *));	/* page_buffer[] */
	sz += MAXALIGN(nslots * sizeof(SlruPageStatus));	/* page_status[] */
	sz += MAXALIGN(nslots * sizeof(bool));	/* page_dirty[] */
	sz += MAXALIGN(nslots * sizeof(int));	/* page_number[] */
	sz += MAXALIGN(nslots * sizeof(int));	/* page_lru_count[] */
	sz += MAXALIGN(nslots * sizeof(LWLockPadded));	/* buffer_locks[] */

	if (nlsns > 0)
		sz += MAXALIGN(nslots * nlsns * sizeof(XLogRecPtr));	/* group_lsn[] */

	return BUFFERALIGN(sz) + BLCKSZ * nslots;
}

slrus用一些数组保存slru的元数据和控制信息，sz大小都是数据类型*buffer个数，这些大致估算都不是特别不大。主要初始化的内存还是BLCKSZ * nslots，也就是8k * (4~128)=(32k~1M)大小。所以可以粗略的认为，shared clog buffer的大小为1M左右。

CLOG的wal：类型、写入和redo
#

写clog的时候会写clog的wal日志吗？如果写了那不是clog丢了也可以通过wal日志再次应用就应该找回了事务状态？我们带着问题来看clog写wal和redo的源码。

extend clog
#

ZeroCLOGPage会写wal，ZeroCLOGPage(pageno, true)实际上仅由ExtendCLOG调用：

/*
 * Make sure that CLOG has room for a newly-allocated XID.
 *
 * NB: this is called while holding XidGenLock. We want it to be very fast
 * most of the time; even when it's not so fast, no actual I/O need happen
 * unless we're forced to write out a dirty clog or xlog page to make room
 * in shared memory.
 */
void
ExtendCLOG(TransactionId newestXact)
{
	int			pageno;

	/*
	 * No work except at first XID of a page. But beware: just after
	 * wraparound, the first XID of page zero is FirstNormalTransactionId.
	 */
	if (TransactionIdToPgIndex(newestXact) != 0 &&
		!TransactionIdEquals(newestXact, FirstNormalTransactionId))
		return;

	pageno = TransactionIdToPage(newestXact); //由TransactionId换算的clog page号

	LWLockAcquire(XactSLRULock, LW_EXCLUSIVE);

	/* Zero the page and make an XLOG entry about it */
	ZeroCLOGPage(pageno, true);

	LWLockRelease(XactSLRULock);
}

ZeroCLOGPage主要调用WriteZeroPageXlogRec：

/*
 * Write a ZEROPAGE xlog record
 */
static void
WriteZeroPageXlogRec(int pageno)
{
	XLogBeginInsert();
	XLogRegisterData((char *) (&pageno), sizeof(int));
	(void) XLogInsert(RM_CLOG_ID, CLOG_ZEROPAGE);
}

WriteZeroPageXlogRec就是在写wal record了，写入的类型是“RM_CLOG_ID, CLOG_ZEROPAGE”。通过waldump可以查看到CLOG_ZEROPAGE，它的占比一般都是非常少的：

pg_waldump -z 000000010000056B00000018 --stat=record
Type N (%) Record size (%) FPI size (%) Combined size (%)
---- - --- ----------- --- -------- --- ------------- ---
...
CLOG/ZEROPAGE 1 ( 0.00) 30 ( 0.00) 0 ( 0.00) 30 ( 0.00)
...

extend clog page时都是以page为单位，实际上在clog segment的末尾可以很容易看到00

hexdump 03C2
0000000 5555 5555 5555 5555 5555 5555 5555 5555
*
001bb30 5555 5555 0055 0000 0000 0000 0000 0000
001bb40 0000 0000 0000 0000 0000 0000 0000 0000 
* ##clog文件后面的都是0
001c000

truncate clog
#

除了extend clog外，还有truncate clog，truncate clog会在vacuum期间被调用，调用时会写truncate clog的wal record，并将wal record flush到磁盘

/*
 * Remove all CLOG segments before the one holding the passed transaction ID
 *
 * Before removing any CLOG data, we must flush XLOG to disk, to ensure
 * that any recently-emitted FREEZE_PAGE records have reached disk; otherwise
 * a crash and restart might leave us with some unfrozen tuples referencing
 * removed CLOG data. We choose to emit a special TRUNCATE XLOG record too.
 * Replaying the deletion from XLOG is not critical, since the files could
 * just as well be removed later, but doing so prevents a long-running hot
 * standby server from acquiring an unreasonably bloated CLOG directory.
 *
 * Since CLOG segments hold a large number of transactions, the opportunity to
 * actually remove a segment is fairly rare, and so it seems best not to do
 * the XLOG flush unless we have confirmed that there is a removable segment.
 */
void
TruncateCLOG(TransactionId oldestXact, Oid oldestxid_datoid)
{
	int			cutoffPage;

	/*
	 * The cutoff point is the start of the segment containing oldestXact. We
	 * pass the *page* containing oldestXact to SimpleLruTruncate.
	 */
	//写入wal的是clog的位置，clog位置是oldestXact转换出来的clog page号
	cutoffPage = TransactionIdToPage(oldestXact); 

.....
	/*
	 * Write XLOG record and flush XLOG to disk. We record the oldest xid
	 * we're keeping information about here so we can ensure that it's always
	 * ahead of clog truncation in case we crash, and so a standby finds out
	 * the new valid xid before the next checkpoint.
	 */
	// WriteTruncateXlogRec会写对应的wal record并将其写到磁盘上
	WriteTruncateXlogRec(cutoffPage, oldestXact, oldestxid_datoid);
	
	//wal写完后，才真正执行truncate clog段
	/* Now we can remove the old CLOG segment(s) */
	SimpleLruTruncate(XactCtl, cutoffPage);
}

WriteTruncateXlogRec就是写RMGR为RM_CLOG_ID，info为 CLOG_TRUNCAT的wal record：

/*
 * Write a TRUNCATE xlog record
 *
 * We must flush the xlog record to disk before returning --- see notes
 * in TruncateCLOG().
 */
static void
WriteTruncateXlogRec(int pageno, TransactionId oldestXact, Oid oldestXactDb)
{
	XLogRecPtr	recptr;
	xl_clog_truncate xlrec;

	xlrec.pageno = pageno;
	xlrec.oldestXact = oldestXact;
	xlrec.oldestXactDb = oldestXactDb;

	XLogBeginInsert();
	XLogRegisterData((char *) (&xlrec), sizeof(xl_clog_truncate));
	recptr = XLogInsert(RM_CLOG_ID, CLOG_TRUNCATE);
	XLogFlush(recptr);
}

当制造了clog wal record后，还需要redo恢复的routine：

/*
 * CLOG resource manager's routines
 */
void
clog_redo(XLogReaderState *record)
{
...
	//redo info类型是CLOG_ZEROPAGE时，将读取出来的redo信息放在内存，然后写到CLOG page文件中
	if (info == CLOG_ZEROPAGE)
	{
		int			pageno;
		int			slotno;

		memcpy(&pageno, XLogRecGetData(record), sizeof(int));

		LWLockAcquire(XactSLRULock, LW_EXCLUSIVE);

		slotno = ZeroCLOGPage(pageno, false);
		SimpleLruWritePage(XactCtl, slotno); 
		Assert(!XactCtl->shared->page_dirty[slotno]);

		LWLockRelease(XactSLRULock);
	}
	//redo info类型是CLOG_TRUNCATE时，将读取出来的redo信息放在内存中，确认page是可删除的（如果不可用需要write page），然后truncate segment
	else if (info == CLOG_TRUNCATE)
	{
		xl_clog_truncate xlrec;

		memcpy(&xlrec, XLogRecGetData(record), sizeof(xl_clog_truncate));

		/*
		 * During XLOG replay, latest_page_number isn't set up yet; insert a
		 * suitable value to bypass the sanity test in SimpleLruTruncate.
		 */
		XactCtl->shared->latest_page_number = xlrec.pageno;

		AdvanceOldestClogXid(xlrec.oldestXact);

		SimpleLruTruncate(XactCtl, xlrec.pageno);
	}
	else
		elog(PANIC, "clog_redo: unknown op code %u", info);
}

clog redo routine所做的事：

redo info类型是CLOG_ZEROPAGE时，找到一个合适的slot（如果没有需要换出），根据读取出来的redo信息（实际上是clog page号）进行一些是否可写的判断，可以再讲page write到clog文件
redo info类型是CLOG_TRUNCATE时，根据读取出来的redo信息（实际上是clog page号），确认page是可删除的（如果不可用需要write page），然后truncate clog segment

clog的同步小结
#

CLOG只有两种wal日志，两种都不包含事务状态信息，且仅仅是在extend clog page和truncate clog segment时触发，写入的wal record只是一个clog page编号。 CLOG的wal日志RMGR类型只有一种RM_CLOG_ID，这种类型只有两种信息：CLOG_ZEROPAGE、CLOG_TRUNCATE。

/* XLOG stuff */
#define CLOG_ZEROPAGE 0x00
#define CLOG_TRUNCATE 0x10

clog wal同步总结： 从库本质上没有在同步clog信息，只是同步了一些clog文件的扩容和删除信息。

但是，从库的clog文件中明明是有状态信息的，从库明显也需要这部分信息以提供可见性检查。clog中的事务状态是怎么同步的呢？

事务id的wal：类型、写入和redo
#

rmgr=clog的wal不包含事务状态，难道从库不同步clog事务信息？并不是，wal日志中有事务ID的状态信息，clog也会被更新：

--回滚一个事务，提交一个事务
> begin;
BEGIN
> select txid_current();
 txid_current 
--------------
 1817254
(1 row)

> rollback;
ROLLBACK
> begin;
BEGIN
> select txid_current();
 txid_current 
--------------
 1817258
(1 row)

> commit;
COMMIT
> checkpoint;
CHECKPOINT

--pg_waldump查看日志中的事务ID状态
[datalzl/pg_wal]$ pg_waldump ../../pg_wal/000000010000007300000008|grep -E "1817254|1817258"
rmgr: Transaction len (rec/tot): 34/ 34, tx: 1817254, lsn: 73/400ED210, prev 73/400ED1E0, desc: ABORT 2024-08-01 14:41:26.017612 CST
rmgr: Transaction len (rec/tot): 46/ 46, tx: 1817258, lsn: 73/400EEB08, prev 73/400EEAD8, desc: COMMIT 2024-08-01 14:41:37.042545 CST
pg_waldump: fatal: error in WAL record at 73/400F7C78: invalid record length at 73/400F7F88: wanted 24, got 0

在wal中有记录事务ID（1817254，1817258）的状态，并且分别记录为ABORT、COMMIT ；rmgr为Transaction。事务ID状态在wal日志中，但是pg会写到从库的clog里吗？很明显，我们需要找到这部分的redo信息。按照刚才的经验，clog_redo代表rmgr=clog的wal redo源码，那么源码搜索_redo应该能找到rmgr=transactionid的wal redo源码。搜搜，在xact.c中的找到函数xact_redo，其主要调用xact_redo_commit,xact_redo_abort，明显各自对应提交事务和回退事务的wal日志应用逻辑。

void
xact_redo(XLogReaderState *record)
{
	uint8		info = XLogRecGetInfo(record) & XLOG_XACT_OPMASK;

	/* Backup blocks are not used in xact records */
	Assert(!XLogRecHasAnyBlockRefs(record));

	if (info == XLOG_XACT_COMMIT)
	{
	...
		xact_redo_commit(&parsed, XLogRecGetXid(record),
						 record->EndRecPtr, XLogRecGetOrigin(record));
	}
...
	else if (info == XLOG_XACT_ABORT)
	{
	...
		xact_redo_abort(&parsed, XLogRecGetXid(record));
	}
...
	}
	else
		elog(PANIC, "xact_redo: unknown op code %u", info);
}

以commit为例

static void
xact_redo_commit(xl_xact_parsed_commit *parsed,
				 TransactionId xid,
				 XLogRecPtr lsn,
				 RepOriginId origin_id)
{
...

	if (standbyState == STANDBY_DISABLED)
	{
		/*
		 * Mark the transaction committed in pg_xact.
		 */
		TransactionIdCommitTree(xid, parsed->nsubxacts, parsed->subxacts);
	}
	else//standby逻辑
	{
	...
		/*
		 * Mark the transaction committed in pg_xact. We use async commit
		 * protocol during recovery to provide information on database
		 * consistency for when users try to set hint bits. It is important
		 * that we do not set hint bits until the minRecoveryPoint is past
		 * this commit record. This ensures that if we crash we don't see hint
		 * bits set on changes made by transactions that haven't yet
		 * recovered. It's unlikely but it's good to be safe.
		 */
		//在pg_xact中标记事务提交
		TransactionIdAsyncCommitTree(xid, parsed->nsubxacts, parsed->subxacts, lsn);

...
}

看着TransactionIdAsyncCommitTree就是我们要找的写clog的函数。

为了验证wal中事务commit信息的redo逻辑，下面给从库的startup进程打三个断点，然后在源库执行begin;select txid_current();commit;提交一个事务，看看从库的startup进程在做redo的时候是否命中我们想要看到的函数：

(gdb) bt
#0 TransactionIdAsyncCommitTree (xid=xid@entry=1818665, nxids=0, xids=0x0, lsn=lsn@entry=495398394064) at transam.c:274
#1 0x000000000050c139 in xact_redo_commit (parsed=parsed@entry=0x7ffda52c0fc0, xid=1818665, lsn=495398394064, origin_id=<optimized out>) at xact.c:5805
#2 0x000000000050ffa3 in xact_redo (record=0x2b5ff2434038) at xact.c:5962
#3 0x0000000000519ea5 in StartupXLOG () at xlog.c:7411
#4 0x000000000072f301 in StartupProcessMain () at startup.c:204
#5 0x0000000000528701 in AuxiliaryProcessMain (argc=argc@entry=2, argv=argv@entry=0x7ffda52c6ef0) at bootstrap.c:450
#6 0x000000000072c459 in StartChildProcess (type=StartupProcess) at postmaster.c:5494
#7 0x000000000072ec44 in PostmasterMain (argc=argc@entry=3, argv=argv@entry=0x2b5ff242d1c0) at postmaster.c:1407
#8 0x000000000048931f in main (argc=3, argv=0x2b5ff242d1c0) at main.c:210
(gdb) info b
Num Type Disp Enb Address What
1 breakpoint keep y 0x000000000050c060 in xact_redo_commit at xact.c:5753
 breakpoint already hit 43 times
2 breakpoint keep y 0x0000000000508190 in TransactionIdCommitTree at transam.c:262
3 breakpoint keep y 0x00000000005081a0 in TransactionIdAsyncCommitTree at transam.c:274
 breakpoint already hit 1 time

可以命中断点TransactionIdAsyncCommitTree ，并且xid=1818665，也就是刚才在源库提交的事务ID。说明刚才肉眼看的代码逻辑没有问题。 so，standby库的clog事务ID状态由wal rmgr=Transaction来同步

总结
#

clog只存储了事务ID的状态，没有存储事务ID本身
可以通过事务ID手动定位到CLOG文件中的事务状态
rmgr=clog的wal只有扩展和清理clog文件，没有更新事务状态
rmgr=transaction的wal会更新clog的事务状态

references
#

《快速掌握PostgreSQL版本新特性》p24 ↩︎
阎书利 PostgreSQL的CLOG解析 https://www.modb.pro/db/606433 ↩︎
《PostgreSQL数据库内核分析》第7章 p380-390 ↩︎

PostgreSQL案例：planning time超长问题分析

Wed, 21 Aug 2024 00:00:00 +0000

问题分析概述
#

库总是OOM，分析到是执行计划生成有问题，planning time 1秒，planning shared hit 100w。一通分析，定位到是统计信息基表pg_statistic膨胀，由于会话首次SQL执行时的CatCacheMiss，导致backend访问并缓存了pg_statistic过多的死元组数据。应用连接总会启用新会话，多个backend的总内存过大从而导致OOM。

下面是详细分析过程。

问题现象
#

某库反复OOM和重启。经过一通问题排查，发现会话连接数不多，但是每个会话的内存占用比较高，总内存超过内存cg限制导致OOM。初步可以排除以下原因：

不是元数据过多的问题导致。对象过多（一般是分区数太多）会导致会话缓存过多的元数据。这个库的对象不算多
不是sql执行计划问题。排序/hash可能使用过多内存。这个库不是这个场景，sql可以是一个顺序扫描。

在问题分析过程中发现，库里面执行任意一个简单sql执行时间很长，并且 Planning Buffers有约100w

 explain (analyze,buffers,timing) select * from lzlinfo limit 1;
 QUERY PLAN 
--------------------------------------------------------------------------------------------------------------------
 Limit (cost=0.00..1.02 rows=1 width=71) (actual time=0.011..0.012 rows=1 loops=1)
 Buffers: shared hit=1
 -> Seq Scan on lzlinfo (cost=0.00..480.73 rows=473 width=71) (actual time=0.010..0.010 rows=1 loops=1)
 Buffers: shared hit=1
 Planning:
 Buffers: shared hit=1127312 --异常planning shared hit
 Planning Time: 947.038 ms --异常planning time
 Execution Time: 0.035 ms
(8 rows)

再执行一次sql，planning time就正常了。

问题定位过程
#

打印执行计划的stat信息
#

把会话的执行计划各阶段的stat信息打到日志：

set log_parser_stats =on;
set log_planner_stats =on;
set log_executor_stats =on;

然后跑下sql，日志输出如下：

2024-08-13 10:02:33.936 CST,"postgres","lzldb",85532,"[local]",66babe8c.14e1c,13,"idle",2024-08-13 10:01:48 CST,4/713,0,LOG,00000,"PARSER STATISTICS","! system usage stats:
! 0.000046 s user, 0.000046 s system, 0.000091 s elapsed
! [0.001661 s user, 0.001661 s system total]
! 4660 kB max resident size
! 0/0 [0/8] filesystem blocks in/out
! 0/36 [0/996] page faults/reclaims, 0 [0] swaps
! 0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent
! 0/0 [5/0] voluntary/involuntary context switches",,,,,"explain (analyze,buffers) select *,1 from lzlinfo
2024-08-13 10:02:33.938 CST,"postgres","lzldb",85532,"[local]",66babe8c.14e1c,14,"EXPLAIN",2024-08-13 10:01:48 CST,4/713,0,LOG,00000,"PARSE ANALYSIS STATISTICS","! system usage stats:
! 0.001459 s user, 0.000000 s system, 0.001464 s elapsed
! [0.003146 s user, 0.001687 s system total]
! 5972 kB max resident size
! 0/0 [0/8] filesystem blocks in/out
! 0/325 [0/1324] page faults/reclaims, 0 [0] swaps
! 0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent
! 0/0 [5/0] voluntary/involuntary context switches",,,,,"explain (analyze,buffers) select *,1 from lzlinfo
2024-08-13 10:02:33.938 CST,"postgres","lzldb",85532,"[local]",66babe8c.14e1c,15,"EXPLAIN",2024-08-13 10:01:48 CST,4/713,0,LOG,00000,"REWRITER STATISTICS","! system usage stats:
! 0.000001 s user, 0.000000 s system, 0.000001 s elapsed
! [0.003177 s user, 0.001687 s system total]
! 5972 kB max resident size
! 0/0 [0/8] filesystem blocks in/out
! 0/0 [0/1324] page faults/reclaims, 0 [0] swaps
! 0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent
! 0/0 [5/0] voluntary/involuntary context switches",,,,,"explain (analyze,buffers) select *,1 from lzlinfo
2024-08-13 10:02:34.644 CST,"postgres","lzldb",85532,"[local]",66babe8c.14e1c,16,"EXPLAIN",2024-08-13 10:01:48 CST,4/713,0,LOG,00000,"PLANNER STATISTICS","! system usage stats:
! 0.539964 s user, 0.164083 s system, 0.705718 s elapsed
! [0.543248 s user, 0.165770 s system total]
! 745072 kB max resident size --异常点
! 0/0 [0/8] filesystem blocks in/out
! 0/184803 [0/186157] page faults/reclaims, 0 [0] swaps
! 0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent
! 0/1 [5/1] voluntary/involuntary context switches",,,,,"explain (analyze,buffers) select *,1 from lzlinfo
2024-08-13 10:02:34.644 CST,"postgres","lzldb",85532,"[local]",66babe8c.14e1c,17,"EXPLAIN",2024-08-13 10:01:48 CST,4/713,0,LOG,00000,"EXECUTOR STATISTICS","! system usage stats:
! 0.540248 s user, 0.164170 s system, 0.706088 s elapsed
! [0.543532 s user, 0.165857 s system total]
! 745596 kB max resident size
! 0/0 [0/8] filesystem blocks in/out
! 0/184898 [0/186252] page faults/reclaims, 0 [0] swaps
! 0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent
! 0/1 [5/1] voluntary/involuntary context switches",,,,,"explain (analyze,buffers) select *,1 from lzlinfo
"

planner阶段内存使用率暴涨，elapsed time也暴涨。这部分信息可以定位到是整个planning阶段中的planner阶段有问题。其他可用信息不多。

strace追踪
#

strace -p 76419

strace: Process 76419 attached
epoll_wait(4, [{EPOLLIN, {u32=15422552, u64=15422552}}], 1, -1) = 1
recvfrom(9, "Q\0\0\0\262explain (analyze,buffers) s"..., 8192, 0, NULL, NULL) = 179
lseek(5, 0, SEEK_END) = 8192
brk(NULL) = 0xfed000
brk(0x100e000) = 0x100e000
brk(NULL) = 0x100e000
brk(NULL) = 0x100e000
brk(0x1007000) = 0x1007000
brk(NULL) = 0x1007000
mmap(NULL, 270336, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b7806b0c000
open("base/17076/16678", O_RDWR) = 7
lseek(7, 0, SEEK_END) = 0
open("base/17076/46160", O_RDWR) = 12
lseek(12, 0, SEEK_END) = 7667712
open("base/17076/46168", O_RDWR) = 13
lseek(13, 0, SEEK_END) = 188416
open("base/17076/46170", O_RDWR) = 14
lseek(14, 0, SEEK_END) = 188416
mmap(NULL, 528384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b78c1b36000
brk(NULL) = 0x1007000
brk(0x102c000) = 0x102c000
brk(NULL) = 0x102c000
brk(NULL) = 0x102c000
brk(0x1025000) = 0x1025000
brk(NULL) = 0x1025000
lseek(12, 0, SEEK_END) = 7667712
open("pg_stat_tmp/pgss_query_texts.stat", O_RDWR|O_CREAT, 0600) = 15
pwrite64(15, "explain (analyze,buffers) select"..., 172, 93934) = 172
pwrite64(15, "\0", 1, 94106) = 1
close(15) = 0
sendto(8, "\2\0\0\0\250\3\0\0\264B\0\0\10\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 936, 0, NULL, 0) = 936
sendto(8, "\2\0\0\0\250\3\0\0\264B\0\0\10\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 936, 0, NULL, 0) = 936
sendto(8, "\2\0\0\0\250\3\0\0\264B\0\0\10\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 936, 0, NULL, 0) = 936
sendto(8, "\2\0\0\0\250\3\0\0\264B\0\0\10\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 936, 0, NULL, 0) = 936
sendto(8, "\2\0\0\0\250\3\0\0\264B\0\0\10\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 936, 0, NULL, 0) = 936
sendto(8, "\2\0\0\0\10\1\0\0\264B\0\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 264, 0, NULL, 0) = 264
sendto(8, "\2\0\0\0\10\1\0\0\0\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 264, 0, NULL, 0) = 264
sendto(8, "\16\0\0\0H\0\0\0\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0"..., 72, 0, NULL, 0) = 72
sendto(9, "T\0\0\0#\0\1QUERY PLAN\0\0\0\0\0\0\0\0\0\0\31\377\377\377\377"..., 826, 0, NULL, 0) = 826
recvfrom(9, 0xd2b4e0, 8192, 0, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
epoll_wait(4, 

虽然shared hit很多，但strace信息很少 strace显示会话只open了4个数据文件，通过fd和oid2name查到数据文件，分别是表、表的两个索引以及pathman_config：

From database "lzldb":
 Filenode Table Name
--------------------------------------
 46170 ix_name
 46168 pk_lzlinfo
 46160 lzlinfo
 16678 pathman_config

这些对象都不大，看上去不像这些表（or索引）过大导致的。

perf
#

（图不好贴自行脑补） perf火焰图有40%的时间在heap_hot_search_buffer堆栈上

gdb
#

以heap_hot_search_buffe函数为依据，经过多次gdb，打如下断点试着看看哪有问题：

b relation_open
b get_relation_info
b RelationCacheInvalidateEntry 
b get_relname_relid
b AcceptInvalidationMessages
b RelationClearRelation
b pg_hint_plan_planner
b heap_hot_search_buffer

刚开始命中断点的时候，其实有很多无用的信息，因为他们是正常逻辑。不过后面发现，执行到一定程度，只有heap_hot_search_buffer命中：

Breakpoint 15, heap_hot_search_buffer (tid=tid@entry=0x2313c60, relation=0x2b2141663910, buffer=17045, snapshot=snapshot@entry=0x228a058, heapTuple=heapTuple@entry=0x23273d0, 
 all_dead=all_dead@entry=0x7ffce272e28f, first_call=true) at heapam.c:1503
1503 in heapam.c
(gdb) 
Continuing.
...

Breakpoint 15, heap_hot_search_buffer (tid=tid@entry=0x2313c60, relation=0x2b2141663910, buffer=96708, snapshot=snapshot@entry=0x228a058, heapTuple=heapTuple@entry=0x23273d0, 
 all_dead=all_dead@entry=0x7ffce272e28f, first_call=true) at heapam.c:1503
1503 in heapam.c

heap_hot_search_buffer传入的绝大部分参数没有变，包括relation、heapTuple的地址，只有buffer参数在改变，说明应该在扫描同一个relation。
heapTuple中包含table oid信息，直接打出来看看：

(gdb) p *heapTuple
$46 = {
 t_len = 968, 
 t_self = {
 ip_blkid = {
 bi_hi = 0, 
 bi_lo = 7211
 }, 
 ip_posid = 5
 }, 
 t_tableOid = 2619, --这个比较有用
 t_data = 0x2b2155fced00

heap_hot_search_buffer传入的oid=2619，2619在pg_class中对应pg_statistic

select oid,relname from pg_class where oid in (2619)
 oid | relname 
-------+----------------------------------
 2619 | pg_statistic

找这个统计信息基表无可厚非，因为pg在生成可能的执行计划s时需要用到统计信息来估算代价。

pg_statistic的膨胀
#

定位到pg_statistic，那么看下pg_statistic表的情况

> \dt+ pg_statistic
 List of relations
 Schema | Name | Type | Owner | Persistence | Size | Description 
------------+--------------+-------+----------+-------------+---------+-------------
 pg_catalog | pg_statistic | table | postgres | permanent | 1036 MB | 


> select * from pg_class where relname='pg_statistic'\gx
-[ RECORD 1 ]-------+------------------------------------------------
oid | 2619
relname | pg_statistic
relnamespace | 11
reltype | 12016
reloftype | 0
relowner | 10
relam | 2
relfilenode | 2619
reltablespace | 0
relpages | 132481
reltuples | 4655

pg_statistic有1G，确实有些大了，有132481块却只有4655行，这明显是有表膨胀了。但是即便有表膨胀，访问统计信息需要cache整个pg_statistic吗？逻辑上来说不需要，因为只需要访问对应表的统计信息就行了，实际上pg也是通过pg_statistic的主键索引pg_statistic_relid_att_inh_index来访问的。从下面的从堆栈中能看到传入的是pg_statistic的复合主键上的字段：

bt
...
#6 0x000000000086edbc in SearchCatCacheMiss (cache=cache@entry=0x226ba80, nkeys=nkeys@entry=3, hashValue=hashValue@entry=853716409, hashIndex=hashIndex@entry=57, v1=v1@entry=18767, v2=v2@entry=1, 
 v3=v3@entry=0, v4=v4@entry=0) at catcache.c:1368
#7 0x000000000086fa82 in SearchCatCacheInternal (v4=0, v3=<optimized out>, v2=<optimized out>, v1=<optimized out>, nkeys=3, cache=0x226ba80) at catcache.c:1299
#8 SearchCatCache3 (cache=0x226ba80, v1=v1@entry=18767, v2=v2@entry=1, v3=v3@entry=0) at catcache.c:1183
#9 0x0000000000880d70 in SearchSysCache3 (cacheId=cacheId@entry=58, key1=key1@entry=18767, key2=key2@entry=1, key3=key3@entry=0) at syscache.c:1145
#10 0x0000000000874092 in get_attavgwidth (relid=relid@entry=18767, attnum=1) at lsyscache.c:2991
#11 0x00000000006a2d46 in set_rel_width (root=root@entry=0x2326600, rel=rel@entry=0x21e8418) at costsize.c:5516 
...

传入了relid=relid@entry=18767, attnum=1

 select ctid,starelid,staattnum from pg_statistic where starelid=18767;
 ctid | starelid | staattnum 
------------+----------+-----------
 (132657,6) | 18767 | 1
 (132657,7) | 18767 | 2
 (132657,8) | 18767 | 3
 (132657,9) | 18767 | 4
 (132658,1) | 18767 | 5
 (132658,2) | 18767 | 6
 (132658,3) | 18767 | 7
 (132658,4) | 18767 | 8
 (132658,5) | 18767 | 9
 (132658,6) | 18767 | 10
 --lzlinfo总共10个字段，每个字段对应一个staattnum

通过ctid可以看出，这些数据实际上只在2个块中。看下通过复合主键索引访问pg_statistic，结果发现哪怕在只有2个块，也要访问1s，shared hit高达100w（1141568）：

 explain (analyze,buffers,timing,verbose) select ctid,starelid from pg_statistic where starelid=18767;
 QUERY PLAN 
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Index Scan using pg_statistic_relid_att_inh_index on pg_catalog.pg_statistic (cost=0.41..103.31 rows=23 width=10) (actual time=105.416..1035.723 rows=10 loops=1)
 Output: ctid, starelid
 Index Cond: (pg_statistic.starelid = '18767'::oid)
 Buffers: shared hit=1141568 --异常
 Planning:
 Buffers: shared hit=8
 Planning Time: 0.102 ms
 Execution Time: 1035.802 ms

通过索引访问10条pg_statistic数据，shared hit有100w，跟SQL的100w planning shared hit差不多。（注意这里的 Planning Time很少，说明我们没有在生成执行计划阶段出问题）

索引dead tuple
#

如果vacuum没有真的“跑起来”，那么索引的dead tuple还是会指向死元组参考从很慢的唯一索引扫描到索引膨胀

autovacuum未回收死元组
#

表膨胀这么大，autovacuum不应该回收吗？

select * from pg_stat_all_tables where relname='pg_statistic'\gx
-[ RECORD 1 ]-------+------------------------------
relid | 2619
schemaname | pg_catalog
relname | pg_statistic
seq_scan | 1 	 --顺序访问pg_statistic极少
seq_tup_read | 4655
idx_scan | 28715508 --索引访问pg_statistic多
idx_tup_fetch | 25150245
n_tup_ins | 46
n_tup_upd | 1292143 --update很多
n_tup_del | 14
n_tup_hot_upd | 138448
n_live_tup | 4655
n_dead_tup | 1496776
n_mod_since_analyze | 1292203
n_ins_since_vacuum | 0
last_vacuum | [null]
last_autovacuum | 2024-08-16 20:34:15.045022+08 --注意autovacuum的时间是一个最近的值
last_analyze | [null]
last_autoanalyze | [null]
vacuum_count | 0
autovacuum_count | 144170
analyze_count | 0
autoanalyze_count | 0

其实pg_statistic上是autovacuum一直在跑，只不过进程有可能看不到，因为autovacuum没有跑什么，所以跑的比较快，跑完又snap休息了

show autovacuum_naptime ;
 autovacuum_naptime 
--------------------
 1min

每间隔1分钟休息一次，日志中也是每隔1分钟打印一次autovacuum信息。

2024-08-16 21:05:15.267 CST,,,41080,,66bf4e87.a078,1,,2024-08-16 21:05:11 CST,27/166839,0,LOG,00000,"automatic vacuum of table ""lzldb.pg_catalog.pg_statistic"": index scans: 0
pages: 0 removed, 132685 remain, 1 skipped due to pins, 0 skipped frozen
tuples: 0 removed, 1501745 remain, 1497090 are dead but not yet removable, oldest xmin: 119329380
buffer usage: 265443 hits, 0 misses, 0 dirtied
avg read rate: 0.000 MB/s, avg write rate: 0.000 MB/s
system usage: CPU: user: 0.53 s, system: 0.17 s, elapsed: 3.38 s
WAL usage: 1 records, 0 full page images, 233 bytes",,,,,,,,,"","autovacuum worker"
2024-08-16 21:05:17.474 CST,,,41080,,66bf4e87.a078,2,,2024-08-16 21:05:11 CST,27/166844,136438968,LOG,00000,"automatic analyze of table ""lzldb.public.lzlinfo"" system usage: CPU: user: 2.02 s, system: 0.00 s, elapsed: 2.08 s",,,,,,,,,"","autovacuum worker"
"

1497090 are dead but not yet removable虽然触发了autovacuum但是根本没有回收到死元组，1497090条死元组没有清理。排查下库内是谁持有了oldest xmin: 119329380，很快可以定位到复制槽：

select * from pg_replication_slots;
 slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size 
-----------------+----------+-----------+--------+----------+-----------+--------+------------+--------+--------------+--------------+---------------------+------------+---------------
 slotslotlostname | pgoutput | logical | 17076 | lzldb | f | f | [null] | [null] | 119329380 | 3F9/105A4970 | 3F9/105F8778 | extended | [null]

slot的catalog_xmin=119329380，与vacuum展示的oldest xmin: 119329380一致。 active=f说明复制链路已经挂了。

修复问题
#

把复制槽删除：

select pg_drop_replication_slot('slotslotlostname');
 pg_drop_replication_slot 
--------------------------

手动vacuum或再等待1分钟autovacuum。最后再开一个全新的会话测试一下恢复没有：

## psql
psql (13.2)
Type "help" for help.

> \c lzldb
You are now connected to database "lzldb" as user "postgres".
> explain (analyze,buffers,timing) select * from lzlinfo limit 1;
 QUERY PLAN 
---------------------------------------------------------------------------------------------------------------------
 Limit (cost=0.00..8.04 rows=1 width=71) (actual time=0.023..0.025 rows=1 loops=1)
 Buffers: shared hit=1
 -> Seq Scan on lzlinfo (cost=0.00..3802.73 rows=473 width=71) (actual time=0.018..0.018 rows=1 loops=1)
 Buffers: shared hit=1
 Planning:
 Buffers: shared hit=2578
 Planning Time: 9.605 ms
 Execution Time: 0.098 ms

耗时从1s下降到10ms，Planning shared hit从100w下降到2k，问题基本解决。

案例总结
#

复制链路挂掉，复制槽未及时清理，导致pg_statistic统计信息基表膨胀，导致每个backend在首次加载统计信息时都非常缓慢且读取多余的page到本地缓存，导致每个backend的缓存都大于正常水平（2g左右），多个backend导致最后的OOM。其实问题很简单，只是过程比较曲折···简言之：基表pg_statistic膨胀导致执行计划生成阶段访问数据过大。元数据基表膨胀其实还有其他棘手的问题，有缘再见了。

ogg搭建oracle-pg同步——实操步骤

Tue, 13 Aug 2024 00:00:00 +0000

源库： oracle(11.2.0.4) 192.168.10.141

目标库：pgsql(10.12) 192.168.10.128

ogg软件版本:(19.1.0.0.4)

ogg软件下载：Oracle GoldenGate Downloads

glibc问题处理：https://www.cnblogs.com/hxlasky/p/16779047.html

1.在源端和目标端安装ogg软件

源端：

一、配置相应文件：oggcore.rsp

oracle.install.responseFileVersion=/home/oracle/oggcore.rsp

INSTALL_OPTION=ORA11g

SOFTWARE_LOCATION=/oracle/ogg

START_MANAGER=false

MANAGER_PORT=7809

DATABASE_LOCATION=/oracle/db/11.2.0.4

INVENTORY_LOCATION=/oracle/oraInventory

UNIX_GROUP_NAME=oinstall

二、静默安装OGG

./runInstaller -silent -nowait -responseFile /home/oracle/oggcore.rsp

oracle@szgtsp431-or@ecsdb>./runInstaller -silent -nowait -responseFile /home/oracle/oggcore.rsp

Starting Oracle Universal Installer…

Checking Temp space: must be greater than 120 MB. Actual 32405 MB Passed

Checking swap space: must be greater than 150 MB. Actual 2048 MB Passed

Preparing to launch Oracle Universal Installer from /tmp/OraInstall2020-08-14_08-57-27AM. Please wait …oracle@szgtsp431-or@ecsdb>You can find the log of this install session at:

/oracle/oraInventory/logs/installActions2020-08-14_08-57-27AM.log

Successfully Setup Software.

The installation of Oracle GoldenGate Core was successful.

Please check ‘/oracle/oraInventory/logs/silentInstall2020-08-14_08-57-27AM.log’ for more details.

2.修改数据库为归档模式

oracle@szgtsp431-or@ecsdb>sqlplus / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on Fri Aug 14 09:06:34 2020

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> archive log list;

Database log mode Archive Mode

Automatic archival Enabled

Archive destination /oracle/oradata/archivelog

Oldest online log sequence 19

Next log sequence to archive 21

Current log sequence 21

3.开启数据库的强制日志和最小附加日志

alter database force logging;

alter database add supplemental log data;

alter system switch logfile;

确认是否开启了强制日志和最小附加日志

select force_logging,supplemental_log_data_min from v$database;

4.修改enable_goldengate_replication参数

alter system set enable_goldengate_replication=true scope=both;

若为集群，所有节点都要修改:

alter system set enable_goldengate_replication=true scope=both sid=’*’;

5.创建ogg用户和ogg用户表空间并授权

create tablespace tbs_ogg datafile ‘/oracle/oradata/datafile/tbs_ogg01.dbf’ size 100M;

create user goldengate identified by 123456 default tablespace tbs_ogg temporary tablespace temp;

grant create session,alter session to goldengate;

grant alter system to goldengate;

grant resource to goldengate;

grant connect to goldengate;

grant select any dictionary to goldengate;

grant flashback any table to goldengate;

grant select any table to goldengate;

grant insert any table to goldengate;

grant update any table to goldengate;

grant delete any table to goldengate;

grant select on dba_clusters to goldengate;

grant execute on dbms_flashback to goldengate;

grant create table to goldengate;

grant create sequence to goldengate;

grant alter any table to goldengate;

grant dba to goldengate;

grant lock any table to goldengate;

6.开启表级附件日志

要同步某个schema的表数据或者多个schema的数据，需要对表开启附加日志

检查附件日志：

SELECT

owner,

table_name,

log_group_name,

log_group_type,

decode( always, ‘ALWAYS’, ‘Unconditional’, NULL, ‘Conditional’ ) always

FROM dba_log_groups

ORDER BY owner,table_name,log_group_name;

选择空闲时段打开所需复制表的附加日志:

oracle@szgtsp431-or@ecsdb>ggsci

Oracle GoldenGate Command Interpreter for Oracle

Version 19.1.0.0.4 OGGCORE_19.1.0.0.0_PLATFORMS_191017.1054_FBO

Linux, x64, 64bit (optimized), Oracle 11g on Oct 17 2019 23:13:12

Operating system character set identified as US-ASCII.

GGSCI (szgtsp431-or) 1> dblogin userid goldengate,password 123456

Successfully logged into database.

GGSCI (szgtsp431-or as goldengate@ecsdb) 2> add trandata ecs.*

2020-08-14 09:13:54 INFO OGG-15132 Logging of supplemental redo data enabled for table ECS.DEPT.

2020-08-14 09:13:54 INFO OGG-15133 TRANDATA for scheduling columns has been added on table ECS.DEPT.

2020-08-14 09:13:54 INFO OGG-15135 TRANDATA for instantiation CSN has been added on table ECS.DEPT.

2020-08-14 09:13:54 INFO OGG-15132 Logging of supplemental redo data enabled for table ECS.INFO.

2020-08-14 09:13:54 INFO OGG-15133 TRANDATA for scheduling columns has been added on table ECS.INFO.

2020-08-14 09:13:54 INFO OGG-15135 TRANDATA for instantiation CSN has been added on table ECS.INFO.

2020-08-14 09:13:54 INFO OGG-15132 Logging of supplemental redo data enabled for table ECS.STUDENT_INFO.

2020-08-14 09:13:54 INFO OGG-15133 TRANDATA for scheduling columns has been added on table ECS.STUDENT_INFO.

2020-08-14 09:13:54 INFO OGG-15135 TRANDATA for instantiation CSN has been added on table ECS.STUDENT_INFO.

GGSCI (szgtsp431-or as goldengate@ecsdb) 3>

查看日志是否添加成功:

SQL> select *from (

2 select owner,table_name from dba_tables where owner in (‘BGLWT’)

3 minus

4 select owner,table_name from dba_log_groups)

5 order by owner,table_name;

no rows selected

返回0行，表示所有的表级附加日志添加成功。

7.配置管理进程

oracle@szgtsp431-or@ecsdb>ggsci

Oracle GoldenGate Command Interpreter for Oracle

Version 19.1.0.0.4 OGGCORE_19.1.0.0.0_PLATFORMS_191017.1054_FBO

Linux, x64, 64bit (optimized), Oracle 11g on Oct 17 2019 23:13:12

Operating system character set identified as US-ASCII.

GGSCI (szgtsp431-or) 1> dblogin userid goldengate,password 123456

Successfully logged into database.

GGSCI (szgtsp431-or as goldengate@ecsdb) 2> create subdirs

Creating subdirectories under current directory /home/oracle

Parameter file /oracle/ogg/dirprm: created.

Report file /oracle/ogg/dirrpt: created.

Checkpoint file /oracle/ogg/dirchk: created.

Process status files /oracle/ogg/dirpcs: created.

SQL script files /oracle/ogg/dirsql: created.

Database definitions files /oracle/ogg/dirdef: created.

Extract data files /oracle/ogg/dirdat: created.

Temporary files /oracle/ogg/dirtmp: created.

Credential store files /oracle/ogg/dircrd: created.

Masterkey wallet files /oracle/ogg/dirwlt: created.

Dump files /oracle/ogg/dirdmp: created.

GGSCI (szgtsp431-or as goldengate@ecsdb) 3> edit param mgr

PORT 7809

DYNAMICPORTLIST 7810-7980

PURGEOLDEXTRACTS ./dirdat/*, USECHECKPOINTS, MINKEEPDAYS 3

PURGEDDLHISTORY MINKEEPDAYS 7, MAXKEEPDAYS 10

LAGREPORTHOURS 1

LAGINFOMINUTES 30

LAGCRITICALMINUTES 45

GGSCI (szgtsp431-or as goldengate@ecsdb) 6>

8.配置抽取进程

GGSCI (szgtsp431-or as goldengate@ecsdb) 7> add extract extecs, tranlog, threads 1,begin now

EXTRACT added.

GGSCI (szgtsp431-or as goldengate@ecsdb) 8> add exttrail ./dirdat/lt, extract extecs

EXTTRAIL added.

GGSCI (szgtsp431-or as goldengate@ecsdb) 9> info all

Program Status Group Lag at Chkpt Time Since Chkpt

MANAGER RUNNING

EXTRACT STOPPED EXTECS 00:00:00 00:00:38

GGSCI (szgtsp431-or as goldengate@ecsdb) 10> edit param extecs

EXTRACT extecs

SETENV (ORACLE_HOME = “/oracle/db/11.2.0.4”)

SETENV (ORACLE_SID = “ecsdb”)

USERID goldengate, PASSWORD 123456

EXTTRAIL ./dirdat/lt

TRANLOGOPTIONS EXCLUDEUSER goldengate

TRANLOGOPTIONS DBLOGREADER

DBOPTIONS ALLOWUNUSEDCOLUMN

FETCHOPTIONS USESNAPSHOT, USELATESTVERSION, MISSINGROW REPORT

STATOPTIONS REPORTFETCH

WARNLONGTRANS 1h, CHECKINTERVAL 10m

DYNAMICRESOLUTION

DISCARDFILE ./dirrpt/extecs.dsc, APPEND, MEGABYTES 1024

DISCARDROLLOVER AT 6:00

REPORTROLLOVER AT 6:00

REPORTCOUNT EVERY 1 MINUTES, RATE

DDL INCLUDE MAPPED

DDLOPTIONS ADDTRANDATA, REPORT

DDLOPTIONS NOCROSSRENAME, REPORT

TABLE ECS.*;

9.配置投递进程

GGSCI (szgtsp431-or as goldengate@ecsdb) 11> add extract deliecs, exttrailsource ./dirdat/lt

EXTRACT added.

GGSCI (szgtsp431-or as goldengate@ecsdb) 12> add rmttrail ./dirdat/rt, extract deliecs, megabytes 500

RMTTRAIL added.

GGSCI (szgtsp431-or as goldengate@ecsdb) 13> edit param deliecs

EXTRACT deliecs

PASSTHRU

DYNAMICRESOLUTION

RMTHOST 192.168.10.100, MGRPORT 7809

RMTTRAIL ./dirdat/rt

DISCARDFILE ./dirrpt/deliecs.dsc, APPEND, MEGABYTES 1024

DISCARDROLLOVER AT 6:00

REPORTCOUNT EVERY 1 MINUTES, RATE

REPORT AT 0:00

REPORT AT 1:00

REPORT AT 2:00

REPORT AT 3:00

…

REPORT AT 22:00

REPORT AT 23:00

REPORTROLLOVER AT 00:00

STATOPTIONS RESETREPORTSTATS

TABLE ECS.*;

10.启动抽取进程

GGSCI (szgtsp431-or as goldengate@ecsdb) 20> start extecs

Sending START request to MANAGER …

EXTRACT EXTECS starting

GGSCI (szgtsp431-or as goldengate@ecsdb) 21> info all

Program Status Group Lag at Chkpt Time Since Chkpt

MANAGER RUNNING

EXTRACT STOPPED DELIECS 00:00:00 00:06:06

EXTRACT RUNNING EXTECS 00:00:00 00:00:01

11.配置目标端ogg软件

一、上传ogg软件并解压

二、配置ogg软件的环境变量

[pgsql@szgtsp428-or ~]$ vi .bash_profile

.bash_profile
#

Get the aliases and functions
#

if [ -f ~/.bashrc ]; then

. ~/.bashrc

User specific environment and startup programs
#

PATH=$PATH:$HOME/bin

export PATH

export PGHOME=/usr/local/pgsql

export PGDATA=/data/pgsql

export OGG_HOME=/data/ogg

export PATH=$PATH:$PGHOME/bin:$OGG_HOME

LD_LIBRARY_PATH=$PGHOME/lib

LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/lib:/usr/lib:/usr/local/lib:$OGG_HOME/lib

export LD_LIBRARY_PATH

export ODBCINI=/home/pgsql/odbc.ini

export DD_ODBC_HOME=/data/ogg

[pgsql@szgtsp428-or ~]$ ggsci

Oracle GoldenGate Command Interpreter for PostgreSQL

Version 19.1.0.0.200714 OGGCORE_19.1.0.0.0OGGBP_PLATFORMS_200628.2141

Linux, x64, 64bit (optimized), PostgreSQL on Jun 29 2020 03:59:15

Operating system character set identified as UTF-8.

GGSCI (szgtsp428-or) 1>

12.目标端创建库及表

ecsdb=# \l

List of databases

———–+———-+———-+————-+————-+——————-

(4 rows)

ecsdb=# \d

List of relations

Schema | Name | Type | Owner

——–+————–+——-+———-

public | student_info | table | postgres

(1 row)

ecsdb=# select * from student_info;

id | name | address

—-+——+———

1 | 张三 | 广州

2 | 李四 | 深圳

3 | 王五 | 上海

4 | 赵六 | 北京

5 | 孙七 | 武汉

6 | 阿大 | 成都

7 | 阿二 | 南京

(7 rows)

13.配置目标端管理进程并启动mgr

[pgsql@szgtsp428-or ogg]$ ggsci

Oracle GoldenGate Command Interpreter for PostgreSQL

Version 19.1.0.0.200714 OGGCORE_19.1.0.0.0OGGBP_PLATFORMS_200628.2141

Linux, x64, 64bit (optimized), PostgreSQL on Jun 29 2020 03:59:15

Operating system character set identified as UTF-8.

GGSCI (szgtsp428-or) 1> info all

Program Status Group Lag at Chkpt Time Since Chkpt

MANAGER STOPPED

GGSCI (szgtsp428-or) 2> create subdirs

Creating subdirectories under current directory /data/ogg

Parameter file /data/ogg/dirprm: created.

Report file /data/ogg/dirrpt: created.

Checkpoint file /data/ogg/dirchk: created.

Process status files /data/ogg/dirpcs: created.

SQL script files /data/ogg/dirsql: created.

Database definitions files /data/ogg/dirdef: created.

Extract data files /data/ogg/dirdat: created.

Temporary files /data/ogg/dirtmp: created.

Credential store files /data/ogg/dircrd: created.

Masterkey wallet files /data/ogg/dirwlt: created.

Dump files /data/ogg/dirdmp: created.

GGSCI (szgtsp428-or) 3> edit param mgr

port 7809

GGSCI (szgtsp428-or) 4> info all

Program Status Group Lag at Chkpt Time Since Chkpt

MANAGER STOPPED

GGSCI (szgtsp428-or) 5> start mgr

Manager started.

GGSCI (szgtsp428-or) 7> info all

Program Status Group Lag at Chkpt Time Since Chkpt

MANAGER RUNNING

GGSCI (szgtsp428-or) 8>

这个时候在源端启动投递进程 deliecs

oracle@szgtsp431-or@ecsdb>ggsci

Oracle GoldenGate Command Interpreter for Oracle

Version 19.1.0.0.4 OGGCORE_19.1.0.0.0_PLATFORMS_191017.1054_FBO

Linux, x64, 64bit (optimized), Oracle 11g on Oct 17 2019 23:13:12

Operating system character set identified as US-ASCII.

GGSCI (szgtsp431-or) 1> info all

Program Status Group Lag at Chkpt Time Since Chkpt

MANAGER RUNNING

EXTRACT ABENDED DELIECS 00:00:00 01:06:41

EXTRACT RUNNING EXTECS 00:00:00 00:00:07

GGSCI (szgtsp431-or) 2> start deliecs

Sending START request to MANAGER …

EXTRACT DELIECS starting

GGSCI (szgtsp431-or) 3> info all

Program Status Group Lag at Chkpt Time Since Chkpt

MANAGER RUNNING

EXTRACT RUNNING DELIECS 00:00:00 01:06:55

EXTRACT RUNNING EXTECS 00:00:00 00:00:01

GGSCI (szgtsp431-or) 4> info all

Program Status Group Lag at Chkpt Time Since Chkpt

MANAGER RUNNING

EXTRACT RUNNING DELIECS 00:00:00 00:00:00

EXTRACT RUNNING EXTECS 00:00:00 00:00:05

14.目标端pgsql的参数调整

[pgsql@szgtsp428-or pgsql]$ vi /data/pgsql/postgresql.conf

wal_level = logical #minimal, replica, or logical

max_replication_slots = 10 #max number of replication slots

max_wal_sender = 10 #maximum number of wal sender processes

wal_receiver_status_interval=10s #optional, keep the system default

wal_sender_timeout = 60s #optional, keep the system default

track_commit_timestamp=off #optional, keep the system default

调整参数后重启pgsql

[pgsql@szgtsp428-or pgsql]$ pg_ctl status -D /data/pgsql/ -l /data/pgsql/logfile

pg_ctl: server is running (PID: 2370)

/usr/local/pgsql/bin/postgres “-D” “/data/pgsql”

[pgsql@szgtsp428-or pgsql]$ pg_ctl stop -D /data/pgsql/ -l /data/pgsql/logfile

waiting for server to shut down…. done

server stopped

[pgsql@szgtsp428-or pgsql]$ pg_ctl start -D /data/pgsql/

waiting for server to start….2020-08-14 11:00:45.360 CST [2817] LOG: listening on IPv4 address “0.0.0.0”, port 5432

2020-08-14 11:00:45.361 CST [2817] LOG: listening on IPv6 address “::”, port 5432

2020-08-14 11:00:45.364 CST [2817] LOG: listening on Unix socket “/tmp/.s.PGSQL.5432”

2020-08-14 11:00:45.375 CST [2818] LOG: database system was shut down at 2020-08-14 10:50:10 CST

2020-08-14 11:00:45.378 CST [2817] LOG: database system is ready to accept connections

done

server started

15.数据源配置

vi odbc.ini

[pgsql@szgtsp428-or ~]$ vi /home/pgsql/odbc.ini

[ODBC Data Sources]

PGDSN=DataDirect 10.12 PostgreSQL Wire Protocol

postgres=DataDirect 10.12 PostgreSQL Wire Protocol

scott=DataDirect 10.12 PostgreSQL Wire Protocol

[ODBC]

IANAAppCodePage=4

InstallDir=/data/ogg

[PGDSN]

Driver=/data/ogg/lib/GGpsql25.so

Description=DataDirect 10.12 PostgreSQL Wire Protocol

Database=ecsdb

HostName=127.0.0.1

PortNumber=5432

LogonID=postgres

Password=123456

16.连接测试

[pgsql@szgtsp428-or ~]$ cd /data/ogg

[pgsql@szgtsp428-or ogg]$ ggsci

Oracle GoldenGate Command Interpreter for PostgreSQL

Version 19.1.0.0.200714 OGGCORE_19.1.0.0.0OGGBP_PLATFORMS_200628.2141

Linux, x64, 64bit (optimized), PostgreSQL on Jun 29 2020 03:59:15

Operating system character set identified as UTF-8.

GGSCI (szgtsp428-or) 1> info all

Program Status Group Lag at Chkpt Time Since Chkpt

MANAGER RUNNING

GGSCI (szgtsp428-or) 2> dblogin sourcedb pgdsn userid postgres, password postgres

2020-08-14 11:35:01 INFO OGG-03036 Database character set identified as UTF-8. Locale: en_US.UTF-8.

2020-08-14 11:35:01 INFO OGG-03037 Session character set identified as UTF-8.

Successfully logged into database.

GGSCI (szgtsp428-or as postgres@pgdsn) 3>

17.目标端配置复制进程并启动

添加checkpoint table

[pgsql@szgtsp428-or ogg]$ ggsci

Oracle GoldenGate Command Interpreter for PostgreSQL

Version 19.1.0.0.200714 OGGCORE_19.1.0.0.0OGGBP_PLATFORMS_200628.2141

Linux, x64, 64bit (optimized), PostgreSQL on Jun 29 2020 03:59:15

Operating system character set identified as UTF-8.

GGSCI (szgtsp428-or) 1> dblogin sourcedb pgdsn userid postgres, password 123456

2020-08-14 15:22:52 INFO OGG-03036 Database character set identified as UTF-8. Locale: en_US.UTF-8.

2020-08-14 15:22:52 INFO OGG-03037 Session character set identified as UTF-8.

Successfully logged into database.

GGSCI (szgtsp428-or as postgres@pgdsn) 2> add checkpointtable public.chkt

Successfully created checkpoint table public.chkt.

GGSCI (szgtsp428-or as postgres@pgdsn) 4> list table public.*

public.chkt

public.chkt_lox

public.student_info

public.test

Found 4 tables matching list criteria.

GGSCI (szgtsp428-or as postgres@pgdsn) 34> edit param repl

REPLICAT repl

SOURCEDEFS ./dirdef/student_info.def

SETENV (PGCLIENTENCODING = “UTF8”)

SETENV (ODBCINI="/home/pgsql/odbc.ini")

SETENV (NLS_LANG=“AMERICAN_AMERICA.AL32UTF8”)

targetdb pgdsn userid postgres, password 123456

DISCARDFILE ./dirrpt/repl.dsc, purge

MAP ecs.student_info, TARGET public.student_info;

GGSCI (szgtsp428-or as postgres@pgdsn) 36> add replicat repl,exttrail ./dirdat/rt,checkpointtable public.chkt

REPLICAT added.

GGSCI (szgtsp428-or as postgres@pgdsn) 38> start repl

Sending START request to MANAGER …

REPLICAT REPL starting

GGSCI (szgtsp428-or as postgres@pgdsn) 55> info all

Program Status Group Lag at Chkpt Time Since Chkpt

MANAGER RUNNING

REPLICAT RUNNING REPL 00:00:00 00:00:08

18.测试验证

首先在目标端创建跟源端student_info一致的表结构

ecsdb=# create table student_info (id int primary key,name varchar(100),address varchar(100));

CREATE TABLE

然后进行数据初始化:

在源库配置extinit进程

GGSCI (szgtsp431-or as goldengate@ecsdb) 17> edit param extinit

EXTRACT extinit

userid goldengate, PASSWORD 123456

REPORTCOUNT EVERY 30 MINUTES, RATE

DISCARDFILE ./dirrpt/extinit.dsc, APPEND, MEGABYTES 1024

RMTHOST 192.168.10.100,MGRPORT 7809, compress

RMTTASK replicat,GROUP replinit

TABLE ecs.student_info;

GGSCI (szgtsp431-or as goldengate@ecsdb) 18> ADD EXTRACT extinit, SOURCEISTABLE

EXTRACT added.

在目标端配置replinit进程

GGSCI (szgtsp428-or as postgres@pgdsn) 28> edit param replinit

REPLICAT replinit

targetDB pgdsn, USERID postgres, PASSWORD 123456

discardfile ./dirrpt/replinit.dsc, PURGE

SOURCEDEFS ./dirdef/student_info.def

Map ecs.student_info,target public.student_info;

GGSCI (szgtsp428-or as postgres@pgdsn) 29>add replicat repinit, SPECIALRUN

REPLICAT added.

开启oracle到pg的数据初始化:

GGSCI (szgtsp431-or as goldengate@ecsdb) 9> start extinit

Sending START request to MANAGER …

EXTRACT EXTINIT starting

目标端：(查看初始化行数)

View report replicat

查看两边的数据:

源：

SQL> set lines 200 pages 200;

SQL> col name for a10;

SQL> col address for a10;

SQL> select * from student_info;

ID NAME ADDRESS

1 张三广州

2 李四深圳

3 王五上海

4 赵六北京

5 孙七武汉

6 阿大成都

7 阿二南京

8 阿三北京

8 rows selected.

目标:

ecsdb=# select * from student_info;

id | name | address

—-+——+———

1 | 张三 | 广州

2 | 李四 | 深圳

3 | 王五 | 上海

4 | 赵六 | 北京

5 | 孙七 | 武汉

6 | 阿大 | 成都

7 | 阿二 | 南京

8 | 阿三 | 北京

(8 rows)

往源端插入数据:

SQL> insert into ecs.student_info values (10,‘aa’,‘bb’);

1 row created.

SQL> commit;

Commit complete.

SQL> select * from student_info;

ID NAME ADDRESS

1 张三广州

2 李四深圳

3 王五上海

4 赵六北京

5 孙七武汉

6 阿大成都

7 阿二南京

8 阿三北京

10 aa bb

9 rows selected.

查看目标端:

ecsdb=# select * from student_info;

id | name | address

—-+——+———

1 | 张三 | 广州

2 | 李四 | 深圳

3 | 王五 | 上海

4 | 赵六 | 北京

5 | 孙七 | 武汉

6 | 阿大 | 成都

7 | 阿二 | 南京

8 | 阿三 | 北京

10 | aa | bb

(9 rows)

数据已经同步OK了。

ogg搭建pg-oracle同步——实操步骤

Tue, 13 Aug 2024 00:00:00 +0000

ogg软件版本:(19.1.0.0.4) oracle版本：11.2.0.4 pg版本：pg10 ogg下载地址：https://www.oracle.com/technetwork/middleware/goldengate/downloads/index.html

glibc问题处理：https://www.cnblogs.com/hxlasky/p/16779047.html

1.源端创建库及表
#

[root@node2 ~]# su - postgres
Last login: Tue Jul 21 21:08:52 CST 2020 on pts/0
[postgres@node2 ~]$ pg_ctl -D /opt/pgsql_data -l logfile start
waiting for server to start.... done
server started
postgres=# create database test
postgres=# \c lzldb
postgres=# create table tab1(id int primary key,name varchar(20))

2.目标端创建库及表
#

sqlplus / as sysdba
SQL> create table ORALZL.tab1(id number primary key,name varchar2(20));

3.解压安装ogg for postgresql
#

--跟ogg for oracle不同，ogg for pg只需要解压。for o需要跑runinstaller
[postgres@node1 ~]$ id postgres
uid=54323(postgres) gid=54330(postgres) groups=54330(postgres)
[postgres@node1 ~]$ exit
logout
[root@node1 ~]# mkdir /ogg
[root@node1 ~]# chown -R postgres /ogg
[root@node1 ~]# chmod -R 755 /ogg
[root@node1 ~]#
[root@node1 soft]# ls -l

total 240744

-rw-r--r--. 1 root root 87028695 Jul 22 02:51 19100200714_ggs_Linux_x64_PostgreSQL_64bit.zip
[root@node1 soft]# chmod 777 19100200714_ggs_Linux_x64_PostgreSQL_64bit.zip
[root@node1 soft]# unzip 19100200714_ggs_Linux_x64_PostgreSQL_64bit.zip
Archive: 19100200714_ggs_Linux_x64_PostgreSQL_64bit.zip
 inflating: ggs_Linux_x64_PostgreSQL_64bit.tar 
 inflating: OGG-19.1.0.0-README.txt 
 inflating: release-notes-oracle-goldengate_19.1.0.200714.pdf 
[root@node1 soft]# chmod 777 ggs_Linux_x64_PostgreSQL_64bit.tar
[root@node1 soft]# su - postgres
[postgres@node1 ~]$ cd /soft
[postgres@node1 soft]$ tar -xf ggs_Linux_x64_PostgreSQL_64bit.tar -C /ogg

4.pg用户环境变量配置
#

pg源端

[postgres@node1 ~]$ cat .bash_profile
## .bash_profile
## Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
## User specific environment and startup programs
PATH=$PATH:$HOME/.local/bin:$HOME/bin
export GGHOME=/ogg
export PG_DATA=/opt/pgsql/pgsql/bin
export PATH=$PG_DATA:$PATH
export PG_HOME=/opt/pgsql/pgsql
export LD_LIBRARY_PATH=$PG_HOME/lib:$LD_LIBRARY_PATH:$GGHOME/lib
export ODBCINI=/home/postgres/odbc.ini
export DD_ODBC_HOME=/ogg
export PATH
[postgres@node1 ~]$ source .bash_profile

5.配置管理进程
#

[postgres@node1 ~]$ cd /ogg
[postgres@node1 ogg]$ ./ggsci
Oracle GoldenGate Command Interpreter for PostgreSQL
Version 19.1.0.0.200714 OGGCORE_19.1.0.0.0OGGBP_PLATFORMS_200628.2141
Linux, x64, 64bit (optimized), PostgreSQL on Jun 29 2020 03:59:15
Operating system character set identified as UTF-8.
Copyright (C) 1995, 2019, Oracle and/or its affiliates. All rights reserved.
GGSCI (node1) 2> info all
Program Status Group Lag at Chkpt Time Since Chkpt
MANAGER STOPPED 


GGSCI (node1) 3> create subdirs
Creating subdirectories under current directory /ogg
Parameter file /ogg/dirprm: created.
Report file /ogg/dirrpt: created.
Checkpoint file /ogg/dirchk: created.
Process status files /ogg/dirpcs: created.
SQL script files /ogg/dirsql: created.
Database definitions files /ogg/dirdef: created.
Extract data files /ogg/dirdat: created.
Temporary files /ogg/dirtmp: created.
Credential store files /ogg/dircrd: created.
Masterkey wallet files /ogg/dirwlt: created.
Dump files /ogg/dirdmp: created.
GGSCI (node1) 4> edit params mgr
GGSCI (node1) 5> view params mgr
port 7809
GGSCI (node1) 6> start mgr
Manager started.
GGSCI (node1) 7> info all
Program Status Group Lag at Chkpt Time Since Chkpt
MANAGER RUNNING 

6.源端postgresql参数调整
#

[postgres@node1 ogg]$ vi /opt/pgsql_data/postgresql.conf
wal_level = logical #minimal, replica, or logical
max_replication_slots = 10 #max number of replication slots
max_wal_sender = 10 #maximum number of wal sender processes
wal_receiver_status_interval=10s #optional, keep the system default
wal_sender_timeout #optional, keep the system default
track_commit_timestamp #optional, keep the system default
wal_receiver_status_interval=10s
wal_sender_timeout = 60s
track_commit_timestamp=off

调整后重启源端postgresql

[postgres@node1 ogg]$ pg_ctl -D /opt/pgsql_data -l logfile stop
[postgres@node1 ogg]$ pg_ctl -D /opt/pgsql_data -l logfile start

7.ogg for pg数据源配置
#

cd /home/postgres/
vi odbc.ini
[ODBC Data Sources]
PGDSN=DataDirect 7.1 PostgreSQL Wire Protocol
postgres=DataDirect 7.1 PostgreSQL Wire Protocol
scott=DataDirect 7.1 PostgreSQL Wire Protocol
[ODBC]
IANAAppCodePage=4
InstallDir=/ogg
[PGDSN]
Driver=/ogg/lib/GGpsql25.so
Description=DataDirect 7.1 PostgreSQL Wire Protocol
Database=test
HostName=192.168.1.112
PortNumber=5432
LogonID=postgres
Password=postgres

8. 连接测试
#

[postgres@node1 ~]$ cd /ogg
[postgres@node1 ogg]$ ./ggsci
--dblogin sourcedb pgdsn userid pg, password 123456
GGSCI (node1) 1> dblogin sourcedb pgdsn userid postgres, password postgres
2020-07-22 03:10:44 INFO OGG-03036 Database character set identified as UTF-8. Locale: en_US.UTF-8.
2020-07-22 03:10:44 INFO OGG-03037 Session character set identified as UTF-8.
Successfully logged into database.
GGSCI (node1 as postgres@pgdsn) 2>

9.开启表级别附加日志
#

源端：

GGSCI (node1) 3> dblogin sourcedb pgdsn userid postgres, password postgres
2020-07-22 03:21:01 INFO OGG-03036 Database character set identified as UTF-8. Locale: en_US.UTF-8.
2020-07-22 03:21:01 INFO OGG-03037 Session character set identified as UTF-8.
Successfully logged into database.
GGSCI (node1 as postgres@pgdsn) 4> add trandata public.tab1 --如果表有主键这步可以忽略
Logging of supplemental log data is enabled for table public.tab1. REPLICA IDENTITY was DEFAULT and is changed to FULL
GGSCI (node1 as postgres@pgdsn) 5>
GGSCI (node1 as postgres@pgdsn) 5> info trandata public.tab1
Logging of supplemental log data is enabled for table public.t1 with REPLICA IDENTITY set to FULL

10 在pg上注册抽取进程
#

在pg库上注册抽取进程，实际上就是创建了一个复制槽,output plugin 默认使用test_decoding

 GGSCI (node1 as postgres@pgdsn) 6> Register Extract ext_pg
 2020-07-22 03:25:27 INFO OGG-25355 Successfully created replication slot 'ext_pg_2947c06e0ea2ec74' for EXTRACT group 'EXT_PG' in database 'test'.

11.配置抽取进程和投递进程
#

配置抽取进程

 edit param ext_pg

SETENV ( PGCLIENTENCODING = "UTF8" )
 SETENV (NLS_LANG="AMERICAN_AMERICA.AL32UTF8")
 extract ext_pg
 SETENV (ODBCINI="/home/pg/odbc.ini" ) 
 SOURCEDB pgdsn, USERID pg, PASSWORD 123456
 exttrail ./dirdat/st
 TABLE PUBLIC.TAB1;
 ----GETTRUNCATES ###此特性postgresql 2020-07-22 03:33:37 ERROR OGG-25541 GETTRUNCATES is not valid with OGG EXTRACT on PostgreSQL database version 10.12. PostgreSQL database supports capture of TRUNCATE operations starting from version 11.

说明pg到oracle无法同步truncate命令

配置投递进程

 extract pump_pg
 SETENV (ODBCINI="/home/pg/odbc.ini" )
 RMTHOST 172.17.100.150, MGRPORT 7809, compress
 numfiles 10000
 RMTTRAIL ./dirdat/rt
 TABLE PUBLIC.TAB1;

12.添加trail和启动抽取和投递
#

ADD extract ext_pg, TRANLOG,BEGIN now
 add exttrail ./dirdat/st,extract ext_pg,megabytes 500
 add extract pump_pg,exttrailsource ./dirdat/st
 add rmttrail ./dirdat/rt,extract pump_pg,megabytes 500
 start ext_pg
 start pump_pg

13 配置defgen
#

如果表结构一直可以配置参数ASSUMETARGETDEFS

edit param defgen

DEFSFILE ./dirdef/tab1.def, PURGE
 SOURCEDB pgdsn, USERID pg, PASSWORD 123456
 TABLE PUBLIC.tab1;

生成表定义文件

defgen paramfile /oggpg/dirdef/tab1.prm

拷贝defgen文件到目标端的dirdef目录下

14.目标端验证trail投递正常
#

[oracle@lzl dirdat]$ cd dirdat
 [oracle@lzl dirdat]$ ll
 -rw-r----- 1 pg pg 1439 Feb 28 11:02 rt000000000

15.在pg上注册抽取进程
#

在pg库上注册抽取进程，实际上就是创建了一个复制槽

GGSCI (node1 as postgres@pgdsn) 6> Register Extract ext_pg
2020-07-22 03:25:27 INFO OGG-25355 Successfully created replication slot 'ext_pg_2947c06e0ea2ec74' for EXTRACT group 'EXT_PG' in database 'test'.

16.配置oracle用户环境变量
#

export ORACLE_BASE=/oracle/app/oracle
 export ORACLE_HOME=$ORACLE_BASE/product/11.2.0/dbhome_1
 export ORACLE_SID=oralzl
 export OGG_HOME=/oggfororacle
 export PATH=$ORACLE_HOME/bin:$ORACLE_HOME/OPatch:$PATH
 export TNS_ADMIN=$ORACLE_HOME/network/admin
 export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$OGG_HOME:$ORACLE_HOME/lib32:/lib/usr/lib:/usr/local/lib

17.配置oracle侧的监听和tns
#

ogg for oracle会默认使用TNS_ADMIN下的tns 也可以在配置抽取的时候手动配置如：USERID goldengate@127.0.0.1:1521/oralzl, PASSWORD 123456

18.目标端安装ogg for oracle
#

下载ogg软件配置oggcore.rsp文件

oracle.install.responseFileVersion=/home/oracle/oggcore.rsp
INSTALL_OPTION=ORA11g
SOFTWARE_LOCATION=/ogg
START_MANAGER=false
MANAGER_PORT=7809
DATABASE_LOCATION=/oracle/db/11.2.0.4
INVENTORY_LOCATION=/oracle/oraInventory
UNIX_GROUP_NAME=oinstall

静默安装OGG

./runInstaller -silent -nowait -responseFile /home/oracle/oggcore.rsp

19 oracle库的用户和权限
#

create user goldengate identified by "123456";
 grant create session,alter session to goldengate;
 grant alter system to goldengate;
 grant resource to goldengate;
 grant connect to goldengate;
 grant select any dictionary to goldengate;
 grant flashback any table to goldengate;
 grant select any table to goldengate;
 grant select any table to goldengate;
 grant insert any table to goldengate;
 grant update any table to goldengate;
 grant delete any table to goldengate;
 grant select on dba_clusters to goldengate;
 grant execute on dbms_flashback to goldengate;
 grant create table to goldengate;
 grant create sequence to goldengate;
 grant alter any table to goldengate;
 grant dba to goldengate;
 grant lock any table to goldengate;

20 目标端mgr进程
#

edit param mgr

PORT 7809
 DYNAMICPORTLIST 7810-7980
 PURGEOLDEXTRACTS ./dirdat/*, USECHECKPOINTS, MINKEEPDAYS 3
 PURGEDDLHISTORY MINKEEPDAYS 7, MAXKEEPDAYS 10
 LAGREPORTHOURS 1
 LAGINFOMINUTES 30
 LAGCRITICALMINUTES 45

start mgr

21 目标端配置复制进程
#

GGSCI (node2) 8> dblogin userid goldengate@127.0.0.1:1521/oralzl,password 123456
GGSCI (node2 as postgres@pgdsn) 9> add checkpointtable goldengate.chkt
Successfully created checkpoint table public.chkt.

复制进程：

 edit param rep_pg
REPLICAT rep_pg
 USERID goldengate@127.0.0.1:1521/oralzl, PASSWORD 123456
 SOURCEDEFS ./dirdef/tab1.def
 MAP public.tab1, TARGET oralzl.tab1; 
add replicat rep_pg,exttrail ./dirdat/rt,checkpointtable goldengate.chkt
 start rep_pg

22 测试同步
#

[postgres@node1 ~]$ psql
postgres=# \c lzldb
test=# \d tab1;
​ Table "public.tab1"
 Column | Type | Collation | Nullable | Default 
--------+-----------------------+-----------+----------+---------
 id | integer | | not null | 
 name | character varying(20) | | | 
Indexes:
 "t1_pkey" PRIMARY KEY, btree (id)


lzldb=# insert into t2 values(1,'lzl1') ;
INSERT 0 1
lzldb=# select * from t2;
 id | name 
----+------
 1 | lzl1


[postgres@node2 ~]$sqlplus / as sysdba
SQL> select * from oralzl.tab1; 
​ id name 
---------- ----------
​ 1 lzl1 

pg_rewind初识

Tue, 13 Aug 2024 00:00:00 +0000

什么是pg_rewind?
#

pg_rewind是pg提供的工具，当2个pg实例时间线（timeline）出现分叉时，pg_rewind可以做实例间的同步。（比如主库运行的情况下，备库failover后运行了一段时间，此时主备的时间线就出现了分叉） pg_rewind会对比两者的大小，然后把大小不一样的文件从源拷贝到目标，包括配置文件。但是它不会对比没有发生改变的文件，所以pg_rewind在比较大的库，更改少量数据时，运行效率较高。 pg_rewind可以运用在备库failover后，备库即时运行一段时间，也可以把备库拉到和主库一样的状态，重新成为standby。 pg_rewind运行过程中，会对比主（源）备（目标）的差异点，并把主库的差异点后的WAL日志传递给备库。所以，如果主库在差异点之后的WAL也丢失了，那么rewind是不会拷贝不存在的WAL日志的，所以此时备库仍然不会被成功做成standby。解决该问题需要用restore。

！！！在使用pg_rewind时，应备份目标实例。pg_rewind会直接覆盖目标库的文件，如果rewind失败，那么可能目标库无法启动。

pg_rewind的使用
#

主备切换后，老主库仍然运行，导致主备时间线不一致，老主库无法当做新主库的备库启动

拉起备库时，报时间线错误如下

LOG:  entering standby mode
FATAL:  requested timeline 2 is not a child of this server's history
DETAIL:  Latest checkpoint is at 0/6000028 on timeline 1, but in the history of the requested timeline, the server forked off from that timeline at 0/4000098.
LOG:  startup process (PID 22321) exited with exit code 1
LOG:  aborting startup due to startup process failure
LOG:  database system is shut down

此时需要用rewind重新拉齐一次主备

1.配置当前主库的pg_hba 配置pg_rewind的登陆用户登陆源库许可，hba生效需要重启数据库

vi $source/pg_hba.conf
host    all       pg         172.17.100.150/32          trust

pg_rewind需要使用高权限用户，pg新版本可以授权，pg老版本最好用超级用户。我当前环境的版本为pg9.6，直接使用OS超级用户

2.wal_log_hints = on参数配置将wal_log_hints = on追加到目标库postgres.conf，重新启动并关闭一次目标库（此时主库是启动状态，备库是关闭状态）

vi $dest/postgres.conf

wal_log_hints = on

3.pg_rewind命令执行

[pg@lzl pg96data_sla]$ /pg/pg96/bin/pg_rewind --target-pgdata /pg/pg96data_pri --source-server='host=172.17.100.150 port=5433 user=pg password=oracle  dbname=postgres'
servers diverged at WAL position 0/4000098 on timeline 1
rewinding from last common checkpoint at 0/4000028 on timeline 1
Done!

4.配置备库参数更改postgres.conf和recovery.conf中的IP、端口、目录等配置，pg_rewind会把配置文件也cp过来

[pg@lzl pg96data_pri]$ mv recovery.done recovery.conf
[pg@lzl pg96data_pri]$ vi recovery.conf
[pg@lzl pg96data_pri]$ vi postgres.conf

5.启动备库

[pg@lzl pg96data_pri]$ /pg/pg96/bin/pg_ctl -D /pg/pg96data_sla -l /pg/pg96data_sla/server.log start 
server starting
[pg@lzl pg96data_sla]$ psql -p5433 postgres
psql (9.6.17)
postgres=# \x
Expanded display is on.
postgres=# select * from pg_stat_replication ;
-[ RECORD 1 ]----+------------------------------
pid | 24766
usesysid | 16384
usename | lzl
application_name | walreceiver
client_addr | 172.17.100.150
client_hostname | 
client_port | 47345
backend_start | 2021-07-30 07:44:05.582546+00
backend_xmin | 
state | streaming
sent_location | 0/4033790
write_location | 0/4033790
flush_location | 0/4033790
replay_location | 0/4033790
sync_priority | 0
sync_state | async

常见问题
#

pg_rewind命令报错一
#

could not fetch remote file "global/pg_control": ERROR:  must be superuser to read files
Failure, exiting

解决办法：使用高权限用户

postgres=# \du
                                    List of roles
  Role name  |                         Attributes                         | Member of 
-------------+------------------------------------------------------------+-----------
 lzl         | Replication                                                | {}
 pg          | Superuser, Create role, Create DB, Replication, Bypass RLS | {}
 rewind_user |                                                            | {}

pg用户是pg server自带的超级用户，跟pg安装用户相同。os的安装用户肯定有修改pg_control的权限

/pg/pg96/bin/pg_rewind --target-pgdata /pg/pg96data_pri --source-server='host=172.17.100.150 port=5433 user=pg password=oracle  dbname=postgres'

pg_rewind命令报错二
#

could not connect to server: FATAL:  no pg_hba.conf entry for host "172.17.100.150", user "rewind_user", database "postgres"
Failure, exiting

没有配置pg_hba.conf连接解决办法：配置用户的pg_hba，例如

host    all       pg         172.17.100.150/32          trust

pg_rewind命令报错三
#

[pg@lzl pg96data_sla]$   /pg/pg96/bin/pg_rewind --target-pgdata /pg/pg96data_pri --source-server='host=172.17.100.150 port=5433 user=pg password=oracle  dbname=postgres'

target server needs to use either data checksums or "wal_log_hints = on"

问题原因：

full_page_writes （默认开启）
wal_log_hints 设置成 on 或者 PG 在初始化时开启 checksums 功能解决办法：将wal_log_hints = on配置到目标库postgres.conf，启动再关闭一次目标库（目标库本来就是关闭的，必须启动再关闭一次，不然参数不会生效）

vi postgres.conf 加入目标库配置

wal_log_hints = on

重启目标库以生效

[pg@lzl pg96data_sla]$  /pg/pg96/bin/pg_ctl -D /pg/pg96data_pri -l /pg/pg96data_pri/server.log start      
server starting
[pg@lzl pg96data_sla]$  /pg/pg96/bin/pg_ctl -D /pg/pg96data_pri -l /pg/pg96data_pri/server.log stop
waiting for server to shut down.... done

参考文档：
#

https://www.postgresql.org/docs/9.6/app-pgrewind.html

PostgreSQL流复制

Tue, 13 Aug 2024 00:00:00 +0000

什么是PG流复制？
#

Streaming Replication是pg9.0开始提供的传递WAL日志的方式，只要primary库一产生日志，就会立马传递到standby库。在pg9.0之前，pg只能一个个传送wal日志(log shipping)，备库至少比主库落后一个wal日志

pg流复制进程
#

wal sender：wal sender存在于主库。wal sender进程将主库最新LSN到备库最新的LSN之间的wal 传递给备库 wal receiver：wal receiver存在于备库。wal receiver进程将备库最新的LSN号传递给主库。wal receiver接收wal sender传递过来的WAL数据并写入WAL日志 startup：备库实例恢复进程。将wal日志在备库上重放

pg 16776 14632 0 13:33 ? 00:00:00 postgres: wal sender process lzl 172.17.100.150(13338) streaming 0/3002D30

pg 16775 15329 0 13:33 ? 00:00:00 postgres: wal receiver process streaming 0/3002D30
pg 15330 15329 0 10:26 ? 00:00:00 postgres: startup process recovering 000000010000000000000003

pg流复制原理
#

pg流复制主要分为2个阶段，实例恢复阶段和主备同步阶段。 实例恢复阶段：当pg库异常宕机后，数据库启动时，pg会重放宕机前的最后一个checkpoint之后的所有WAL日志（这跟oracle、mysql等关系型数据库实例恢复是同样的原理，目的就是把数据库置为一致性状态）。pg备库在搭建时，一般主库都是不停机的，此时备份主库出来的备份库处于不一致状态，在备库启动时statup进程将进行实例恢复操作 主备同步阶段：wal receiver进程将备库最新的LSN号传递给主库，wal sender将主库最新LSN到备库最新的LSN之间的wal 传递给wal receiver，wal receiver接收WAL并将WAL写入到磁盘上，startup进程根据磁盘上的WAL日志在备库上重放

同步和异步
#

pg主从有5种模式，由synchronous_commit 参数控制。synchronous_commit 参数的本质就是控制主库什么时候提交。 remote_apply：所有备库上均已应用完WAL时，主库提交。所以这个模式是同步模式，主从是一致的，主库上能查到的数据备库上一定也可以查到，这种模式下主备没有延时，但对主库提交时间有影响，因为主库commit需要等待网络传输和备库应用时间 ynchronous_commit的含义分2种情况，有从库和无从库时（synchronous_standby_name空或非空时）

当synchronous_standby_name为非空时： remote_apply:从库已应用了wal，主库才可以提交。这种模式主从是同步的 on：default。主从的wal都写到磁盘上时，主库提交。类似半同步，不会丢数据。 remote_write：备库接收到wal并将wal日志写到文件系统cache上时，主库提交。此时从库的接收到wal但是还没有落盘，如果操作系统crash，会丢失数据。 local：主库wal刷到磁盘时提交。这种模式是异步的，主库不需要确认备库状态就可以提交。 off：本机wal没有刷到磁盘就可以提交，存在数据丢失风险，不推荐。

当synchronous_standby_name为空时：（当synchronous_standby_name为空时，synchronous_commit只有on和off有效，如果是remote_apply, remote_write and local ，那么仍然被认为是on） on：default。数据库wal写到磁盘上，事务才可以提交 off：本机wal没有刷到磁盘就可以提交，存在数据丢失风险，不推荐。

主从同步关系

主从可靠性

Failover
#

当主库crush时，备库就需要启动failover，此时备库就成为新主库。pg没有提供可以识别failure的方法，但是pg提供了激活主库的方法。（一般三方工具会调用pg激活方法，而主备监控、主库宕机判断、连接切换等等，都不是pg本身来做） pg提供了2种方法将备库激活为主库：trigger_file文件和pg_ctl promote命令。(pg 12以后trigger_file变成promote_trigger_file） trigger_file和pg_ctl promote在激活时都是一条命令就可以完成激活备库的任务，区别在于trigger_file需要在recover_file提前写好trigger_file配置使用trigger_file做主备切换（pg_ctl promote同样的效果，比较简单）：

备库recovery.conf中配置trigger_file
关闭主库
touch trigger_file，将老备库启动为新主库
配置recovery.conf，将老主库启动为新备库
观察新老主备库

failover示例： 环境：主库 172.17.100.150 5432 备库 172.17.100.150 5433

1.备库recovery.conf中配置trigger_file

$ cat recovery.conf|grep trigger
trigger_file = '/pg/pg96data_sla/trigger.kenyon'
$ ll /pg/pg96data_sla/trigger.kenyon
ls: cannot access /pg/pg96data_sla/trigger.kenyon: No such file or directory

在recovery.conf中配置trigger文件路径就可以了，配置后不会出现trigger文件

备库postgres.conf添加配置

max_wal_senders = 6 #max_wal_senders是sender进程的最大数量，默认是0，所以切换前备库必须配置
hot_standby=on #备库打开查询功能

2.关闭主库

$ pg_ctl stop -D /pg/pg96data_pri -m fast
waiting for server to shut down.... done
server stopped

(判断主库WAL是否全部被备库应用：pg9.6- cd pg_xlog;pg 10+ cd pg_wal)

ls -ltr|tail -n 1 |awk '{print $NF}'|while read xlog;do pg_xlogdump $xlog;done

观察备库wal中有关键词shutdown

3.touch激活备库(或者 pg_ctl promote -D /pg/pg96data_sla

$ touch /pg/pg96data_sla/trigger.kenyon

此时recovery.conf变成recovery.done

4.主库设置为备库 配置新备库recovery.conf文件，可以直接cp老备库的过来，修改IP和目录

vi $新备库/recover.conf
standby_mode = on
primary_conninfo = 'host=172.17.100.150 port=5433 user=lzl password=lzl'
recovery_target_timeline = 'latest'

配置postgres.conf，将hot_standby = on写入conf，表示备库开启查询

vi $新备库/postgres.conf
hot_standby = on

启动新备库

/pg/pg96/bin/pg_ctl -D /pg/pg96data_pri -l /pg/pg96data_pri/server.log start

5.检查主备库

postgres=# \x
Expanded display is on.
postgres=# select * from pg_stat_replication ;
-[ RECORD 1 ]----+------------------------------
pid | 24766
usesysid | 16384
usename | lzl
application_name | walreceiver
client_addr | 172.17.100.150
client_hostname | 
client_port | 47345
backend_start | 2021-07-30 07:44:05.582546+00
backend_xmin | 
state | streaming
sent_location | 0/4033790
write_location | 0/4033790
flush_location | 0/4033790
replay_location | 0/4033790
sync_priority | 0
sync_state | async

pg_basebackup
#

pg_basebackup是pg自带的备份工具，它用来做pg的基础备份。pg_basebackup可以用作PITR，也可以用来构造log-shipping standby和stream standby。它是pg的物理备份工具。 https://liuzhilong.blog.csdn.net/article/details/119533506

pg_rewind
#

pg_rewind可以用作pg主从的维护工具。当2个pg实例时间线（timeline）出现分叉时，pg_rewind可以做实例间的同步。（比如主库运行的情况下，备库failover后运行了一段时间，此时主备的时间线就出现了分叉） https://liuzhilong.blog.csdn.net/article/details/119250794

Replication Slots
#

什么是pg复制槽？ 主从架构下，如果从库还没有收到wal日志，主库就把wal删除了，这样的lag就不能自动恢复。复制槽就是为了确保主库不会把那些还没有被传到从库的WAL日志给删除。在没有使用复制槽的情况下，可能需要用 wal_keep_size/wal_keep_segment和 archive_command去确保wal日志不被删除，但这种方式总会保留过多的wal，且在延时较大时也不能保证wal一定不会被删除。所以复制槽就是为此而生。但是复制槽可能会导致主库一直不删除wal（比如从库已宕机的情况）导致磁盘被撑满，这时就需要max_slot_wal_keep_size来设置wal文件的保留上限。

复制槽参数： max_slot_wal_keep_size：在有复制槽时，该参数定义pg_wal目录下wal文件的最大大小。默认值为-1，表示主库为从库保留wal文件的大小没有上限。 wal_keep_segments/wal_keep_size:pg12及以下为wal_keep_segments，pg13及以上为wal_keep_size。保证pg_wal下的wal文件不会被删除。在没有复制槽的情况下，wal文件超过该大小就可能被删除，可能导致从库不可追日志。如果调整的过大，可能导致目录被撑的很大。该参数默认为0，也就是不保留WAL文件。如果wal被删除，可能会出现如下报错 ERROR: requested WAL segment xxxx has already been removed 这时从库只能期待有归档，否则只要重搭。 primary_slot_name：设置slot的名字，表示pg主从开启复制槽。所以开启pg复制槽至少有类似下面的配置 primary_conninfo = ‘host=172.17.100.150 port=5433 user=lzl password=lzl’ primary_slot_name = ‘pg_slot_lzl’ max_replication_slots:复制槽的最大个数，重启生效。如果使用的复制槽不足，从库将启动失败。应将该值设置的较大。在pg9.6版本以下，默认值为0，pg10以上为10。

创建pg复制槽

1.设置主库max_replication_slots参数 主库：（我的pg版本为9.6) max_replication_slots=10 加入postgres.conf，并重启主库

2.创建复制槽 创建复制槽：

postgres=# SELECT * FROM pg_create_physical_replication_slot('pg_slot_lzl');
 slot_name | xlog_position 
-------------+---------------
 pg_slot_lzl |

查看复制槽

postgres=# SELECT slot_name, slot_type, active FROM pg_replication_slots;
 slot_name | slot_type | active 
-------------+-----------+--------
 pg_slot_lzl | physical | f

3.设置从库primary_slot_name参数 primary_slot_name = 'pg_slot_lzl' 加入recovery.conf,并重启从库

4.查看复制槽

postgres=# select *,pg_xlogfile_name(restart_lsn)as current_xxlog from pg_replication_slots;
 slot_name | plugin | slot_type | datoid | database | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | current_xxlog 
-------------+--------+-----------+--------+----------+--------+------------+------+--------------+-------------+---------------------+--------------------------
 pg_slot_lzl | | physical | | | t | 12802 | | | 0/A002340 | | 00000002000000000000000A
--pg_xlogfile_name(restart_lsn)查看当前wal日志信息

查询冲突
#

什么是查询冲突？ 备库在查询时可能会遇到如下错误 ERROR：canceling statement due to confilct with recovery

为什么会产生冲突呢？我们细想一下，比如说备库正在执行基于某个表的查询（这个查询可能是应用产生的，也可能是手动连接进行的查询），这时主库执行了drop table操作，该操作写入wal日志后传至备库进行应用，为了保证数据一致性，postgresql必然会迅速回放数据，这时drop table和select就会形成冲突。如下图所示：

冲突场景：上面只介绍了1种查询冲突的情况。总结一下有以下几种情况

主库排他锁（包括显示LOCK命令和各种DDL）
主库vacuum清理死元组，从库如果正在使用该元组，就会产生冲突
主库删除了从库查询正在使用的表空间
主库删除了从库正在使用的数据库

试想在仅有主库的情况下：场景1：一个会话发起了drop table，此时发现有select语句正在执行，那么该会话只能等待select完成其事务。场景2：一个会话发起vacuum或后台自动vacuum，不会与当前库查询发生冲突，因为vacuum不会清理正在使用的元组。

从库的处理就不同。因为主库不知道从库的事务状态，而从库又需要与主库保持一致，所以才发生了“查询冲突”

查询冲突参数 hot_standby_feedback： 这个参数是查询冲突这个话题中提到最多的参数，下面我们详细探讨一下。我们假设在没有备库的情况下，会话1查询某行数据，会话2删除该数据，然后commit，此时会话2执行一次vacuum，我们知道这次vacuum并不会删除该行数据，因为会话1的事务还需要使用该元组，所以不会清理该元组。那么如果是主从呢？主库在准备进行vacuum时怎么知道从库还在进行查询，这就是设置该参数的意义，设置hot_standby_feedback参数之后备库会定期向主库通知最小活跃事务id（xmin）值，这样使得主库vacuum进程不会清理大于xmin值的事务。这个参数有利于减少冲突的发生，但并不能完全避免冲突，其实细想一下，这个参数只是减少了由于主库vacuum死亡元组造成的冲突，并不能解决排他锁造成的冲突。或者由于网络中断造成的冲突，假如主备之间的网络中断后，备库就无法向主库正常发送xmin值，如果时间够长，主库在这段时间内还是会清理无用元组，这样网络恢复后就可能发生上面的vacuum造成的冲突。值得注意的是hot_standby_feedback参数并不会覆盖主库上old_snapshot_threshold参数限定的值，old_snapshot_threshold参数限制了死亡元组的无限膨胀，当事务信息超过old_snapshot_threshold的限制时，依然会进行清理。

max_standby_streaming_delay：备机因为接收wal流日志产生查询冲突而取消查询之前的等待时间，设置该参数会在发生冲突时，备库查询不会立即取消，而是等待一个时间后如果还没结束再抛出报错。这个值的大小可以参考备库可能产生的长事务运行时间。

max_standby_archive_delay：备机因为处理归档的wal日志产生查询冲突而取消查询之前的等待时间，和上面的参数类似。

vacuum_defer_cleanup_age：指定vacuum延迟清理死亡元组的事务数，vacuum会延迟清除无效的记录，延迟的事务个数通过vacuum_defer_cleanup_age进行设置。即vacuum和vacuum full操作不会立即清理刚刚被删除元组

可以根据pg_stat_database和pg_stat_database_conflicts视图查看冲突发生的情况

其他相关参数
#

传输参数 max_wal_senders：使用wal sender获取wal的服务最大个数，也就是从库+baseback客户端的最大个数。pg9.6默认为0，pg10以后默认为10。 wal_send_timeout:wal传输xx秒失败后中断复制。该参数在从库宕机或者网络长期中断时，wal不会再尝试传输。默认60。0表示永不中断复制 track_commit_timestamp：记录事务的时间。默认是off。

主库参数 synchronous_standby_names：在主库上配置，备机的复制列表。有下面几种方式（s1，s2，s3代表备机的application_name，配置在recovery.conf中） synchronous_standby_names=‘s1’ 代表s1备机返回就可以提交。 synchronous_standby_names=‘FIRST 2 (s1,s2,s3)’ 代表s1，s2，s3三个备机中前两个s1和s2返回主库就可以提交。 synchronous_standby_names=‘ANY 2 (s1,s2,s3)’ 代表s1，s2，s3三个备机中任意两个备机返回主库就可以提交。 synchronous_standby_names=’*’ 代表匹配任意主机，也就是任意主机返回就可以提交。 wal_level： wal日志级别，这个参数决定了有多少信息写入wal日志，默认是replica，这种模式支持复制和wal归档，同时支持备库只读查询。 minimal：除了实例crash恢复需要的记录，其他不记录，比如CREATE TABLE AS，CREATE INDEX，CLUSTER，COPY可以跳过，该模式记录的日志信息不足以支持wal归档和流复制。 logic：在replica的基础上增加一些信息以支持逻辑解码，该模式会增大wal日志的数量，尤其是大量的update，delete操作的库。在9.6之前还有archive和hot_standby模式，映射到现在的replica模式。 synchronous_commit：前面已讲过，5种模式，各有优劣。 archive_mode ：archive_mode =on表示打开归档 archive_command：归档命令，pg归档直接调用操作系统命令。可以是简单cp命令到备份端 listen_addresses：监听地址。’‘表示所有IP都监听，默认为local

从库参数 hot_standby：on表示打开从库只读 primary_conninfo：从库连接主库的连接串。如primary_conninfo = ‘host=172.17.100.150 port=5432 user=lzl password=lzl’ trigger_file/promote_trigger_file：激活备库的激活文件。pg 12以前叫trigger_file，pg12及以后为promote_trigger_file trigger_file和pg_ctl promote在激活时都是一条命令就可以完成激活备库，前面已经具体演示过 wal_receiver_create_temp_slot：当没有slot时，临时起一个slot（命为primary_slot_name）。默认是off的。

参考文档：
#

《PostgreSQL修炼之道》 https://www.postgresql.org/docs/current/warm-standby.html

https://www.postgresql.org/docs/13/high-availability.html

https://www.postgresql.org/docs/current/runtime-config-replication.html

https://www.postgresql.org/docs/13/runtime-config-wal.html

https://www.postgresql.org/docs/current/app-pgbasebackup.html

https://www.postgresql.org/docs/current/hot-standby.html#HOT-STANDBY-CONFLICT

https://cloud.tencent.com/developer/article/1555354

https://www.modb.pro/db/29737

https://wiki.postgresql.org/wiki/Streaming_Replication

https://www.percona.com/blog/2018/09/07/setting-up-streaming-replication-postgresql/

https://www.cybertec-postgresql.com/en/the-synchronous_commit-parameter/

https://blog.csdn.net/m15217321304/article/details/88850146

https://blog.51cto.com/lishiyan/2460518?source=dra

PostgreSQL逻辑复制

Tue, 13 Aug 2024 00:00:00 +0000

什么是逻辑复制
#

pg逻辑复制基于逻辑解析（logicaldecoding），将wal日志流解析成一定格式输出（output），订阅节点收到解析后的数据进行应用。

逻辑复制不同于流复制（物理复制）基于实例级别主从库物理结构上就是一样，逻辑复制可以基于表级别选择性复制。逻辑复制（Logical Replication）在官方文档里专指”复制-订阅“模式，其实有许多工具可以基于逻辑解析做异构数据库间数据同步。

pg9.4 pglogical插件可以支持逻辑复制（https://github.com/2ndQuadrant/pglogical），pg10开始原生支持逻辑复制。

逻辑复制可以用于数据库升级、异构数据迁移、表级数据同步链路、订阅数据流等等

逻辑解析
#

逻辑解析可以将wal日志中的表数据变更解析成行数据流或sql文本，这些行数据流或sql文本可以被其他类型的数据库或软件消费。而具体的解析格式由outputplugin决定。

复制槽
#

在逻辑复制中，复制槽代表着数据变更流。跟物理复制槽一样，逻辑复制槽也可以保证复制异常中断后，相关的wal日志不被删除，以保证复制重连后仍然可以继续解析wal日志。一个数据库可以有多个复制槽，一个复制槽只有一个outputplugin，一个复制槽代表一条复制链路。复制槽本质上是用来管理复制链路的。不同于流复制可以没有复制槽，逻辑复制是必须有复制槽的。

output plugin
#

output plugin转换wal日志信息成复制槽所要的格式。pg中内置了一些outputplugin，也可以通过插件添加一些额外的outputplugin。每个逻辑复制槽都有一个output plugin用于解析wal相关工作。

outputplugin使用回调函数管理解析。比如OUTPUT_PLUGIN_BINARY_OUTPUT ，OUTPUT_PLUGIN_TEXTUAL_OUTPUT 用于设置out_type是二进制还是文本。还有一些回调函数用于通知plugin事务数据变更，并把事务排序。回调函数当然不用我们人为使用，一些内置的outputplugin已经打包好了。

每个output plugin都有一些不同的解析行为和输出格式

几个常见的outputplugin
#

test_decoding：这是一个outputplugin样例，相当于output plugin原始形态。官方文档说这是一个template，但是它仍然可以解析。这个output plugin是pg自带的，但需要在contrib中编译。

pgoutput：发布订阅模式的默认outputplugin。在发布订阅中，walsender进程使用该outputplugin逻辑解码wal日志。

decoder_raw:解析成sql文本格式。这个不是pg自带的，自行编译：https://github.com/michaelpq/pg_plugins/tree/main/decoder_raw

wal2json：这个outputplugin会将wal日志信息转化为json格式

有些其他的output plugin可参考：https://wiki.postgresql.org/wiki/Logical_Decoding_Plugins

有些国内也有厂商做了自己outputplugin。

几个output plugin和逻辑复制插件的关系：

pgoutput、test_decoding、wa2json上面已经介绍了

pglogical在pg9.4是pglogical replication的前身

BDR是2ndQuadrant开发，支持双向复制、DDL同步，功能更强大，BDR3.0开始闭源

几个能手动接收解析数据的函数和工具
#

pg_logical_slot_get_changes()函数展示解析数据并消费掉;

pg_logical_slot_peek_changes()函数展示解析数据不会消费掉；

pg_recvlogical，pg自带的工具，能消费复制槽内的数据，相当于逻辑复制的下游。对应物理wal接收工具为 pg_receivewal

逻辑解析测试1：观察用2个不同的output plugin解析数据
#

--创建两个逻辑复制槽，分别使用logical_test和logical_raw

lzldb=# select pg_create_logical_replication_slot('logical_test','test_decoding');

 pg_create_logical_replication_slot 

------------------------------------

 (logical_test,0/1756F50)

lzldb=# select pg_create_logical_replication_slot('logical_raw','decoder_raw');

 pg_create_logical_replication_slot 

------------------------------------

 (logical_raw,0/1756F88)

--只创建上游，slot是f状态

lzldb=# select * from pg_replication_slots; 

 slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size 

--------------+---------------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------+------------+---------------

 logical_test | test_decoding | logical | 16385 | lzldb | f | f | | | 558 | 0/1766878 | 0/17668B0 | reserved | 

 logical_raw | decoder_raw | logical | 16385 | lzldb | f | f | | | 557 | 0/1756F50 | 0/1756F88 | reserved | 

--创建一张表

lzldb=# create table tdecoder222(a int,b varchar(10));

CREATE TABLE

--尝试获得这个ddl

lzldb=# SELECT * FROM pg_logical_slot_get_changes('logical_raw', NULL, NULL, 'include-xids', '0');

ERROR: option "include-xids" = "0" is unknown

CONTEXT: slot "logical_raw", output plugin "decoder_raw", in the startup callback

lzldb=# SELECT * FROM pg_logical_slot_get_changes('logical_test', NULL, NULL, 'include-xids', '0');

 lsn | xid | data 

-----------+-----+--------

 0/17669C8 | 558 | BEGIN

 0/1776778 | 558 | COMMIT

--能看出decoder_raw完全没有解析ddl，logical_test只是获取了ddl的事物，没有ddl语句本身，相当于没解析ddl

--插入一条数据

lzldb=# insert into tdecoder222 values(1,'lzl'); 

INSERT 0 1

lzldb=# select * from pg_logical_slot_peek_changes('logical_test',null,null);

 lsn | xid | data 

-----------+-----+---------------------------------------------------------------------------

 0/1776890 | 560 | BEGIN 560

 0/1776890 | 560 | table public.tdecoder222: INSERT: a[integer]:1 b[character varying]:'lzl'

 0/1776900 | 560 | COMMIT 560

lzldb=# select * from pg_logical_slot_peek_changes('logical_raw',null,null);

 lsn | xid | data 

-----------+-----+----------------------------------------------------------

 0/1776890 | 560 | INSERT INTO public.tdecoder222 (a, b) VALUES (1, 'lzl');

--test_decoding解析了事物

--decoder_raw把事务解析成了sql语句

这个测试可以得出结论：

1.复制槽在f状态仍会解析，等待下游消费

2.每个output plugin都有一些不同的解析行为和输出格式

逻辑解析测试2：使用pg_recvlogical工具接收逻辑解析数据，模拟一个逻辑复制链路
#

--配置免密登陆

[pg@lzl ~]$ vi .pgpass

[pg@lzl ~]$ cat .pgpass

lzl:5410:lzldb:pg:pg

[pg@lzl ~]$ chmod 0600 .pgpass

--启动pg_recvlogical

[pg@lzl ~]$ pg_recvlogical -h lzl -p 5410 -d lzldb -U pg --slot=logical_raw --start -f recv.sql &

[pg@lzl ~]$ ps -ef|grep recv|grep -v grep

pg 7747 7355 0 21:40 pts/3 00:00:00 pg_recvlogical -h lzl -p 5410 -d lzldb -U pg --slot=logical_raw --start -f recv.sql

lzldb=# insert into tdecoder222 values(2,'qwe');

INSERT 0 1

lzldb=# update tdecoder222 set b='asd' where a=2;

UPDATE 1

[pg@lzl ~]$ tail -2f recv.sql

INSERT INTO public.tdecoder222 (a, b) VALUES (2, 'qwe');

--update没有正确解析

--给表加主键

lzldb=# alter table tdecoder222 add primary key(a);

ALTER TABLE

lzldb=# insert into tdecoder222 values(100,'lzl1');

INSERT 0 1

lzldb=# insert into tdecoder222 values(200,'lzl2');

INSERT 0 1

lzldb=# update tdecoder222 set b='lzlupdate' where a=200;

UPDATE 1

[pg@lzl ~]$ tail -3f recv.sql

INSERT INTO public.tdecoder222 (a, b) VALUES (100, 'lzl1');

INSERT INTO public.tdecoder222 (a, b) VALUES (200, 'lzl2');

UPDATE public.tdecoder222 SET a = 200, b = 'lzlupdate' WHERE a = 200;

–加了主键后update被decoder_raw正确解析

–没有主键不会正确解析，这跟replicaidentity复制标识相关，后面会介绍

逻辑复制的前置条件
#

1.参数
#

1.1基本的必要参数

wal_level。重启生效，默认是replica。wal_level参数必须是logical。logical不是把wal改成逻辑的，它表示在支持物理复制（replica）的基础上增加逻辑解析所必要的信息。在pg9.6以后只有minimal、replica、logical，信息量依次递增。
max_replication_slots。重启生效，在pg9.6版本以下默认值为0，pg10以上为10，10个一般都够了。与物理复制相同，逻辑复制一般也要用到复制槽。pg的备份、物理复制均可以占用到复制槽的数量。

1.2源端必要参数

max_wal_senders。重启生效，默认10。sender进程数限制，发布端的sender传递解析后的日志。一般一个逻辑复制槽对应了一个sender和一个worker。这个跟物理复制类似，一个物理复制对应一个sender和一个receiver。

1.3目标端必要参数

max_worker_processes。重启生效，默认8。工作进程数限制。并行进程（并行查询、并行统计信息收集等，这些并行进程由 max_parallel_workers限制）、逻辑复制工作进程（max_logical_replication_workers）和一些其他需要forkworker的程序均与该参数有关。应该设置为max_parallel_workers+逻辑复制应用端worker+其他后台worker。
max_logical_replication_workers。重启生效，默认4。逻辑复制工作进程数，包括逻辑复制的应用工作进程和表同步工作进程。
max_sync_workers_per_subscription。reload生效，默认2。逻辑同步新增表时同步工作进程，目前一张表只有一个并行。
以上三个参数是梯度式的max_sync_workers_per_subscription<max_logical_replication_workers<max_worker_processes。总之得有worker可用。

2 权限
#

复制用户的权限。逻辑复制的用户需要有replication权限。

ALTER ROLE <usename>WITH REPLICATION;

hba访问限制，允许下游使用复制用户访问数据库

host lzldb user1 172.17.100.150/32 md5

对于发布订阅模式。需要database上的create权限或ssuperuser权限。

在创建发布时只有fortable至少需要带create权限的表owner，其余发布都必须要superuser

在创建订阅时必须要superuser。

grant create on database lzl1db to owner1; 或者

alter user replicate1 superuser;

另外复制过程中表的读或写权限也是必要的。

pg间的逻辑同步——发布与订阅
#

pg的内置逻辑复制基于发布订阅模型。发布与订阅模式不是解析成sql应用。

发布
#

发布者可以有多个发布，每个发布可以有多个表。
发布时可以指定

for table 发布某些表，新增表需要显示添加ALTER PUBLICATION ADD TABLE。创建此发布至少是表的owner。

for all tables 发布database下的所有表，新增表自动发布。创建此发布必须是superuser

for all tables in schema 发布schema下的所有表，新增表自动发布。创建此发布必须是superuser。pg15开始支持

发布默认包含INSERT, UPDATE, DELETE, and TRUNCATE，也可以指定复制某些命令。不同步DDL。（官方文档原话。也就是说truncate在pg里面不算ddl，这个留坑后面再研究。truncate在mysql和oracle中是ddl）
只能发布基表；临时表、外部表、视图、序列等等都不能发布。分区表发布与pg版本和分区属性有关，pg15默认发布分区表所有分区
publish_via_partition_root。pg13开始支持。该发布参数表示分区表使用分区进行过滤（fales，默认）还是用户父分区进行行过滤。如果设置为true，那么支持了异构分区表逻辑复制，比如分区表到普通表的复制。true时不能进行truncate复制。

订阅
#

一个订阅只有一个发布者，但可订阅发布者上的多个发布。
订阅者可以有多个订阅，每个订阅都会从一个复制槽中接收数据。
一个订阅对应一个复制槽，这个复制槽在发布端。
在创建或删除订阅时，默认自动在发布者创建或删除复制槽。
创建订阅必须要superuser
DDL不会被同步，表必须是已建好的。
存量数据默认同步，存量数据通过copy的方式快照拷贝到订阅者
同步可以暂停和继续ALTER SUBSCRIPTION sub1 {ENABLE|DISABLE}
当发布新增表后，需要在订阅端refresh。alter subscription sub1 refresh publication
发布和订阅的表schema名、表名、字段名必须一致，字段类型可以不一致（只要能隐式转换成功），字段顺序可以不一致。
订阅还有些属性，比如二进制传输、流传输、同步提交、两阶段提交等

logicalreplication launcher是用来启动订阅端的worker进程的，只在启动时存在

/*-------------------------------------------------------------------------
...
 * IDENTIFICATION

 * src/backend/replication/logical/launcher.c
...
 * NOTES
 * This module contains the logical replication worker launcher which
 * uses the background worker infrastructure to start the logical
 * replication workers for every enabled subscription.
 *-------------------------------------------------------------------------

 */

发布订阅相关视图
#

pg_publication; –查看发布。发布本身是无状态的，复制槽是有状态的，所以没有pg_stat_publication

pg_publication_tables –查看发布的表，简单明了

pg_publication_rel –查看发布的表，都是id

pg_stat_subscription –查看订阅状态，pid是worker进程的pid

pg_subscription –查看订阅

pg_subscription_rel –查看订阅表，没有pg_subscription_tables。另外该视图可以查看订阅下面各个表的同步情况，这是复制槽视图做不到的

\dRp list replication publications

\dRs list replication subscriptions

创建一个发布和订阅
#

用专门的复制用户replicate1，在库lzldb下创建一个发布和订阅，实现逻辑复制表trep1

`角色`	`主机ip`	`端口`	`库名`	`schema`	`表名`	`复制用户`	`版本`
`发布节点`	`172.17.100.150`	`5410`	`lzldb`	`public`	`trep1`	`replicate1`	`pg13`
`订阅节点`	`172.17.100.150`	`5412`	`lzlbd`	`public`	`trep1`	`replicate1`	`pg13`

创建发布
#

#修改postgres.conf，wal_level参数重启生效

wal_level=logical 

#修改pg_hba.conf文件,reload生效

host lzldb replicate1 172.17.100.150/32 md5

--创建复制用户并赋权

create user replicate1 with password 'replicate1';

alter user replicate1 with replication;

grant create on database lzldb to replicate1;

--创建要复制的表并授权给复制用户

\c lzldb replicate1 --如果复制用户不是表的owner，应该授权grantselect on trep1 to replicate1

create table trep1(a int primary key,b char(10));

insert into trep1 values(1,'abc') 

--创建发布，用superuser用户也可以

\c lzldb replicate1

create publication pub_lzl1 for table trep1;

--查看发布。\dRp或pg_publication
lzldb=# select * from pg_publication;

 oid | pubname | pubowner | puballtables | pubinsert | pubupdate | pubdelete | pubtruncate | pubviaroot 

-------+----------+----------+--------------+-----------+-----------+-----------+-------------+-----------

 16400 | pub_lzl1 | 16392 | f | t | t | t | t | f

创建订阅
#

--创建表定义

create table trep1(a int primary key,b char(10));

--用superuser用户创建订阅

CREATE SUBSCRIPTION sub_test

CONNECTION 'host=172.17.100.150 port=5410 dbname=lzldb user=replicate1 password=replicate1'

PUBLICATION pub_lzl1;

lzlbd=# select * from pg_subscription; --查看订阅。\dRs或pg_subscription

 oid | subdbid | subname | subowner | subenabled | subconninfo | subslotname | subsynccommit | subpublications 

-------+---------+----------+----------+------------+--------------------------------------------------------------------------------+-------------+---------------+-----------------

 16394 | 16384 | sub_test | 10 | t | host=172.17.100.150 port=5410 dbname=lzldb user=replicate1 password=replicate1 | sub_test | off | {pub_lzl1}

lzlbd=# select * from trep1;--查看存量数据已同步

 a | b 

---+------------

 1 | abc

发布订阅模式测试1:truncate同步
#

lzldb=# truncate table trep1;

TRUNCATE TABLE

lzldb=# select * from trep1;

 a | b 

---+---

(0 rows)

lzlbd=# select * from trep1; --发布订阅模式，truncate可以同步

 a | b 

---+---

(0 rows)

发布订阅模式测试2:新增表同步
#

--在已有发布订阅下，新增一个表同步。lzldb是发布者，lzlbd是订阅者

lzldb=# create table tab_pk(a int,b varchar(10));

CREATE TABLE

lzldb=# alter table tab_pk add primary key(a);

ALTER TABLE

lzldb=# alter publication pub_lzl1 add table tab_pk;

ALTER PUBLICATION

--发布端新增表后需要在订阅端执行refresh，refresh默认同步存量数据

lzlbd=# alter subscription sub_test refresh publication; 

ALTER SUBSCRIPTION

lzlbd=# select * from pg_subscription_rel ;

 srsubid | srrelid | srsubstate | srsublsn 

---------+---------+------------+-----------

 16394 | 16389 | r | 0/15F2898

 16394 | 16400 | d | 

--订阅的状态码： i = 初始化， d =正在复制数据， s = 已同步， r =准备好(普通复制)

--此时表tab_pk数据并没有同步，因为订阅端复制用户缺少查询表的权限

lzldb=# grant select on tab_full to replicate1;

GRANT

lzlbd=# select * from pg_subscription_rel ;

 srsubid | srrelid | srsubstate | srsublsn 

---------+---------+------------+-----------

 16394 | 16389 | r | 0/15F2898

 16394 | 16400 | r | 0/172D830

--订阅为ready状态，新增表同步完成

replica identity复制标识
#

复制标识写进wal日志以标识一行数据。无论是发布订阅还是第三方逻辑同步工具，都需要定位表中的行，以标识update、delete到底作用在下游的哪一条数据。 pg中可以设置4种复制标识模式。

default(d) 非系统表的默认标识。表有主键就用主键，如果没有主键就是nothing
index(i) 将一个非空唯一索引作为标识。必须是非空且唯一，这样才能标识一行。如果只是唯一，可以有多个空值。其实也可以显示指定主键为index模式。
full(f) 将行的所有列作为标识。full模式会增大wal日志量
nothing(n) 系统表的默认模式，没有标识，update、delete无法作用到下游

查看表的复制标识：
select relname,relreplident from pg_class where relname='tabname1';
当表的复制标识是i时，查看索引是否是复制标识
\d tabname
select rel.relname,idx.indisreplident from pg_index idx ,pg_class rel where idx.indexrelid=rel.oid and relname='idx_1';

修改表的复制标识：

ALTER TABLE tab1REPLICA IDENTITY { DEFAULT | USING INDEX index_name | FULL | NOTHING };

复制标识测试1：将一个没有主键的表的复制标识设置为非空唯一索引
#

lzldb=# create table tab_idx(a int,b varchar(10));

CREATE TABLE

lzldb=# select relname,relreplident from pg_class where relname='tab_idx';

 relname | relreplident 

---------+--------------

 tab_idx | d

lzldb=# create unique index idx_1 on tab_idx(b);

CREATE INDEX

lzldb=# alter table tab_idx alter b set not null; --当做复制标识的索引必须是非空唯一索引

ALTER TABLE

lzldb=# select rel.relname,idx.indisreplident from pg_index idx ,pg_class rel where idx.indexrelid=rel.oid and relname='idx_1';

 relname | indisreplident 

---------+----------------

 idx_1 | f

lzldb=# alter table tab_idx REPLICA IDENTITY using index idx_1; --修改表的复制标识

ALTER TABLE

lzldb=# select rel.relname,idx.indisreplident from pg_index idx ,pg_class rel where idx.indexrelid=rel.oid and relname='idx_1';

 relname | indisreplident 

---------+----------------

 idx_1 | t

lzldb=# \d tab_idx --pg_index或者\d查看索引复制标识，\d只能查看显示修改的索引复制标识

 Table "public.tab_idx"

 Column | Type | Collation | Nullable | Default 

--------+-----------------------+-----------+----------+---------

 a | integer | | | 

 b | character varying(10) | | not null | 

Indexes:

 "idx_1" UNIQUE, btree (b) REPLICA IDENTITY

复制标识测试2：full模式，多条重复数据时，是否可以正常同步
#

--发布端执行一下命令

lzldb=# create table tab_full (a int,b varchar(10)); --添加一个无主键和非空索引的表同步

CREATE TABLE

lzldb=# insert into tab_full values(1,'abc'); --插入相同的5条数据

INSERT 0 1

lzldb=# grant select on tab_full to replicate1;

GRANT

lzldb=# alter publication tab_full add table tab_pk;

ALTER PUBLICATION

--

lzlbd=# alter subscription sub_test refresh publication; 

ALTER SUBSCRIPTION

lzlbd=# select ctid,* from tab_full ;

 ctid | a | b 

-------+---+-----

 (0,1) | 1 | abc

 (0,2) | 1 | abc

 (0,3) | 1 | abc

 (0,4) | 1 | abc

 (0,5) | 1 | abc

lzldb=# delete from tab_full where ctid='(0,2)';

ERROR: cannot delete from table "tab_full" because it does not have a replica identity and publishes deletes

HINT: To enable deleting from the table, set REPLICA IDENTITY using ALTER TABLE.

lzldb=# update tab_full set a=2 where ctid='(0,5)';

ERROR: cannot update table "tab_full" because it does not have a replica identity and publishes updates

HINT: To enable updating the table, set REPLICA IDENTITY using ALTER TABLE.

--当表的replica identity是d(default)时，没有主键就是nothing。nothing无法复制delete和update。

lzldb=# alter table tab_full replica identity full;

ALTER TABLE

lzldb=# delete from tab_full where ctid='(0,2)'; --复制标识设置为full后，删除成功

DELETE 1

lzlbd=# select ctid,* from tab_full ; --

 ctid | a | b 

-------+---+-----

 (0,2) | 1 | abc

 (0,3) | 1 | abc

 (0,4) | 1 | abc

 (0,5) | 1 | abc

lzldb=# update tab_full set a=2 where ctid='(0,5)'; 

UPDATE 1

lzldb=# select ctid,* from tab_full; 

 ctid | a | b 

-------+---+-----

 (0,1) | 1 | abc

 (0,3) | 1 | abc

 (0,4) | 1 | abc

 (0,6) | 2 | abc

lzlbd=# select ctid,* from tab_full ; 

 ctid | a | b 

-------+---+-----

 (0,3) | 1 | abc

 (0,4) | 1 | abc

 (0,5) | 1 | abc

 (0,6) | 2 | abc

–这个例子可以证明3个点

–1.当复制标识为d(default)时，默认用主键，如果没有主键就是nothing

–2.nothing不能复制delete和update

–3.full时的重复数据也可以正常逻辑复制，虽然数据行的ctid不一样，但是也达到了复制目的

第三方同步软件
#

第三方同步软件已经有比较成熟的方案，而且使用比较多，比如ogg、dts、ktl等等

这些同步软件非常灵活，他们可以实现真正的异构同步，可以从pg库同步到不同的数据库或者kafka、大数据消费平台等等。

当然也可以从其他架构的数据平台同步到pg库里，比如如今场景比较多的oracle到pg的同步。

因为我们这里主要讨论pg数据库本身，当pg充当下游入库时，只是一些数据写入问题，问题非常少，不会有逻辑解析、复制槽等等问题，所以这一小章节不讨论pg作为异构同步下游的情况，只观察和总结pg作为上游往异构数据库同步的场景。这些第三方软件一般都利用了pg自身的逻辑解析，自行指定outputplugin并自动创建复制槽和复制链路，有些软件自动创建了订阅，而有些就没有订阅只有复制槽。

前面已经了解了逻辑解析、outputplugin、复制槽、replicaidentity、复制的前置条件等知识点，下面模拟一个pg到oracle的同步，直接将前置条件配置好开始同步。

创建ogg同步pg到oracle的同步
#

安装软件：

ogg for oracle：Oracle GoldenGate 21.3.0.0.0 for Oracle on Linux x86-64

ogg for pg ：Oracle GoldenGate 21.3.0.0.0 for PostgreSQL on Linux x86-64

oracle ：11.2.0.4

pg ：13.10

安装步骤：

ogg的安装和部署就不介绍了，我也是参照文章的安装步骤一步步搭建，安装文章参考：https://liuzhilong.blog.csdn.net/article/details/129252320?spm=1001.2014.3001.5502

同步架构图：

lzldb=# select * from pg_replication_slots where slot_name='ext_pg_5d4b1d39f7494f79';

-[ RECORD 1 ]-------+------------------------

slot_name | ext_pg_5d4b1d39f7494f79

plugin | test_decoding --ogg默认使用test-decoding

slot_type | logical

datoid | 16385

database | lzldb

temporary | f

active | t --只要ogg extract是running的，复制槽就是active状态

active_pid | 3509

xmin | 

catalog_xmin | 591

restart_lsn | 0/17F3E38

confirmed_flush_lsn | 0/17F4020

wal_status | reserved

safe_wal_size | 

select * from pg_stat_replication

-[ RECORD 2 ]----+------------------------------

pid | 3509

usesysid | 10

usename | pg

application_name |GoldenGateCapture

client_addr | 127.0.0.1

client_hostname | 

client_port | 43665

backend_start | 2023-02-28 15:12:17.350469+08

backend_xmin | 

state | streaming

sent_lsn | 0/17F4140

write_lsn | 0/17F4020

flush_lsn | 0/17F4020

replay_lsn | 

write_lag | 

flush_lag | 

replay_lag | 

sync_priority | 0

sync_state | async

reply_time | 2023-02-28 16:39:44.986625+08

--replay_lsn没有值

--连lag都没有值

逻辑复制监控
#

逻辑复制延迟监控有一个重要的手段是从复制软件看延迟。如果没有就只有从复制槽视图查看，复制槽视图的信息是比较多的，比如复制槽是否active就直接代表了复制链路是否在同步。

复制槽视图对于逻辑复制监控非常重要，发布订阅的一些额外监控前面已介绍过，这里着重介绍宽泛的逻辑复制的监控

pg_replication_slots
#

复制槽视图，每个复制槽的信息和一些复制槽状态。手工创建复制槽或者工具、订阅自动创建了复制槽，都会在这里展示

slot_name	复制槽名
plugin	逻辑复制槽output plugin的名字，如果是空那么就是物理复制槽
slot_type	physical or logical
datoid	逻辑复制槽的database id
database	逻辑复制槽的database
temporary	是否是临时复制槽。临时复制槽不会写到磁盘，会话结束临时复制槽自动删除。pg_basebackup默认使用的就是临时复制槽
active	复制槽状态 t or f。如果是f，需要尽快考虑把复制链路拉起或者删除，因为可能阻碍wal日志删除导致主库磁盘打满，这个跟参数max_slot_wal_keep_size相关
active_pid	使用复制槽的walsender pid。当复制槽状态是t的时候，才有walsender pid
xmin	复制槽需要持有的最小事务id
catalog_xmin	复制槽需要持有的catalog最小事务id
restart_lsn	slot需要保留的wal的位置lsn号，以确保下游消费端需要的wal不会被清理。max_slot_wal_keep_size 参数是slot需要保留wal的最大大小，超过这个值wal也能被删除，默认值-1表示不会清理。这个值表示下游最新checkpoint消费后的lsn位置，可以帮助定位复制链路的延迟
confirmed_flush_lsn	逻辑复制下游确认接收的lsn。物理复制槽为空
wal_status	`被这个复制槽申明的wal的状态` reserved 代表复制槽保留了wal，wal没有超过max_wal_size(自动检查点间距） extended 代表复制槽保留了wal，wal超过了max_wal_size，但是复制槽仍保留了wal。此状态的wal仍在wal_keep_size或max_slot_wal_keep_size内 unreserved 复制槽不再保留需要wal，在下个checkpoint即将删除wal lost 复制槽需要的wal已被清理，复制槽已无效 `The last two states are seen only when max_slot_wal_keep_size is non-negative。比较好理解，毕竟max_slot_wal_keep_size是判断是否可以删除wal的标准。如果没有删除slot wal的机制，那就不会出现ureserved和lost两种状态。` `If restart_lsn is NULL, this field is null.也比较好理解，如果wal的lsn都没有就不知道wal保留的位置，也无法判断wal是否超过了wal_keep_size或max_slot_wal_keep_size`
safe_wal_size	到在被删除WAL文件之前，可以写入的WAL字节数。如果这个值是负数或者是0，意味着已经超过了max_slot_wal_keep_size设置的值，只要做检查点，就会删除wal文件，这样使用插槽的备库就必须重建了

pg_stat_replication
#

与其说是复制状态，其实walsender状态更准确。该视图展示每个walsender的状态，一个walsender一条记录。

如果pg_replication_slots中有而pg_stat_replication中没有，那么说明walsender不在了，逻辑复制挂了，pg_replication_slots active应该是f
如果pg_replication_slots中没有而pg_stat_replication中有，那么说明这是个不带复制槽的物理复制

没有复制槽也可以有replicationstat信息，有walsender的复制槽也需看该视图，因为该视图比pg_replication_slots揭示更多复制状态信息

所以当复制槽没有挂时，pg_stat_replication对于监控逻辑复制延迟非常重要

pid	walsender pid ，同pg_replication_slotsactive_pid
usesysid	连入这个walsender的user oid，也就是下游使用的复制用户oid
usename	连入这个walsender的usename
application_name	下游的的应用程序名称。如果是订阅，那么就是订阅名。如果是pg_recvlogical就是pg_recvlogical
client_addr	下游的IP，如果是空就是本地socket连接
client_hostname	下游的主机名
client_port	下游的端口，如果是-1就是本地socket连接
backend_start	backend启动时间，也就是下游连入walsender的时间
backend_xmin	hot_standby_feedback打开时，standby的xmin。这个明显是物理复制的
state	状态比较简单易懂 startup: walsender正在启动 catchup: walsender正在追主库日志 streaming: walsender已经追上了主库日志，正常复制状态 backup: walsender在发送备份，这个状态出现在备份使用的walsender stopping: walsender正在停止
sent_lsn	发送的lsn
write_lsn	下游write到磁盘的lsn
flush_lsn	下游flush到磁盘的lsn
replay_lsn	下游重放的lsn
write_lag	主库flush wal和下游write之间的日志lag
flush_lag	主库flush wal和下游flush之间的日志lag
replay_lag	主库flush wal和下游relay之间的日志lag
sync_priority	同步优先级
sync_state	同步状态
reply_time	上次答复时间

sent_lsn、write_lsn、flush_lsn、replay_lsn的关系
#

上面很好的展示了sent_lsn、write_lsn、flush_lsn的层级关系

这些监控指标看上去很像流复制的，对于逻辑复制来说sent_lsn、write_lsn、flush_lsn也一般都有值

但是在逻辑复制不清楚下游是什么东西的情况下，replay这个日志回放动作可能是没有的，所以逻辑复制可能没有replay_lsn

但是有一个东西是确认有效的，就是sent_lsn

看完pg_replication_slots和pg_stat_replication视图监控，发现都没有展示日志解析延迟，最多只能看到日志传输延迟

pg_stat_replication_slots
#

这个视图从pg14开始才有，这个视图专门监控逻辑复制槽状态，可以额外监控spill的状态。pg13只有查看pg_replslot目录。spill后面会介绍

逻辑复制槽的事务快照和pg_logical目录
#

复制槽所需的事物快照会持久化到磁盘，源码在snapbuild.c中

void
SnapBuildSerializationPoint(SnapBuild *builder, XLogRecPtr lsn)
{
if (builder->state < SNAPBUILD_CONSISTENT)
SnapBuildRestore(builder, lsn);
else
SnapBuildSerialize(builder, lsn);
}

snap持久化有2种行为：一种是restore从磁盘加载到内存，一种是serialize从内存持久化到磁盘

事物快照持久化：

SnapBuildSerialize(SnapBuild *builder, XLogRecPtr lsn)
...
sprintf(path, "pg_logical/snapshots/%X-%X.snap",
(uint32) (lsn >> 32), (uint32) lsn);
...
else if (ret == 0)
{
/*
 * somebody else has already serialized to this point, don't overwrite
 * but remember location, so we don't need to read old data again.
 *
 * To be sure it has been synced to disk after the rename() from the
 * tempfile filename to the real filename, we just repeat the fsync.
 * That ought to be cheap because in most scenarios it should already
 * be safely on disk.
 */
fsync_fname(path, false);
fsync_fname("pg_logical/snapshots", true);

builder->last_serialized_snapshot = lsn;
goto out;
}

事物快照加载到内存：

SnapBuildRestore(SnapBuild *builder, XLogRecPtr lsn)
...
if (builder->state == SNAPBUILD_CONSISTENT)
return false;

sprintf(path, "pg_logical/snapshots/%X-%X.snap",
(uint32) (lsn >> 32), (uint32) lsn);

fd = OpenTransientFile(path, O_RDONLY | PG_BINARY);

逻辑复制槽需要的事物在未提交以前，会将事物脏数据和未消费的数据存放在pg_logical/snapshots/ 下面。在提交数据或启动复制槽后交给reorderbuffer：或者清理复制槽后，数据被释放

我的环境有一个长时间未启用的slot，它的restart_lsn为0/1776858

postgres=# select slot_name,plugin,slot_type,database,active,restart_lsn from pg_replication_slots where slot_name='logical_test';
 slot_name | plugin | slot_type | database | active | restart_lsn 
--------------+---------------+-----------+----------+--------+-------------
 logical_test | test_decoding | logical | lzldb | f | 0/1776858

pg_logical/snapshots/下最旧的snapshot就是它

[pg@lzl snapshots]$ ll
total 300
-rw------- 1 pg pg 144 Feb 23 20:410-1776858.snap
-rw------- 1 pg pg 144 Feb 23 20:44 0-1776900.snap
-rw------- 1 pg pg 144 Feb 23 20:45 0-1776938.snap

删除不要的复制槽

select pg_drop_replication_slot('logical_test');

等了几分钟snap被删除

[pg@lzl snapshots]$ ll 0-1776858.snap
ls: cannot access 0-1776858.snap: No such file or directory

逻辑解析工作内存和溢出到pg_replslot
#

logical_decoding_work_mem
#

pg13以前，逻辑解析的最多会在内存中保留4096条变更（max_changes_in_memory代码中写死），超过4096条变更，事务数据会写入磁盘

pg13引入参数logical_decoding_work_mem。逻辑解析使用的工作内存，所有walsender解析都会使用这个共享内存区。如果逻辑解析持有的数据大过该内存值，会写入磁盘。逻辑解析工作内存大小默认64m。

总结
#

逻辑复制通过复制槽管理，一个复制槽一个walsender进程，一个outputplugin
output plugin决定了逻辑解析后的数据输出形态，在创建复制槽时指定
复制标识replicaidentity建议优先:主键->非空唯一索引->full
发布订阅模式是pg内置的逻辑复制，默认使用pgoutput。发布可以单独使用
发布端进程是walsender，订阅端进程是worker。需要关注各自进程的参数
逻辑复制第三方软件较多，他们一般都使用pg逻辑解析这套体系
监控复制链路需要关注pg_replication_slots,pg_stat_replication
pg_logical目录会存放事务解析的元数据snap，等待事务提交后解析
pg_replslot目录会存放超过logical_decoding_work_mem的事物信息，称为spill

参考资料
#

书：《postgreSQL实战》

官方文档：

PostgreSQL: Documentation: 15: Chapter 49. Logical Decoding

PostgreSQL: Documentation: 15: 49.1. Logical Decoding Examples

PostgreSQL: Documentation: 15: pg_recvlogical

PostgreSQL: Documentation: 14: 52.81. pg_replication_slots

PostgreSQL: Documentation: 13: 19.6. Replication

PostgreSQL: Documentation: 13: 48.6. Logical Decoding Output Plugins

PostgreSQL: Documentation: 15: 31.1. Publication

PostgreSQL: Documentation: 15: 31.2. Subscription

PostgreSQL: Documentation: 15: CREATE PUBLICATION

Logical replication internals | Select * from Adrien

An Overview of Logical Replication in PostgreSQL - Highgo Software Inc.

从实际案例聊聊逻辑解码

折磨许久的逻辑解码异常

Monitoring replication: pg_stat_replication - CYBERTEC

其他资料：

https://zhuanlan.zhihu.com/p/311496301

A Guide to PostgreSQL Change Data Capture - DZone

Change data capture in Postgres: How to use logical decoding and wal2json - Microsoft Community Hub

PgSQL · PostgreSQL 逻辑流复制技术的秘密 · 数据库内核月报 · 看云

剖析postgresql逻辑复制原理_postgresql 逻辑复制_麒思妙想的博客-CSDN博客

http://pigsty.cc/zh/blog/2021/03/03/postgres逻辑复制详解/

Logical replication and logical decoding - Azure Database for PostgreSQL - Flexible Server | Microsoft Learn

读书笔记——《educated 》和《atomic habits》

Tue, 13 Aug 2024 00:00:00 +0000

其实很早之前就想写写这两本书的读后感了。我很喜欢看书，但是极其讨厌写作，坚持写博客对于我来说简直就是神迹。我喜欢看书因为我喜欢和相信教育的力量。对于我有多讨厌写作，我想讲个我的小故事。

我不喜欢写作文
#

我不喜欢写作可以说是天生的。从小学开始，我就不写日记、作文。每次寒暑假作业都要每天一篇日记，我一篇也不会写。我还记得开学的时候要交暑假作业，老师威胁我说你补不齐就上不了学，可是我最后还是没有写一个字，坐在教室照常上课。后来我们班主任老师不知道是什么任务，要交几个典型缺点的孩子改正缺点的方法，全班只有4、5个人被选中，有个是体育不好的、有个是脾气不好的，而我是那个作文不好的！关键是要写一篇改正缺点的作文！我不会写作文为什么要我写改掉不会写作文的作文啊？？？拖了2周，其他同学都交了，我硬是一个字没憋出来。班主任亲自指导我，她说你平时走在路上看到任何东西都可以写成句子，比如看到蓝天，你内心可以造一个“这个天空是万里无云的”这种句子，时常锻炼造句能力可以运用到写作中，你也可以想想还有没有其他办法可以改掉不爱写作的坏毛病。又过了一周，我把她给我说的话原封不动的写了进去，我能看到她眼里的无奈。后来，到了初中，我机智的跟语文科代表搞好了关系，让她收作业的时候，不要把我的名字写到未交作业名单上去，于是我躲过了3年初中。再后来，到了高中，有次以自己的方式尬写了一篇作文，拿了30分给我心理造成了沉重打击，于是每次月考考语文的时候，我都不会写作文，我想反正是模拟又不是高考，60分哥们不要了。最后我在高考和前2次模拟的时候，像八股文一样把屈原李白硬往作文模板里套，我发现没有套不进去的，于是混过了高考作文这个坎。大学就不用说了，我的手已经不会拿笔了。是的，就是这种奇特的写作心理，我讨厌作文。但是工作后我逐渐明白，好记性不如烂笔头的道理，看再多书也得自己沉淀。理想、家庭、工作的压力使我必须要改变自己，我需不需要这个技能似乎不重要，社会需要这个技能我就应该尝试改变。写东西不仅可以鞭策自己，也是一种记录成长、记录人生的方式。甚至我自己写的技术文章，我几年后还得回来仔细看，仔细复习。

读点原著有利于身心健康
#

《educated》和《atomic habits》我都是看的英语原版的，自己本身还是有一丢丢英语的底子，加上那段时间考研，我想提升一下自己的英语阅读能力，所以选择了英语原版著作。刚开始读英语原著，还是很困难的，很多单词都不认识，不认识的就查翻译标注在书上，读的十分缓慢。但随着阅读的深入，标注的单词越来越少。并不是我很快的记住了很多不会的单词，而是一本书，有些重要单词是反复出现的，而有些出现次数很少也不会影响阅读，还有刚开始你并不知道书要讲什么，理解书的内容延迟比较高，后面你知道这本书将要讲什么时候，阅读自然会快很多。比如ridge这个单词，刚开始出现频率非常高，后来就记住这个单词了，有些类似的单词我也记不住了，但是我知道他们是某个地理名词，山顶、谷底、田垦什么的，即时没记住也不影响我继续阅读。英语原著都是这样，刚开始看起来比较困难，越往后读越快。

educated
#

《educated》的中文书名《你当像鸟飞往你的山》，我十分想吐槽这个标题，educated是全书的精神内涵，在书的最后还终极点题call it educated，十分的精彩。这个中文标题像shit一样，毫无本书的精髓。作者的亲身经历就是一个传奇，从美国的某个角落山咔咔里走出来的孩子，靠着自己的努力读书读到剑桥。他父亲是一个没有文化、反社会、没有基本物理认知的人，自身的无知也导致家人受伤甚至残疾，而且不赞同孩子去读书，甚至认为读书是政府的洗脑方式，有太多奇葩行为。他哥哥也有人格问题，把她的头按在肮脏的马桶上让她求饶，第二天跟任何事都没发生一样继续当她的好哥哥…后来作者读书靠找到出路，最后也不想回到那个山谷。看到最后我总是想起我自己的经历，当然我没有那么极端的环境，也没有那么传奇的经历，可是我好像可以理解educated后，理解家人的行为总觉得不太自然。不是说上个大学飘了，而是这个代沟是真实存在的。我非常认同education的重要性，如果不是我家人砸锅卖铁全力支持我读书，我们的家的条件根本不会改变。如果你真的沉溺于贫穷，你才会知道摆脱贫穷的欲望有多么强烈，而教育是我们这类人几乎唯一的出路。《educated》是一本好书，文笔清晰、舒适的语句结构、适合现代人的阅读节奏、精彩的故事、深刻的主旨，作为人生第一本英语原著非常合适。

atomic habits
#

《atomic habits》中文名《原子习惯》，我也忘记了是怎么找到这本书的，它改变了对行为的认知。养成良好的习惯其实并不困难，只是绝大多数人不知道怎样去养成良好的习惯。很多人都曾经说过，我要在几个月内看几本书、跑多少步减多少肥，但是他们很难完成。养成好习惯需要你真的喜欢这个习惯、改变自己的思维、减少做这个动作的复杂度、把不利因素放远一点、形成奖励机制等等。你想成为某种人时，不应该想着如何成为这种人，而是要思考这种人正在做什么，你应该学着做。比如说戒烟，如果的大脑认为你现在处于戒烟状态，是很难戒烟的，如果一个人给你一根烟，你说你在戒烟，他可能几句话就能让你把烟抽起来。但是如果你本身就认为你不抽烟，注意是你内心的真实想法，别人给你烟的时候，你会说你不抽烟，这烟可能就不用抽了。还有一些小细节，比如养成晚上读书的习惯，你需要戒掉刷手机的习惯。你需要把书从书柜放置在床头，这样更方便你拿取，把手机放在床尾，让起床成为拿手机的屏障，这样更有利于你随手拿书而不是手机。如果拿起书还是有困难，转换一下思想，“看书”这个行为可能困难，但是把这个动作拆解，“把书拿在手上”或者翻看第一页“成为你的思想目标，看书的启动动作很简单，也比较容易完成，看完第一页后再考虑之后的事，实际上你看了第一页很难不看第二页。当然还有很多非常好的关于养成好习惯和扔掉坏习惯的建议，字字珠玑引人入胜。看完《atomic habits》后，如果我想要某种习惯，我会先考虑书中的指导然后再计划如果实施，而不是心血来潮。

最后
#

At last，这2本书对我自身的影响非常大，一部传奇自传、一部颠覆行为的书，它们都不是那种看完一段时间后就会忘光光的著作。对于培养读书这个习惯的起步书籍非常合适，特别是想看英语原著的小伙伴，真不推荐《傲慢与偏见》、《百年孤独》这些著作，虽然他们经典，但是对于读者的影响程度非常低，而且著作时间太久远，有些英语单词和语法太古老了，不太适合刚接触英语著作的人。如果从《atomic habits》这本书来看这个观点，看这些英语经典著作不仅难度较高、而且没有利己收益，很难养成习惯。

读书笔记——《Sapiens : A Brief History of Humankind》

Tue, 13 Aug 2024 00:00:00 +0000

这是一本我读了很久的书。书很厚，书所涉猎的内容也很广，原著啃起来还是有些困难，不过值得庆幸的是最终还是读完了，就在今天(2023年2月），成就感拉满。

《Sapiens : A Brief History of Humankind》中文译名《人类简史：从动物到上帝》。为什么总是感觉中文译名怪怪的，找不到重点。这本书的重点是人类历史本身，是一篇全面介绍人类文明发展的宏伟史书。我本身比较喜欢了解一些人类历史方面的东西，沉浸于这种历史的承重感和人类文明发展的生命力。

认知革命与虚构
#

一般人类史观点认为，人类第一次重要进化或者revolution是学会使用工具。就像《太空漫游》里那样，几只猩猩拿着骨头敲打，经典bgm响起~~不过这是科幻。《人类简史》认为人类的第一次重要revolution，是cognitive revolution认知革命，认知革命是区分人和动物的重要标志。人类学会直立行走不仅解放了双手，其实更重要的是解放了思想。四肢奔跑的动物，之所以没有进化，是因为残酷的自然环境让它们必须拥有更强壮的身体和四肢才能跑的快，而直立行走显然是跑不快的，群居和使用工具使我们不需要太快的奔跑。但是群居和工具不是智人独有的属性，许多动物都是群居，猩猩也会使用工具。但是智人学会了制造武器、船、更多人数的群居生活，他们从非洲走到中东，到欧洲和比他们强壮的多的尼安德特人交战并最终占领领地，走向远东，跨越白令海峡到达美洲，甚至坐船到澳大利亚。而这种制造更复杂的工具和交流的能力，就是认知革命带来的。

尼安德特人本身已经灭绝，但是最新的研究发现，绝大部分人类拥有少量的尼安德特人基因，除了非洲土著没有。这说明尼安德特人并没有被智人灭绝，少数尼安德特人与智人融合了，并走向了世界。这也是佐证人类非洲起源的重要证明。

书中对认知革命讲了一个经典的例子：假设河边有一只狮子，一个智人看到了那只狮子并把这件事告诉了其他人，那么其他人会在大脑中构造”河边有狮子“这样一个事情，即便大家不知道那里到底有没有狮子。这个事情的前提是智人必须学会构思，更重要的是学会了这项技能后，便有了后来的语言交流、虚构、谎言、权利、社会结构···尼安德特人显然比智人交流的信息要少的多。

认知革命对文明的发展影响非常大，它可以构造更多并不存在的东西，比如神、宗教、权利、金钱、社会结构、王朝···。比如公司，公司实际上是也是一种社会结构，它其实并不存在，公司也可以是文件袋里带着章的4A纸，但那只是一张白纸而已。员工认为公司存在是因为他们大脑相信公司存在，所有人都相信公司存在，但是公司实际上只是人脑中的一种虚构，这个真实的世界是不存在公司这个实体的。

货币
#

金钱是怎么来的？在没有金钱的时代，一个稳定的社会结构出现以物换物的交易，但是当交易种类增多后，以物换物的等价交换等式数会程指数上涨。当鞋子和钉耙进行交易时，这是很简单的一物换一物，再增加一个物品驴，我们也可以有3中交换等式鞋-耙、耙-驴、鞋-驴，如果货物再增多，这个交换等式数就是不排列组合数，这还不考虑多物换一物的情况。这时一个中介物——金钱出现了，它将这个问题迎刃而解，所有东西只需要与金钱划等式即可。金钱充当了所有物品的等价交换物，我们的交易便利性得到极大缓解。最初的金钱种类非常多，常见的是贝壳，如果贝壳过于方便获取，那么有人就可以买下市场上的所有东西，所以以贝壳为金钱的文明一般都在内陆。由于金钱大家都揣兜里买东西或者藏家里囤着，并担心过于廉价的方式获得货币会冲击市场，所以金子这种稀有、不宜变质、难以开采的矿石资源成为了人类长时期的重要货币。在古代欧洲，很多国家的国王都会发行印有自己头像或logo的金币，以至于欧洲的金币种类超级多。而古代中国还是有些不一样，刚开始像三星堆文明发掘出的贝壳、再到春秋战国的青铜货币、再到朝代更迭期金银铜、交子。我们没有像欧洲那样一直使用金子，主要还是人口太多而金存量太少，导致金子价值过高，需要一些其他金属来制造货币梯度缓和交易量级差距。

书中还有一个很棒的观点：金钱和宗教都有一定的传播性，金钱与宗教本质上没有什么区别，他们都是人类构想出来的，虚构的东西。他们的唯一区别在于：宗教是让你知道你要相信什么，而金钱是让你知道别人相信什么。

哥伦布和郑和
#

大航海时代，工业革命早期。欧洲人热衷于探索世界未知领域。在欧洲人知道地球是圆的以后，由于没有很好的测绘条件，哥伦布从欧洲出发往西走，准备到印度india。他们穿越大西洋来到了一片土地，并见到了当地人，他们以为到了印度，把那些人叫indian，中文翻译印第安人。直至今日漂亮国的indian还是两个含义：印度人或印第安人。欧洲人知道了这个世界还有很多角落我们未曾驻足（至少是较现代的文明未曾驻足），他们重绘了世界地图，把未知的领域用海怪和巨兽来代替。这种地图现在仍被广泛运用于游戏地图，比如说游戏《文明6》的地图，未探索领域用海怪地图展示，等待发现与探索。欧洲人热衷于发现新的土地，随后南美、新西兰、澳大利亚、海洋上的许多小岛被发现和插旗。如果本地文明过于落后，比如阿兹特克文明、印第安文明、毛衣文明、达斯玛尼亚文明等等都遭到残忍屠杀，土地皆被白人占领。

当阿兹特克文明遭遇到穿着泛光的铁铠甲和锋利铁剑的西班牙人，他们以为那些人是神，他们无法理解坚硬的衣服和武器，那一定是神派来的，而后却被”高等文明“欺骗和屠杀。

郑和的舰船被称为dragon boat（原文是这样写的，甚至还配了图，我觉得可能是搞错了或者西方人认为带有龙头的船都是dragon boat），要比哥伦布发现新大陆的船大几倍，比哥伦布还早1、2百年，郑和舰队用更先进的科技发现了新的土地，但是并没有去占领，而是与当地人贸易。书中的观点认为，欧洲人更具冒险性和侵略性，从而开启大航海时代。感觉欧洲人对明朝有较友好的态度，《文明6》中，只有3个天朝文明领袖：秦始皇、武则天、朱棣。只有明朝的朱棣是发展种田流的。

结尾
#

重新回溯人类文明的发展，可以了解我们是怎么来的，还可以知道我们现在在做什么，探索我们会往哪里去。也因为喜欢这类题材而很喜欢《文明6》《人类》这样的策略游戏，但你种植水稻、圈养马、挖出盐、铁矿、煤、石油、铀···时，会有一种人类进化的快感。

我想用我玩了400多个小时的游戏《文明6》来结束此篇：”从水下第一个生命的萌芽开始……到石器时代的巨型野兽……再到人类第一次直立行走，你已经历许多。现在，开启你最伟大的探索吧“。

读书笔记——《富爸爸穷爸爸》

Tue, 13 Aug 2024 00:00:00 +0000

《富爸爸穷爸爸》，以前不屑读这种书。这种书就是那种走进书店放在门口展销位的成功学著作，一眼看上去没什么实在的内容，看上去很不靠谱，感觉就是骗一些社会底层又做着暴富梦的人来买的，但是由于自身原因或环境局限根本无法将书中建议带入自身。再者说了，聪明人是不会读这种没涵养的书的~书名还low的一笔！有一段时间喜欢看B站的《老高与小茉》，有一集在讲这本书，说的神神忽忽的，而且是世界畅销书，所以买来看看到底有多么神奇。

开始读电子书了
#

个人是纸质书的忠实拥趸，喜欢那种看完一整本书，然后放在书架收藏的感觉——”这一书架都是我的知识“的feeling。本身是不太喜欢电子书的，一种看完就完了的感觉，重拾电子书有3个原因：

最近把常用的打发时间app都干掉了，需要一个不那么洗脑的app，拿出手机时能首先点开的app
电子书还是比纸质书方便，随时都能拿出来看

利用地铁的碎片时间。之前考研的时候给自己规划了细致的时间计划表，其中就包括地铁时间。因为已经养成了地铁学习的习惯，还是不想放弃。推荐一下我的考研总结精华：我是如何考上武汉大学在职研究生的_ 把我之前的实际计划稍微调整了一下，现在不用这么投入的去背单词了，所以可以替换成看电子书。我把地铁时间分成了2块：上班地铁时间和下班地铁时间

上班的时候脑子比较清晰，精神状态比较好，会看技术类的电子书。这种书看的时候非常慢，有时候还得停下来想问题。这种技术类的书是目标驱动看书。下班的时候脑子混沌（其实也不是混沌了，很多时候是头痛），看点比较轻松的书。比如《富爸爸穷爸爸》这种的”课外“书籍。看这种书本身内容也不硬核，看的就很快，而且看的比较爽，有点多巴胺驱动看书的感觉。

穷爸爸和富爸爸
#

作者罗伯特清崎从小在夏威夷生活，他亲身父亲是一位高学位的教育官员，称之为穷爸爸，他一位好朋友的爸爸是一位高中没毕业但是及其有财商的人，称之为富爸爸。穷爸爸受过高等教育但是每天都需要担心贷款和账单，而富爸爸每天都在指挥人为自己创造财富。书中有一句经典的话”穷人为钱工作，富人让钱为自己工作“

挣钱的思想：作者在小时候跟他好朋友一起想了很多挣钱的办法。小时候他们用牙膏皮伪造硬币，他们当时并不知道制造钱币是违法的，后来就被大人制止了。后来他们用商店里的免费书籍，找了个地方弄成小书店，利用给附近小孩出租书的方式来挣钱，后来因为引来了当地一些社会分子就没做了。富爸爸很欣赏他们的挣钱的行为，他认为穷人和富人的区别在于富人一直在思考怎么挣钱，而穷人只是在思考怎么找一份好工作。
关于缴税：穷人交的税要比富人多的多。富爸爸交的税要比穷爸爸多，但是富爸爸收入要高得多。当美国总统决定提高富人缴税额时，只是把美国领工资的中产阶级税提高了，真正的富人没有影响。富人有有很多合理避税的方法，只要懂得使用法律来合理避税。比如书中作者说在房地产行业，如果卖掉一个房子，所得的收入需要交非常多税，但是如果是换房子，那么没有税。富人可以通过这条法令来投资房产和合理避税。但是穷人的收入所得税是逃不过的，挣的越多，交的税也越多。
关于投资：投资需要培养会计、金融、法律方面的知识，总之需要你想挣钱需要培养自己的财商。当你挣打钱后应该开启下一段投资而不是买东西消费。比如我们家里里的桌子凳子、瓶瓶罐罐、各种衣服和生活用品，我们会花较高的价格买入，当一但买入，它们的价格会立即降至几乎不要钱。当然不是说不让你买东西，而是先考虑把钱投资，再考虑无回报率的消费。

最后
#

书中说，我们的教育体系都是在培养人们的工作能力，而不是培养挣钱能力。这句话非常赞同，但是我仍然相信教育的力量。作者也不是不让人们去读书接收教育，教育对于挣钱也非常重要，我们需要了解这个世界的基本运作原理和规则，这样也能帮助寻找适合自身的挣钱的办法。
从作者当时的家庭条件来看，可能对于富爸爸来说是比较贫穷，但是对于真正的穷人来说，已经完全不是穷人的家庭条件了。我感觉我的条件还没有达到全身心的投入投资和挣钱的道路中。如果有一天有点闲钱并且自身的管理、社交、决策能力达到一定水平，我也许会去寻找挣钱的办法。现在还想不了那么多，把代码敲好了，先把坑填上再说。

文中这个学习金字塔令人印象深刻，被动学习能记住的东西真的非常非常少。所以我坚持频繁的写文章，包括读书笔记这类的。几年的半夜维护数据库，遇到问题，现在还影响深刻，实战确实是记忆最深的。不过话说回来，实战是可遇不可求的，阅读和自我学习是成本最低也最容易养成习惯，也是提升能力性价比最高的方式，它也没那么“被动”。学习金字塔的“被动”指的是知识被主体接收，“主动”指主体输出知识。这也增强了我记录和分享的动力，无论是技术的还是非技术的。

读书笔记——《马斯克》

Tue, 13 Aug 2024 00:00:00 +0000

天赋异禀
#

马斯克的祖辈因为热爱冒险，从美国移民到南非生活，他的外祖父甚至驾驶飞机从非洲飞到澳大利亚。马斯克出生于南非，从小马斯克就表现出惊人的记忆力，而且非常聪明。她母亲梅耶马斯克跟老师说：“我儿子是个天才”，老师说“是的，每个母亲都是这样说的”，梅耶：“不，我是说他真的是个天才”。小时候马斯克表现得有点“反应迟钝”，他妈妈说，别人在跟他说话时他毫无反应，她以为马斯克脑子有问题甚至去看了医生。但是后面她发现，马斯克只是沉浸在自己的世界里思考。马斯克小时候甚至可以把图书馆的书全部看完，再让图书馆再去搞更多的书···

到达美国
#

由于南非的环境不如人意，即将读大学的马斯克选择了二级跳。他先到加拿大读大学，再到美国读硕士。最终到达美国的马斯克沉浸于硅谷的工作环境，科技行业太需要他这种聪明又拼命的年轻人了。而硅谷的科技氛围和自由施展特长的文化另马斯克沉浸其中。

zip2和paypal
#

不久马斯克创办了ZIP2，相当于公司版的在线地图，虽然我们现在对于在线地图非常熟悉，但那个时候美国的互联网行业才起步不久，这些都是新鲜玩意儿。后来经过很多曲折，zip2确实也成长了起来。个人觉得zip2的模式再往后发展，不往在线地图或大众点评这种方向做很难活下来，最后有冤大头用3亿美金把zip2买下来，直接让马斯克成为千万富翁，成为硅谷科技富豪。其实能看出来，zip2当时内部分化严重，公司经营方向也有问题，马斯克也没有绝对的话语权，估计早就想甩锅了。

在离开zip2前马斯克已经在盘算和招兵买马搞在线支付。当时这个世界还没有支付宝这种东西··· 。马斯克认为传统金融行业过于保守，有非常大的机会改变这个行业模式。但是很多银行家并不认为互联网金融能做起来，因为互联网金融无法处理网络安全问题，毕竟金融问题如果出一点差错影响会极大。刚开始马斯克成立的公司不是paypal，而是X.com，后来与paypal合并并保留了前者的名字。刚开始X.com遭到了非常多的攻击，而X.com活了下来，他们当时的安全防护机制对于后来在线支付领域影响很大。而paypal后来被ebay收购，马斯克收入上亿美元，又挣了一大笔。

spaceX和特斯拉
#

zip2和paypal对于马斯克来说，是对自己行业敏感度和商业能力的认可，同时也有人质疑马斯克的执行和决策能力，也就是当CEO的能力。一如既往的，马斯克认为这些行业过于保守和老旧。马斯克很喜欢招募那些能力极强的高校毕业生，也不愿意招募那些经验老道思想保守的行业精英。他几乎同时运营了两家公司，而这两家公司长时间都完全没有产品产出，关键是，想想也知道，造火箭这事儿是得有多烧钱。经过几次火箭发送失败后，马斯克发动了自己的特别技能：fire··而正值金融危机没有人愿意投钱，他也将自己的全部家当投入到两家公司。spaceX经过几次失败在FALCON火箭终于完成第一个私人公司成功发射卫星的壮举后，获得了NASA的10亿美元订单。特斯拉也在厚脸皮的向之前下单购买roadster的客户再要点钱后，因为开发一辆如此新概念的新能源车成本远超预期，终于制造出了成品车，并打造了公路新能源充电体系和电车工厂。在同时成功经营两家颠覆行业的公司后，没有人再质疑马斯克的能力。

为了人类
#

马斯克的成功离不开他优秀的品质，对未来科技的敏感性、快速理解新行业的知识、识别人才的能力、自由开放的科技和市场环境、长时间工作和执行力···，但是他不被人喜欢的点包括对员工非常冷库，对于一些忠心耿耿的人说fire就fire。作为一个打工仔的我深深理解自我付出但是被公司认可的感受。我在读这本书时，甚至可以感受到美国资本家是真剥削工人。一次一个员工因为不想错过女儿的出生而错过了公司的聚会，马斯克写邮件喷他，你想沉浸于家庭的里短还是马不停蹄的改变世界？毒师可不想错过女儿的出生。

几年前我读《乔布斯》传的时候，想着怎么会有这么偏执的人，但是就是这种人改变了移动行业，带来了智能手机革命，乔布斯也太强了。看完《马斯克》后，现在感觉马斯克比乔布斯还强。特斯拉、spaceX、太阳城都是在向着人类的未来发展，未来世界似乎启动了步伐，能看到它慢慢来到我们的世界。

马斯克的火星计划似乎终于见到了一些曙光，几十年来美国航天业几乎停滞不前，他带来了新的模式，并再次把航天业带入热门领域。但是这一切也有不确定因素。如果载人发生发生爆炸造成人员上网，SpaceX可能又会落入深渊。再者特斯拉在未来发现有严重缺陷需要召回，股价也会暴跌。

如果你可以成为登陆火星的第一个人类，你会去做吗？马斯克想过，并且他真有可能成为那样的人。但是马斯克不会那样做，书中的原话：我想去，但我不必去，重点是让很多人能够去火星。就好像波音公司老板当飞机试飞员，对于太空开发是不明智的。就算永远不去太空也没什么，重点是尽可能延长人类的寿命。

未了人类而工作，这个主题确实令人心潮澎湃。我玩几天几夜的《文明6》，从拿棒子的原始人到点燃火箭，就是为了发射那一刻，人类成为跨行星物种，在火星上建立了新的家园！

读书笔记——《再见，平庸时代》

Tue, 13 Aug 2024 00:00:00 +0000

为什么会看这本书
#

《马斯克》这本书中，最后几段介绍了一下经济学家和作者泰勒·考恩的两本书《大停滞》《再见，平庸时代》。《大停滞》讲的是美国这40年发展为何停滞，我当然不太关心这种内容。但是《再见，平庸时代》不是对历史的研究，而是对未来发展的看法，特别是AI对人类生活的影响。

对于人类的未来生活是怎么样的，一直比较感兴趣。最近OpenAI也比较火，似乎AI时代就要来了。AI会带给我们生活、工作怎样的改变？社会结构不会不会发生改变？哪些工种会逐渐消失？那些工作会得到收益？

象棋
#

这本书用了大篇幅（将近一半）说国际象棋和电脑程序，能看出来作者肯定是一个国际象棋爱好者，他非常了解国际象棋的历史和象棋的发展。看这段文章总让我想起《女王的棋局》，要不是这部剧我都不知道国际象棋有快棋的下法，前苏联是最强的国际象棋国家。作者也借助国际象棋引申了电脑程序对国际象棋的影响。

这个影响不仅仅是阿尔法战胜人类最强围棋手这类“击败最强人类大脑”的影响力，还包括早期象棋程序对人类学习象棋习惯的改变。在国际象棋发展早期，电脑还没有兴起的时候，人人们学习象棋只有通过人教人的方式，一个初学者也不太可能经常跟一个象棋高手下棋。但是随着电脑程序的广泛使用，象棋程序被大量应用。象棋程序可以教你下棋，你可以跟象棋程序下棋，而且还可以设置难易度。这对于初学阶段的象棋爱好者是非常方便的。虽然我们没有意识到，但是电脑程序就这样悄无声息地影响着我们的生活。在未来，我们也会更多的与人工智能协同工作。

两极分化
#

当人工智能被大量应用以后，我们许多生活方式会发生改变。人工智能不太会颠覆式的改变富人和穷人的社会结构，极少数人掌握绝大部分财富的现状可能愈演愈烈。中产阶级也许是最可能被影响的阶层，许多中产阶级通常使用着一部分智慧做着重复的工作，这是人工智能所擅长的领域。书中认为，中产阶级的工作价值其实没有那么大，可能会被较容易地取代。基础资产差距会加大财富分配差距，也就是说本金差距会拉大资产积累的差距——在这个时代，这句话还是比较好理解的。

书中是站在美国的角度看财富分配问题，其实也很容易带入天朝环境。从天朝这几十年经济发展确实令人瞩目，人口和基础设施建设的红利，发达国家都经历过基础设施建设的时代。但是市场经济的带入和时间推移，也伴随着贫富差距越来越大。就这样吧···我并不想写一些太过敏感的内容···

学习成本
#

学习成本越来越高。这句话不是说读书或者培训课程的成本，而是学习或掌握一个行业的难易度。“发明家”这个词我想很多人已经很久没听说过了，我们对这个词汇的印象还停留在爱迪生那个年代。那个年代人们可以自我发明，只是需要行业内一些较先进的知识并运用一下大脑，“发明”似乎没有那么难。但是随着时间推移，我们很难再听到“发明家”这个词汇了。这不是因为人类没有再发明，而是现在人们发明的东西，基本都是一个团体、非常多的人来完成，通常需要跨行业的多个专业人员协作。我们“发明”东西的成本越来越高，因为我们掌握行业的知识越来越多，越来越复杂，一个人掌握整个行业是不太现实的，人们更倾向掌握更细化的领域，即便是这个细化领域，也足够一人一生来学习。

如今学术界正面临着这样的现状。一篇比较成功论文通常需要各个行业的专家通过自己的专业知识证实某一小段证明的正确性。书中讲了一个经典的例子：如果一位数学家在数学领域证明了一个猜想，那么可能全人类没有几个人能真正看明白这个数学家在证明什么，他们中的大部分人可能只能看懂其中的一段内容，即使是他自己也只是会说：我也许是对的。我们没有办法证明这个证明的正确性。

人类的知识越来越趋于复杂，科学家现在更倾向于、越来越多地把计算和实验交给机器。人类似乎已经到达了一个临界点：我们大脑快理解不了这些知识了。从生物学角度来看，人类大脑必然有一个极限。人类大脑的处理速度，远远跟不上机器。

自我学习
#

即便是学习成本越来越高，在未来，教育愈发重要。教育体系可能发生变化。由于未来世界时间会更宝贵，而人们也更容易拿到学习资源，人们更倾向于线上学习，自我学习。同时这会导致人的自驱力更加重要。

作为一个IT行业的从业者，对于自我学习这件事深有体会。这行业非常内卷，如果不学习基本处于被淘汰的边缘。但是一个非常高效的学习，也会反应在薪水上。我们父辈那个年代靠着分配工作，在一个岗位上可以工作几十年，不会有特别大的变化。那时的人们也只想着工作而不是满脑子自我提升，去考这样那样的证。时代真变了，有多少人像我一样，半夜11点还在写文章…我甚至对那些毕业后不需要怎么学习的行业感到困惑，是得有多落后。大学毕业不过20多岁，还有几十年的时间可以学习，如果我们就这么停滞不前实在是太奇怪了。我当然不喜欢内卷，但是我更不喜欢原地踱步，特别是在这个坐在凳子上发呆贫富差距就会拉大的年代。

最后
#

文章封面和插图都是AI作画，我只是输入“再见平庸时代”，然后AI就画出了令人惊叹的图画。我不知道具体哪些行业、哪些职业在未来会消失，但是至少可以看出插图师在AI时代很难生存。

人工智能已经侵入到IT领域，作为一个dba来讲，我们哪些工作模式会被替代，这是一个值得思考问题。无论怎样，在这个时代，只有学习才可以保持竞争力，希望我们都不会是那个“消失的棒棒”。

我是如何考上武汉大学在职研究生的

Tue, 13 Aug 2024 00:00:00 +0000

我为什么要考在职研究生？
#

提升学历。我的学历是一个普通的本科学校。学历高一点的话在以后的职业生涯会稍微增加一点竞争力
之前投递过一家国企，简历石沉大海。但是同办公室的一个学历较高的同事就通过了，所以如果是国企单位，高学历就是敲门砖
弥补大四考研失败的遗憾，重拾研究生的梦想
学习总不会有错，这是我的信仰

全日制研究生和在职研究生的区别
#

学习状态
#

全日制是脱产的，在职是可以工作的。这条基本定死了大部分打工人只能考非全

考试范围
#

全日制考试压力更大，考试范围基本都是4门：高数，考研英语，政治，专业课. 非全考试压力较小，考试范围是2门：管综（初中数学，逻辑，写作），考研英语. 非全除了英语跟全日制差不多外，管综考试内容比全日制简单很多（后面细说管理类综合联考）

研究方向
#

全日制研究生偏向研究性质，重学习和科研成果，培养学生的学习能力和研究能力。

非全研究生偏向提升学生的管理才能，向社会输送管理类人才。

两个方向有很大的不同.

社会认可度
#

全日制研究生肯定比非全的认可度高，毕竟门槛高，学习压力更大，主流学历，社会认可要更高。但是非全认可度也是有的，很多学校已明确方针是一视同仁的（明面上）。最重要的一点是，非全日制研究生持有双证（学位证书和学历证书）。

对于工作方面，就看单位情况了，有些单位招聘要求只要是研究生学历即可，有些可能真写明必须是全日制研究生。但是对于无法脱产提升学历的人来说，非全几乎是唯一途径. 总之，非全同样是双证，非全认可度 < 全日制认可度

如何选专业
#

结合工作性质、发展意向、人民币余额综合考虑..

人力资源或金融方向或公司高管：MBA

技术工种或工程管理：MEM

公务员或公共管理：MPA

会计：MPAcc。其他还有几个比较冷门自行百度

从人民币余额角度考虑，每所学校收费不同，但一般不会差别过大。以四川大学为例，MEM一年学费1.5w，MBA一年15w，MPA好像跟MEM差不多。

像我这样的it人士，囊中羞涩，自我感觉也做不到高管，比较适合MEM。

如何选择学校
#

因为学习难度相对比较简单，社会认可度也没有全日制高，所以建议选择当地名校。211、985是极其推荐的，找一个自己心仪的学校即可。很多985院校的录取分数线就是国家线，所以个人感觉非211、985的院校报考意义不大，既然分数都一样为什么不选择好一点的学习呢？

当然有些985有自己的自划线，这个需要自己到学院官网找历年的录取分数线，例如四川大学每年都是自划线，一般超国家线20-30分。

怎么考试？
#

考试内容
#

考试分为初试和复试，初试在12月底，复试在3月份。

初试既笔试。在报名考试和考点后，在12月底进行考试，一天考完，每场考试3小时。

复试既面试。少部分学校会加笔试，但是从疫情以后，都是网络面试，很少有面试的时候用笔写什么东西。

初试内容：（管理类综合联考）

复试内容：

提前面试
#

提前面试指初试之前，学院安排面试，相当于把复试提前。提前面试通过以后，初试只需要过国家线即可。而一般考试流程下，需要过学院自划线。

提前面试也是只有部分院校才有，比如清华有提前批面试，四川大学没有提前批面试。这个就要看报考院校的官网信息了。

加入通过了提前面试的话，初试压力确实要小一些。

如何报名
#

考研过程中，最重要的2个网址，一个是你要报名的学校官网，另一个就是研招网：中国研究生招生信息网

报考前在硕士目录中查看报考的学校和专业，例如非全工程管理应如下选择

要不要报培训班？
#

很多同学都比较关心要不要报培训班的问题。报呢感觉太贵，万一考不上呢？不报嘛不知道咋学或者学的太累。

这个问题我还是比较有发言权，因为我报了培训班。

我也是网上看到有培训班，问了一下价格8k，再加上当时存在信息差，不知道考什么，不知道怎么学，不知道怎么报名，不知道报考什么学校，不知道在哪去搜这些信息（马上百度在职研究生，基本全是广告），再加上当时真的很有决心要学习，所以就入了这个坑..

培训班给了我什么？
#

首先给我一堆学习资料，学习方法、真题等等。除了英语词汇我立马拿出背以外，其他东西我基本没动过。真题我也立马打印了，那堆真题到考完我也没看过。看上去很有用，实际上淘宝搜索真题一大把正式发版带详细解析的真题，非常好用，也没那么费眼睛。而那个词汇，很奇怪，培训班给我的词汇跟张剑黄皮书词汇对不上，我把培训班词汇背了很久，发现有些真题常见词汇不在词汇本里，后面换了张剑黄皮书词汇本背，感觉好多了。

处理学习资料外，最重要的就是直播授课，直播课基本都是晚上8-10点，2小时讲课，10分钟答疑。

直播课还是有用的，特别是逻辑课和数学课，听这2个课基本不需要额外买书全面地学习数学和逻辑基础知识，只需要做课后练习和练题。英语课我基本没听过，基本都是自学的，个人感觉听英语课效率很低，浪费时间，不如多背背单词，多做些阅读题。英语写作课也只听了最后2节，非常有用，后面细讲英语写作（有干货）。最后，不要妄想有问题问老师，这种网课很多人，老师答疑时间就10分钟左右，我提的问题从来没被选中过。

培训班的好处： 学习的方便性。从打工人的角度出发，本身加班就多，回到家累的要死，要我回去把资料铺开像高考一样去学习，太难了。但是如果是授课，我只需要坐在沙发上把直播看完，这eazy很多节省时间。不需要费周折地制定计划并在期间不断调整学习计划，听课的效率也比把厚厚的一本书自己看完要来的更容易。从本质上讲，培训班就是拿钱买时间。

同学的学习状态良好会激励你学习，你不会是孤单一个人学习，完全不知道别人学的怎么样。

培训班的坑： 培训班参差不齐。我当时报考的shangdejigou，报的时候没有调查过这家机构，确实很一般。他们有的班是协议形的，没考上的话会退费，但是协议里有坑，都没退成。我们群里有很多闹退费的。还有个人信息泄露的问题，基本所有学员都接到过退费诈骗电话，连我这种考上的都接了5、6个诈骗电话了。

老师素质参数不齐。有的老师讲的好，有的老师感觉像是摸鱼的，甚至有些讲解完全就是误人子弟。我那个班就是数学和逻辑老师讲的特好，英语垃圾，写作误人子弟…

不要妄想培训班会把你培训的很好，培训班只是辅助，主要还是靠自己。我从计划开始考研，到初试完成，基本没有一天周末时间，都是泡在图书馆或者咖啡厅里，所有聚会都拒绝。

所以，到底要不要报考培训班？

个人认为如果你同时具备以下条件，可以报名：

足够的决心。既然已经交钱了，就不要打水漂，也不建议报退费的班给自己留后路
足够的资金。线上培训班几大千起步，我这个8k可以参考。线下会更贵，但是有老师线下辅导
无法填补信息差。信息差可能会导致无法自我规划学习计划。如果是信息差导致报班，我建议多看看别人的学习计划，b站成功的up案例。最大的信息来源一定是学校官网

如果你具有时间和精力，或者资金不足，或者具有一定的学习力，大可不必报班。这个时候制定适合自己的学习计划尤为重要。

初试
#

在初试结束之前，只需要准备初试即可。一般来说复试内容在初试完后再准备即可。
准备初试既学习的核心，也是最消耗精力最卷的环节，成败在此。

如何准备初试——学习计划
#

准备初试，你需要一个适合自己的学习计划，并全身心的投入其中。

学习计划是非常非常非常重要的，你需要确定先审视自己，自己的在优缺点是什么，环境是什么，哪门科不了解，哪门科又需要长时间的学习。

每个人情况情况是不一样的，先讲讲我的学习计划，可以参考我的定制计划的方式，和学习方式。因为学习压力没有那么大（相比全日制），非常建议从7、8月份开始准备学习，过晚时间不够，过早容易懈怠，整个学习时间为5-6个月。但是如果你的英语确实有够烂，再多提前几个月去背单词。

我的个人条件如下：

时间不够充足，经常加班到晚上9点，周末一般都是双休。上下班地铁，双向共2小时。
数学基本忘精光，逻辑从来没碰过，语文写作从小稀烂，英语词汇量还行，阅读没问题，英语写作完全不会。

结合学习压力和个人条件，我需要这样制定计划：

背单词。英语肯定是最花时间的，需要长时间持续性地背单词，在所有学习开始之前，背英二单词。因为早上记忆力最好，我每天在上班的地铁上背单词，周末早上也背单词。时间从8月份开始，一直到初试。
英语阅读。其实只要把单词背下来，阅读很容易理解。英二的长难句并不多，能认识所有单词，阅读肯定没问题。但是个人比较爱好英语阅读，我计划了每天的英语原著阅读。不能说用处大，也不是完全没用，就当是辅助考试。重要的是，爱好更容易培养习惯。
数学和逻辑，其实学习难度差不多，我虽然完全不会，但是学起来较为简单（知识点是简单的，考试是另一个样子这里先不谈）。我会在下班晚上20:00 -22:00点学习数学或逻辑（主要是听课，没有课的可以自己买资料学习），这个也是长时间学习，前期学习知识点，后期练题。因为不是每天都能正常下班，所以有时候需要利用下班地铁时间和中午1小时午休时间，把数学和逻辑的每日学习任务完成。（千万不能拖，拖一次就会累积很多）
中文写作。在考前一个月，也就是11月底12月初准备即可。看下作文资料，自己试着写，不用想的要多完美，主要是把主题含义表达清楚。相信我，考试的时候你绝对是用的狂草在写作。
英语写作。在考前一个月，准备即可。切记，千万千万不要背范文，不仅非常难背，而且根本无法套用。考前背2-3个模板即可，用模板联系历年真题，只需要替换单词即可，不会发生提笔一个单词写不出的情况。

所以，我的周计划如下：

这样安排感觉比较合适自己，既充分利用了碎片化时间，也充分利用了周末。前3-4个月打基础，英语的基础是单词，逻辑和数据的基础是知识点，每周工作日的学习，可以在周末汇聚复习和练习。后1-1.5个月主要就是写作和找做真题的感觉。

推荐的学习资料
#

英语：张剑黄皮书。买单词本和真题本即可。百词斩，爱阅读，公众号：考研英语外刊。
英语写作：不推荐任何可以购买的写作资料书。用通用模板，不要背范文。
数学：《陈剑数学高分指南》，历年真题解析
逻辑：中公《逻辑轻松通关》，历年真题解析
管综写作：找个销量高的吧，都不是很好用。写作不用学太精

不要买练习题，直接买真题做，现有的练习题质量跟真题完全比不了。英语不需要买练习题，直接买真题即可。数学和逻辑除了基础学习的一些自带练习题外，也不要买额外的练习题。我也做过一小段时间的数学练习题，很花时间，效果并不好。数学和逻辑主要还是要把基础打好，把知识点学齐，然后做真题看解析即可。总之，沉浸式学习时间（比如周末）只需要做真题，真题做近20年的即可，做完然后重新做一遍（20份真题，周末2天也就做2套，要2个多月才能做完一轮，重新做的时候前面的题已经忘的差不多了）。最近两年的2套真题一直都不要做，留着考前2周掐表自我模拟。

英语学习
#

单词
#

早上雷打不动地背单词（在地铁上效果非常好···）。百词斩——有些小伙伴喜欢用百词斩，我前期也在使用百词斩，但是我感觉效果不好，它是全量单词，背一年可能都循环不了一遍，前面背的早忘了，所以后期我没有用这个软件。我个人强烈推荐我背单词的办法。

每个人的单词量是不一样的，刚开始的时候，必须把所有单词全部过一遍（考研词汇大概5000个左右），把不认识的拎出来写在单词本上。由于拿着单词本在地铁上背会略显尴尬，所以我放在手机里。

我专门有一个单词本相册：

每次背的时候，点开，放大，相当于蒙住注释背单词。

这样循环背诵，刚开始我每天背2页，每天前进1页，后面每天背4页，每天前进4页。无论如何，循环背，背到蒙住注释就知道单词的含义。有些单词容易混淆的可以加在单词本里再拍照更新相册。

在我初试前，这些单词我已经背了6、7遍了，基本上除了超纲单词，我没有不认识的。

阅读
#

英语总分100分，阅读能力分数占比=完型填空10分+阅读理解40分+新题型阅读10分=60分。英语能力再烂不能烂阅读理解能力。我的阅读能力基本上都是靠每日的外刊阅读，比如爱阅读、考研英语外刊。每天花20分钟左右，学习压力也不大（其实主要是单词，单词认识，句子就好理解）。

爱阅读：《爱看世界》外刊，每日一篇。在阅读计划-更多专辑-外刊-爱看世界，订阅每月的期刊，每日一篇。难度较低，适合初期阅读能力提升。
微信公众号：考研英语外刊，每日一篇。每天都会更新，这个公众号做的很不错，非常推荐。只是这个难度比较高，适合后期挑战难度，如果看不太懂也没有关系，我有些也看不太明白，毕竟难度超了点。

阅读就随着早上背单词看了就行，时间不够下班路上也可以看。

长难句：英二的长难句并不多，有些小伙伴会专门花时间去学习长难句。如果你要专门学习长难句的话，特别推荐刘晓燕长难句的视频（视频网站搜一下就行，都是免费的），非常有趣，条理也很清晰，比较容易能坚持看完。而我，只看了刘晓燕长难句里的简单句，就没有继续看。因为，第一，我发现只要单词认识，句子基本都懂，第二，视频太长太多了，比较占用学习时间。

写作
#

写作分为小作文（书信或通知，10分），大作文（材料分析文——柱状图饼状图分析，15分）

再次提醒，不要背范文。考前我专门买了一本写作的书，背了10篇范文，真的很难很难很难背，而且难套用，范文背完，我第一次做英语写作题，毫不夸张我一个字都写不出来。

我学习的培训课程里，对我来说最最有价值的，就是英语模板，我按照模板把历年的英语写作全部做了一遍，全部都能套用。要替换的单词不超过20个，会写简单句即可。模板如下：

小作文模板——书信模板：

Dear  Sir or Madam,

    I am an undergraduate who majos in Applied English in this/a university.I am writing this letter for the purpose of doing sth.

    1.It,first an formost,is my idea that not only ... but also

    2.Then more importantly,so ... that...

    3.The last on I must point out is that 简单句,which could be accepted by the majority of 人/.

    So It is the very moment for me to do ...,And I am looking forward to your reply.

                                                                                          yours truly,
                                                                                            xxx.

其中 doing sth包含：

感谢信:expressing my genuine gratitude for your kind help
建议信:making some suggestions concerning sth.
投诉信:making my complaints concerning sth.
祝贺信:show my sincere congratulations to you because 句子
道歉信:offer my sincere apology to you because 句子
邀请信:invite you to participate in 活动 on behalf of 某人/组织
通知信:have 某人 informed that 句子

书信模板各类信都可以套用。

小作文除了书信，小概率可能考通知，通知的格式与书信不同

小作文模板——通知模板:

                                               Notice

    In an effort to do sth,I woud like to offer you some detailed information about it.

    The 活动 will be held in the school auditorium at 7 p.m.,next Saturday,December 28th and the requirements for sth. are listed as follows.

    主段内容同书信...

    If you have any questions,please feel free to send on email to 
studentsunion@123.com or call 1234567.We are looking forward to your participation.

大作文基本只有柱状图和饼状图的分析，图例只分为比大小和比趋势。比大小和比趋势只有首段不一样，后面2段是一样的。

大作文模板：

    (比大小首段)The diagram clearly shows/illustrates/d that 句子/词组(the purposes of/attitudes toward/the proportions of) among participants/respondents in a certain college.
Based on the data offered,one can distinctly see that 对象1 ranks the first/highest among all the categories,accounting for 数据1.Next are 对象2 and 对象3 with 数据2 and
数据3 respectively ,while 对象4 only constitutes 数据4.
    (比趋势首段)The diagram clearly illustrates how 话题 changed during the past several years.Based on the data provided,one can distinctly see that the number of 对象1 rose/fell significantly/slightly/gradually from 数据 in 年 to 数据 in 年,while that the number of 对象2 experienced a gradual/significant increase/decrease during the same period,reaching 数据 in 年.
    From my standpoint,there are two fundamental factors that are responsible for this scence.To begin with,the first contributing factor is that 句子.In addition,another important factor that cannot be ignored is that 句子.
    In view of the analysis above,we can conclude that it is of little surprise to see this phenomenon in the current era.Therefore,it can be predicted that 名词词组/动词ing will still take up a large share in the future.

作文不背模板靠自己写非常难，背模板拿个超高分数比较难，但是拿70-80%的分数是没问题的，而且前提投入基本为0，后期模板背好，自己把历年写作真题全部写一遍即可。

数学学习、逻辑学习
#

数学题：
#

逻辑题：
#

数学和逻辑都是选择题，没有什么好说的，前期主要学习知识点，后期需要提升做题速度。

数学和逻辑的知识点非常多的，前期学习时间需要花3-4个月，每天学习2-3个小时，把知识点全部学会。知识点学完后拿真题练习看解析。最后1个月恰表练习，提高做题速度，数学做题时间不超过70分钟，逻辑做题时间不超过60分钟。

中文写作学习
#

管综作文分为论证有效性分析和论说文。

论证有效性分析就是抬杠，找本写作书看看，并不难写。论证有效性分析需要在一大段材料找找出材料推理问题所在，写的时候找4个问题点即可。没有学过的话可能找不太到，学过后找4个问题点还是比较简单的。不用把问题写的特别明确，比如这个问题是以偏概全、偷换概念、非黑即白等等，把它写成”xxx推不出xxx“即可。

论说文主要是对一小段材料做出自己的理解。论说文需要注意主题别写歪了，刚开始找主题也挺难的，多看几个论说文材料，找找感觉，基本能找到主题在哪。论说文一般写作结构为总分总，建议以 “个人-企业-国家”为思路来写（总-个人-企业-国家-总，共5段），找几个自己拿手的材料往里面套用。一些同学觉得自己作文能力强，会以其他思路来写议论文，我个人当然是非常佩服的。因为写作时间是非常有限的，除非天赋异禀思路非常快，不然还是建议用套路来写，把作文写完，是第一要务。

考试时的做题规划
#

是的，做题也得规划，100%相信我，管综你做不完。管综是我平生考过的，时间最仓促的考试，你知道这些题你会，但是你没有时间去运算。

初试考试时，上午管综3小时，下午英语3小时。

英语考试时长3小时，内容较少，也没有需要反复演练的点，做题时间是完全足够的。我当时考完时间还剩了50分钟，提前交卷走了。

管综3小时，完全不够。我在考前自我模拟的时候，基本都是4小时才做完的。考试时，数学只要有做题时间超过3分钟，直接跳过，感觉运算量大，直接跳过。逻辑题，根本无法用平时做题的思路去做，快速读完题（逻辑题文字巨多）看选项，感觉对的就勾上，需要运算的逻辑题暂时放弃，后面有时间在做。写作题看完题目直接写，能写多快写多快（2篇写作总共不能超过1小时），每省2分钟，就可能拯救一道选择题。

选择题可以不用做完（答题卡要涂完哈），但是写作一定要写完，所以做题顺序很重要。很多人一般上来都直接写作文，然后做选择题。我是先做数学题，然后写作文，然后逻辑题。反正总之，不要把写作放在最后做。真实考试时，两篇作文完成时间不能超过55分钟，总共1500字，还要阅读材料和构思，去做一次就知道时间是多么不够。

最后20分钟，涂答题卡，涂完再继续做题。

复试
#

复试的基本信息
#

如果你如愿过了国家线或者学院自划线，那么你已经完成了90%的进度。剩下10%既复试。复试也是有淘汰率要求的（国家强制要求），一般在淘汰率在70-80%左右。这个淘汰率一定存在，所以每年一定有人复试被刷，如果你不准备，那么极有可能就是你。讲个笑话，我复试四川大学被刷~

复试时间：每年3月中旬到3月底

成绩公布时间：3月中旬

考试内容：英语口语，专业课，综合面试，政治（川大政治开卷，不用准备，武大政治闭卷笔试···）

疫情以后复试都是网络面试，没有笔试环境，专家提问学习回答的模式。

也就是说你有3个月的时间来准备复试。而恰巧初试考完是12月底，加上成绩还没出，再加上2月份过年，其实大部分人都是成绩公布的时候开始准备。已我这个反面教材为例，我是3月21日接到复试通知，复试时间是3月27日，我就准备了6天时间，其中还要考英语口语和我从没接触过的工程管理···，所以很尴尬，考官英文我一个没答上来，专业课题目一个没答上来，复试被刷。

网上调剂
#

当我知道四川大学复试没通过后，我的情绪跌入谷底。但是，柳暗花明又一村，调剂是我的救命稻草，当我在找调剂学校时，发现了武汉大学。

研招网专门有个调剂窗口，给予复试被刷的同学再3次面试的机会。调剂可以填3个志愿，也就是可以填3个学校。由于每个学校复试时间复试要求都不一样，全部准备是很难的。我主要就是准备武汉大学的调剂。调剂当然也是要复试的，其实就是没有招满学生的院校把复试再走一遍，给那些首批没有录取上的同学再一次的机会。

调剂窗口：3月底到4月初

如何准备复试？
#

复试也是非常卷的，跟我一样懒的人不会在少数···但是无论如何，已经付出了大半年，不能就这么打水漂了（我是差点真打水漂了···）。像我这种非专业学生，复试最难的就是英语口语和专业课。从成绩公布到复试，大概只有1周时间来准备（还要上班！），所以从头学肯定是来不及的，以我的经验，下面的学习办法的重要性依次递减

找学长学姐要历年复试资料（低调，复试资料外传是违规的）和老师上课资料。找找有没有人认识的在那个院校的，或者贴吧找组织，找群
B站搜考研复试常问的问题。把问题总结总结，背一背。
买学院推荐的参考书（一般是教学资料）。很厚，看不完。

最后最重要的一点，模拟复试。把可能问的英语问题，专业问题，综合面试问题总结出来，找个小伙伴当老师模拟面试。

还有一些其他复试要求，关注学院动态和邮箱即可。比如分数占比，面试流程，双机位，面试时间，材料准备等等。

最后
#

22年考研初试国家线是185，我初试成绩210（英语80，管综130）。附上我的复试通过通知^_^

祝被社会毒打仍不死心的打工人学子，考研一切顺利，上岸！！！

HikariCP连接池初识

Mon, 12 Aug 2024 00:00:00 +0000

HikariCP的简单介绍
#

hikari-光，hikariCP取义：像光一样轻和快的Connetion Pool。这个几乎只用java写的中间件连接池，极其轻量并注重性能，HikariCP目前已是SpringBoot默认的连接池，伴随着SpringBoot和微服务的普及，HikariCP 的使用也越来越多。

在hikariCP github首页就放了一篇性能对比：（https://github.com/brettwooldridge/HikariCP-benchmark）

看上去好像是碾压一众数据库连接池中间件。然而这个性能对比的有点老了，而且没有阿里自研的国产巅峰连接池druid的性能对比。我稍微看了下druid的github首页，star比hikariCP还多一点，druid在功能性上明显比hikariCP强。至于两者的性能谁更好，还引发过一次大佬间的口水战，目前没有看到有严格的性能对比报告。不过这不是我们这篇文章的重点···这篇文章只是为了稍微了解下hikariCP。

几个连接池参数
#

参数其实不多，挑几个重要的：

参数	含义
minimumIdle	这个属性控制着HikariCP尝试在连接池中维持的空闲连接的最小数量。如果空闲连接的数量下降至此值以下，并且连接池中的总连接数少于maximumPoolSize，HikariCP将尽最大努力快速而高效地添加额外的连接。然而，为了达到最大性能和对高峰需求的响应性，我们推荐不设置这个值，而是让HikariCP充当一个固定大小的连接池。默认值：与maximumPoolSize相同。
maximumPoolSize	此属性控制池所能达到的最大大小，包括空闲和正在使用的连接。基本上，此值将决定到数据库后端的实际连接数的上限。合理的值最好由您的执行环境确定。当池达到此大小且没有可用的空闲连接时，调用 getConnection() 将会阻塞，直至 connectionTimeout 毫秒后超时。默认值：10
maxLifetime	此属性控制池中连接的最大生命周期。正在使用中的连接永远不会被弃用，只有当它被关闭时才会被移除。为了避免池中发生大规模的连接消失，该属性会对每个连接适用轻微的负衰减。我们强烈推荐设置此值，并且应该比任何数据库或基础设施强加的连接时间限制短几秒。值为0表示无最大生命周期（无限生命周期），当然，这受到idleTimeout设置的约束。允许的最小值是30000毫秒（30秒）。默认值：1800000（30分钟）。
idleTimeout	此属性控制连接在池中允许空闲的最大时间。此设置仅在minimumIdle被定义为小于maximumPoolSize时适用。一旦池达到minimumIdle连接数，空闲连接不会被回收。连接是否被视为空闲并回收，其最大变化范围为+30秒，平均变化范围为+15秒。一个连接在此超时前永远不会被视为空闲并回收。值0表示空闲连接永远不会从池中移除。允许的最小值是10000毫秒（10秒）。默认值：600000（10分钟）。
keepaliveTime	此属性控制 HikariCP 将多频繁地尝试保持连接active，以防止它因数据库或网络基础设施而超时。这个值必须小于 maxLifetime 的值。“keepalive"操作仅会发生在空闲连接上。允许的最小值是30000毫秒（30秒），但最理想的值是在几分钟的范围内。默认值：0（禁用）。

keepaliveTime参数的设置应低于数据库空闲连接超时时间、TCP空闲连接超时时间以及一切其他设施的空闲超时时间。对于PostgreSQL来说，hikariCP的keepaliveTime参数应设置为小于PG库idle_in_transaction_session_timeout的时间。

很明显，maximumPoolSize代表连接到数据库中的最大连接数。当然一般来说，真实场景中数据库中的连接数不会一直保持maximumPoolSize，因为应用不可能从始至终都是最高负荷运行。即使经过一个请求高峰期，根据idleTimeout或者maxLifetime的设置，那些空闲的连接经过一段时间后应该被释放。为了保证数据库的可用性，这个值应该设置为比数据库最大连接数小一些。比如PostgreSQL数据库，maximumPoolSize参应设置为小于PG库的max_connections。这个参数还有调优空间，我们下面会提及。

minimumIdle是最小空闲连接数。例如，如果minimumIdle=100，数据库的active会话有10个，那么理论上数据库中的总连接数应该是100+10个。因为有可能有连接风暴的情况，真实的数据库连接应该比active+minimumIdle略多一点，但肯定小于maximumPoolSize。

为什么数据库连接数远大于minimumIdle？

理论上数据库总连接数只应该略大于minimumIdle，但是经过我实际观察连接池多节点的情况，哪怕数据库活跃连接只有10几个，数据库总连接数却远大于minimumIdle。观察pg_stat_activity的min(backend_start)、min(state_change)，基本保持在maxLifetime左右，说明连接回收是有作用的。看上去新请求总喜欢启用新连接，而不是直接拿已有的idle连接用。个人猜多节点部署是原因之一，每个节点minimumIdle很低，也可能存在某些组件上的节点请求要多一点，瞬时请求数超过了minimumIdle从而创建了新的连接。第二，这跟maxLifetime参数也有关系，maxLifetime的目的是为了旋转连接，释放那些一直在用的连接，这样就存在那些使用过的链接需要一段时间来释放，并且最好不要再使用了，以免延长释放周期。

连接池大小设置
#

连接数过多的影响
#

在数据库的世界中，“数据库连接数的增多，数据库性能都会一定的下降”。

例如oracle的连接数对性能的影响，参考这个视频。当资源配置、jdbc并发都不变的情况下，连接数从2048下降到1024个，请求响应时间下降一半；如果连接数调整到96个，响应时间下降几十倍！！

连接数设置为多少才合适？
#

Unless you have a database server that has 1000 cores, it is very unlikely that you really want a maximumPoolSize of 2000.

除非你的数据库有1000C，不然你不应该有2000个连接。

最初始的情况下，数据库连接数应设置为cpu数，这样就能达到cpu的最大性能模式。但是这不是真实的。因为数据库的消耗不仅在cpu，也在磁盘和网络（也有内存、但相对影响不大）。例如，磁盘的读写也需要时间，cpu需要等待磁盘返回数据才可以进行下一步动作。在IO等待的这段时间（有可能时间很长），cpu最好是不要闲着，而是给其他进程使用。所以，基于磁盘等设备的等待时间，数据库连接数最好是高于cpu个数。

由于SSD等磁盘性能的提升，磁盘访问的速度是非常快的，也就是说IO等待时间下降，意味着连接数应该调整得更低。

调低了不能压榨CPU，调太高数据库性能损耗，那么到底调整到多少合适呢？hikariCP给出了这么一个公式

connections = ((core_count * 2) + effective_spindle_count)

其中core_count不应该计算超线程数；effective_spindle_count为主轴数，如果活动数据集完全被缓存，那么effective_spindle_count为零，随着缓存命中率的下降，它应该接近于实际的主轴数量。对应SSD还没有想过公式，不过可以肯定小于以上的最大值。当然这些都是理论值，实际情况要比这个更复杂，比如长连接问题，具体可参考连接池大小相关知识。

即使前端有10000个用户，连接池也不可能是10000个，即使是1000也太多了，需要一个更小的连接数，让其余的请求在连接池中等待，发挥数据库及其CPU的最佳性能才是最好的方式，参考连接数设置如上公式所示。

fixed pool
#

fixed pool是HikariCP的作者Brett Wooldridge的一个理念，是为了解决连接风暴问题。在minimumIdle参数解释中已经提及fixed pool：

为了达到最大性能和对高峰需求的响应性，我们推荐不设置minimumIdle，而是让HikariCP充当一个固定大小连接池（fixed size connection pool）。默认值：与maximumPoolSize相同。

把minimumIdle=maximumPoolSize就是fixed size connection pool。minimumIdle的默认值就等于maximumPoolSize。

其实早在2014年，Brett Wooldridge就提到了这个概念，参考PG社区邮件。这段话很重要，我将逐字翻译：

根据我的经验，即使是维护最小空闲连接数的池，在响应突发需求时也是有问题的。如果你有一个最大30个连接的池，并且有一个最小10个空闲连接的目标，突发的需求需要20个连接意味着连接池可以立即满足10个，但随后要尝试在应用程序申请连接时间到达connectionTimeout之前建立另外10个连接。这反过来在数据库上产生了突发需求，不仅减慢了建立连接本身，也减慢了实际上可能会将连接返回给连接池的事务。

现在，如果你的峰值是100个连接，你的中位数是50个，这并不重要。但我知道不少工作负载的峰值是1000，中位数是25，在这种情况下你会想要逐渐减少空闲连接。

最终我们采用了一个maxPoolSize + minIdle模型，默认情况它俩相等（fixed pool）。

虽然我不怀疑存在这样的工作负载（1000个活动连接），如果有人真的这么做了，我很想听听他们的理由。除非他们有超过128个CPU核和固态存储，否则基本上就是在白费功夫。

这也意味着，即使连接池的大小是固定的，你也想要旋转（rotate in and out）实际的会话，这样它们就不会无限期地挂着最大虚拟内存。

我们确实是这样做，有一个maxLifeTime设置来旋转这些连接。

在真实场景中，fixed pool对连接风暴影响的保护是可见的。fixed pool下，数据库的瞬时active连接突增，数据库的idle链接数下降，但数据库的总连接数不变，请求响应耗时影响不大。如果把maximumPoolSize设置为比minimumIdle大的一个值，连接风暴会造成瞬间产生很多新会话，而新会话的连接是非常消耗资源的，这明显增加了请求的响应时间。

连接泄露案例
#

由于本人不是连接池的专家，这里只是把最近找到的连接泄露资料小小汇总下。

连接泄露有如下现象：

“Connection is not available” exception。连接泄露，连接打满或者数据库因为active会话过度响应不过来了，新的请求会因为超过connectionTimeout时间而报错
Growth of active connections。数据库监控可以明显看到活动会话上涨
Application logs。应用日志也可以看到很多连接请求，包括活跃会话信息
Database views and logs。pg_stat_activity可以看到所有的会话状态和具体的sql，以及在log中可以看到新连接认证登录信息
HikariCP leak detection。需要打开leakDetectionThreshold，HikariCP可以检测链接泄露，这个参数默认是关闭的

对于定位连接泄露，应该

检查应用日志，特别是问题刚发生的时间点
合理的监控系统
善于debug、trace等hikariCP设置
设置leakDetectionThreshold参数

可能的原因：

Misuse of streaming responses;
Misuse of raw connections;
Prolonged operations within @Transactional method (such as network invocation).
配置错误，参考
vitual thread，参考

References
#

https://github.com/brettwooldridge/HikariCP

https://github.com/brettwooldridge/HikariCP/issues/2148

https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing

https://blogs.oracle.com/opal/post/always-use-connection-pools

https://mkyong.com/jdbc/hikaripool-1-connection-is-not-available-request-timed-out-after-30002ms/

https://medium.com/@eremeykin/how-to-deal-with-hikaricp-connection-leaks-part-1-1eddc135b464

https://medium.com/@eremeykin/how-to-deal-with-hikaricp-connection-leaks-part-2-847a9629627f

Linux内存浅析

Mon, 12 Aug 2024 00:00:00 +0000

内存的基本概念
#

操作系统内存非常重要且比较复杂，其中有许多知识点仍然需要掌握才能更进一步分析程序问题。由于是初次全面系统地接触OS内存，目的是为了全面且低层次地理解linux内存相关概念，不会深入其中原理，所以本章也会尽量避免linux的源码知识。

物理内存和虚拟内存
#

(https://en.wikipedia.org/wiki/Memory_address)

物理内存（Physical memory）：物理内存是计算机系统中实际存在的硬件内存，通常是RAM（随机存取存储器）的形式。

虚拟内存（Virtual memory）：虚拟内存是一个线性区，并没有分配实际物理内存，程序认为它们有比实际物理内存更大的地址空间。虚拟内存的实现允许程序访问比物理内存更大的地址范围，而不需要所有数据都同时存在于物理内存中。内核释放物理页面是通过释放线性区，找到其所对应的物理页面，将其全部释放的过程。

内存管理单元（Memory Management Unit，MMU）：是一个硬件组件，负责将程序中使用的虚拟地址转换为实际在物理内存中存储数据的物理地址。MMU的主要任务是执行地址映射。

页表（Page Table）：页表是一种数据结构，用于存储虚拟地址空间与物理地址空间之间的映射关系。程序试图访问虚拟内存时，MMU通过查询页表确定相应的物理地址。

系统调用流程： https://users.cs.utah.edu/~aburtsev/cs5460/lectures/lecture19-memory-management/lecture19-memory-management.pdf

（图有点糊，最上面的字是 “User Space|Kernel Space”）

用户程序通过C库或通过系统调用才能访问内核系统，用户程序不能直接访问内核系统
内核系统通过MMU访问物理内存；通过驱动访问磁盘其他外部设备
虚拟内存系统（上图中的VM Subsystem）中包含buddy、slab算法等

用户空间和内核空间
#

进程虚拟地址空间分成了用户空间和内核空间。

用户空间：

用户进程在内存中运行的空间
这部分空间被保护，系统防止其他进程访问。（共享内存除外）
但是内核进程可以直接访问用户进程

内核空间：

内核空间是内核进程使用的空间
在内核空间，运行操作系统的内核代码，这些代码具有更高的特权级别，可以直接访问系统硬件、管理进程、进行文件系统操作等

上下文切换：

当用户程序需要访问系统服务或执行需要更高权限的操作时，会触发从用户空间到内核空间的上下文切换。
上下文切换是一种操作系统机制，用于保存和恢复程序的状态，确保在用户程序和内核之间切换时不会发生数据丢失。

用户空间和内核空间的划分是为了提供安全隔离，防止用户程序直接影响操作系统的关键部分。早期的操作系统和Dos系统不区分内核、用户空间，一个程序的错误或恶意行为可能对整个系统造成影响。

(https://www.zhihu.com/tardis/zm/art/66794639?source_id=1003)

32位系统：总共4GB地址空间，3G UserSpace|1G KernelSpace

64位系统：总共256TB地址空间，128T UserSpace|128T KernelSpace

2^32=4GB，2^64=16777216TB，为什么是64位的系统是256TB地址空间呢？

64-bit computing wiki上有解释。简而言之，256TB (256 × 1024^4 bytes) 的内存地址足够了，目前以及能想象的未来还不会出现16EB (16 × 1024^6 bytes)的内存。

进程虚拟地址空间
#

每个进程通常都有自己的独立虚拟内存空间。虚拟内存是一种抽象概念，为每个运行的进程提供了似乎是连续且私有的地址空间，使得每个进程都感觉自己拥有整个计算机系统的全部内存。

进程虚拟地址空间分布：

（https://www.sohu.com/a/392831824_467784）

mmap 映射区域至顶向下扩展，mmap 映射区域和堆相对扩展，直至耗尽虚拟地址空间中的剩余区域，这种结构便于C运行时库使用mmap 映射区域和堆进行内存分配。
栈区(Stack)：存储程序执行期间的本地变量和函数的参数，从高地址向低地址生长
堆区(Heap)：动态内存分配区域，通过 malloc、new、free 和delete 等函数管理
未初始化变量区(BSS)：存储未被初始化的全局变量和静态变量
数据区(Data)：存储在源代码中有预定义值的全局变量和静态变量
代码区(Text)：存储只读的程序执行代码，即机器指令。

进程虚拟地址空间分布和映射：

(https://velog.io/@mysprtlty/%EA%B0%80%EC%83%81-%EB%A9%94%EB%AA%A8%EB%A6%AC%EC%99%80-%EA%B0%80%EC%83%81-%EC%A3%BC%EC%86%8C-%EA%B3%B5%EA%B0%84)

共享内存
#

前面讲到，虚拟地址空间中的用户空间不能被其他用户进程访问，如果通过内核区域实现多进程的用户访问同一内存数据，那么无法避免上下文切换。多进程的应用程序明显需要进程间的相互访问，所以一种直接可以实现用户进程访问同一物理内存的方法便应运而生，这就是共享内存。

共享内存是实现进程相互访问IPC（inter process communication）的机制之一，其他的方式还有message queues和semaphores。

（https://www.geeksforgeeks.org/inter-process-communication-ipc/）

由于本身就是多个虚拟内存地址空间对应一个物理内存地址空间，所以只要把两个进程的地址空间中的一段指向同一物理内存即可。

（https://www.softprayog.in/programming/interprocess-communication-using-system-v-shared-memory-in-linux）

共享内存（seems like）有许多实现方式，例如postgresql默认是mmap来实现共享内存，参考shared_memory_type参数和Managing Kernel Resources。其他的共享内存实现可参考这篇文章：宋宝华：世上最好的共享内存(Linux共享内存最透彻的一篇)

页表 PAGE TABLE
#

进程虚拟地址空间是对于每个进程而言的，而物理内存空间只有一个。那么如果映射、转换虚拟内存和共享内存呢？

(https://courses.engr.illinois.edu/cs241/sp2014/lecture/09-VirtualMemory_II_sol.pdf)

页表就是存储虚拟内存地址和物理内存地址的对应关系的地方。(这里有内存管理单元MMU和转换缓冲区TLB等的概念，我们简化一下，简单理解为虚拟内存到物理内存转换功能（PAGING），这里只看页表）。一个页表是一组页表项page table entries (PTEs) 组成，PTE存储了虚拟页和物理页间的map。

单个页表虽然可以实现内存到虚拟内存的转换功能，但是直接这样实现话，页表本身又占用了太多的内存。

(https://courses.engr.illinois.edu/cs241/sp2014/lecture/09-VirtualMemory_II_sol.pdf)

所以，需要对单个页表进行再分页：二级页表和四级页表

二级页表：

二级页表就是对单页表的再分页。4G 的空间需要 4M 的页表来存储映射表，如果将这 4M 分成 1K 个页（4K）, 这 1K 个页也需要一个表进行管理，我们成为页目录表，这个页目录表里面有 1K 项，每项 4 个字节，页目录表大小也就是 4K 。

四级页表：

对于 64 位系统，两级页表也不够，需要用四级页表

（https://maodanp.github.io/2019/06/02/linux-virtual-space/）

查看pagetable的大小：

[pg@lzl 2345]$ cat /proc/meminfo |grep PageTables
PageTables: 46736 kB

NUMA
#

Uniform Memory Access (UMA)：所有cpu访问内存的时间是等价的。UMA存在的问题是多个处理器通过一条总线访问内存，使共享总线上负载增加。多个处理器会争用memory controller造成冲突。另外总线带宽有限，会有访问延迟。

Non-Uniform Memory Access (NUMA)：一小组CPU一起访问它们自己的本地内存。存在多组CPU和它们的内存组时，每组CPU和内存组就构成一个NUMA节点(node)。

UMA：

NUMA：

（https://users.cs.utah.edu/~aburtsev/cs5460/lectures/lecture19-memory-management/lecture19-memory-management.pdf）

NUMA的基本特性：

cpu访问本地node的内存要比remote的更快
默认情况下linux优先在cpu上分配本地内存，策略可以配置
每个node都有自己的内存结构
不是所有场景都适合numa，需要上层应用的适配

NUMA balancing：

通过自动转移任务到远端cpu或者拷贝远端数据到本地内存的方式，实现本地访问。redhat 7上默认打开。

转移任务或者拷贝数据本身也消耗资源，导致任务变慢，该特性可能不适用于部分应用，例如oracle的exdata就对NUMA做了针对优化。

numactl：

NUMA的OS配置工具。

numactl –show检视cpu和node情况，如下为4node总共64c256g，每个node有16c64g：

available: 4 nodes (0-3)
node 0 cpus: 0 1 2 3 4 5 6 7 32 33 34 35 36 37 38 39
node 0 size: 65418 MB
node 0 free: 310 MB
node 1 cpus: 8 9 10 11 12 13 14 15 40 41 42 43 44 45 46 47
node 1 size: 65536 MB
node 1 free: 41 MB
node 2 cpus: 16 17 18 19 20 21 22 23 48 49 50 51 52 53 54 55
node 2 size: 65536 MB
node 2 free: 82 MB
node 3 cpus: 24 25 26 27 28 29 30 31 56 57 58 59 60 61 62 63
node 3 size: 65536 MB
node 3 free: 43 MB

zone
#

NUMA把cpus和内存分成多个node（node 0，node 1，node 2 ···），UMA结构中也可以把cpu内存整体看成node 0。

在Linux中每个node用数据结构struct pglist_data表示，数据类型为typedef pg_data_t。每个node又分为多个zone，一个zone的数据结构为zone_t，数据类型为zone_struct，一般有3种数据类型ZONE_DMA, ZONE_NORMAL , ZONE_HIGHMEM，每个类型的zone有各种不同的功能。

（https://www.kernel.org/doc/gorman/html/understand/understand005.html）

32位zone的区域分布及功能：

ZONE_DMA：(<16MB)，Direct Memory Access (DMA)，古老的16 MiB限制，包含ISA devices。
ZONE_DMA32：由于很多设备在访问无法用 32 位寻址的内存时遇到问题，在x86-64新增了这样一个区域，该区域只存在于x86-64架构中。（详见ZONE_DMA32）
ZONE_NORMAL： (16MB to 896MB)，可直接映射到内核段的普通内存域；大部分内核操作都在NORMAL区进行，这是最重要的一个区域
ZONE_HIGHMEM：(>896MB)，标记了超出内核段的物理内存，不能直接被内核调用。

32位和64位的zone分布图：

https://users.cs.utah.edu/~aburtsev/cs5460/lectures/lecture19-memory-management/lecture19-memory-management.pdf

注意zone是对于物理内存而言的，虚拟内存的用户态转换为内核态后，才可以调用物理内存。下图便是虚拟内存空间的内核地址与物理地址空间中的zone的关系：

（https://wr.informatik.uni-hamburg.de/_media/teaching/wintersemester_2014_2015/kp-1415-memory-management.pdf）

检视zone：

cat /proc/zoneinfo

cat /proc/buddyinfo

cat /proc/pagetypeinfo

$ cat /proc/buddyinfo 
Node 0, zone DMA 1 1 1 1 1 0 1 1 1 1 2 
Node 0, zone DMA32 688 2080 1420 995 596 357 278 241 276 32 133 
Node 0, zone Normal 195748 204074 161167 119070 70791 33578 9556 2070 1034 2533 7328 
Node 1, zone Normal 11705 51467 36752 21326 11343 7309 5024 3403 2597 3056 10898

页
#

虚拟内存和物理内存被分割为固定大小的片段，一般是4KB大小。所以虚拟内存分割后就有了虚拟页，物理内存分割后就有了物理页（PP or PF，Physical Page or Page Frame），物理页也叫页帧，也是4KB。页帧代表系统内存的最小单位。

虚拟地址空间的每个页面都可以通过其描述项对应到物理地址空间的一个页帧上。

Huge Pages/Transparent Huge Pages
#

页是内存分配的最小单元（默认4K），当map分配大量的连续页时性能较差，Huge Page就是为了解决这个问题。大页不仅分配的时候更cheap，页表同时也相对会更小。hugepagesz 为2 MB或1 GB，默认是2MB。REDHAT 6开始实现了Huge Page。

由于手动管理大页比较麻烦，REDHAT 6开始同样也提供了自动管理大页的功能，即透明大页。

在oracle的数据库管理中，一般把大页打开给SGA使用，透明大页关闭。相关资料也比较多可行搜索资料。

同样的，PostgreSQL也可以开启大页。由于数据库一般会占用较多的操作系统内存，数据库开启大页一般可以降低内存分配的压力。

文件页与PageCache/匿名页与SwapCache
#

文件页可以map到磁盘上的文件，文件系统的读写会通过Page Cache当做缓存IO，脏数据周期或被调用时“sync”（or fsync之类的）到对应的磁盘，Page Cache就是用来“提升”磁盘性能的内存区域。

相对应的，没有文件相关联的页叫匿名页（Anonymous pages ），一般对应着heap、stack。当内存资源紧张时，内核会把不经常使用的匿名页中的数据写入到 Swap 分区或者 Swap 文件中。

简而言之：

page cache是与文件映射对应;
swap cache是与匿名页对应

（https://www.slideshare.net/raghusiddarth/memory-management-in-linux-11551521?from_search=2）

以上page cache的图是站在操作系统的角度来看的，应用程序（如数据库）的写入也可以不delayed，甚至不通过Page cache。

内存分配
#

内存分配也十分复杂，涉及很多概念。两种常见的内存分配方式为buddy、slab

buddy
#

buddy系统用于分配连续的内存页，每个zone都有各自的buddy系统。buddy系统划分了大块内存以响应内存分配请求，同时由于合并的特性可以减少系统内存碎片化。

buddy allocator将内存分为2的幂次方的页，最大阶数为10：

当内存请求大于已有块的大小时，系统会将较大的块分割成两个相等大小的伙伴块。当内存释放时，系统会尝试将相邻的伙伴块合并成一个更大的块：

释放⻚⾯的时候就直接把⻚⾯放回空闲列表，如果其之前拆开的另⼀半⻚⾯也没有被分配，则组合成双倍⻚⾯交给更⼤的列表，然后依次循环，直到不能再循环或者已经到头。

由于高阶页因为不停的分配没有了，此时再申请高阶页时便会触发碎片问题：

等待内存回收成功后，buddy本身会合并低阶到高阶，然后分配高阶页面：

（The implementations of anti pages fragmentation in Linux kernel https://teawater.github.io/presentation/antif.pdf）

然而内存回收也可能赶不上分配速度，所以buddy系统不总是那么理想。

分析示例：

$ cat /proc/buddyinfo 
Node 0, zone DMA 0 0 0 1 2 1 1 0 1 1 3 
Node 0, zone DMA32 7 6 5 6 5 6 7 7 6 2 272 
Node 0, zone Normal 317681 38869 31620 19250 8931 2579 815 182 19 5 0 

上述包含3个ZONE：DMA，DMA32，Normal
阶数： 0 ~ 10，即buddy里对应每一阶对应的数量。buddy最大的阶数为10, 即1024个pages，也就是4MB
如Normal 行第3列表示有31620个2^2连续内存块可以用
以此类推，越是往后的空间，就越是连续，数目越多，就代表这个大小的连续空间越多，当大的连续空间很少的时候，也就说明内存碎片已经不少
另外，全部加起来就是当前free状态的内存

通过buddyinfo判断内存碎片问题：

#host 1
Node 0, zone Normal 317681 38869 31620 19250 8931 2579 815 182 19 5 0 
#host 2
Node 0, zone Normal 7321 7833 10885 8514 2311 1644 1663 1302 1141 7384 80675 

上面是两个主机的内存情况，对比可以发现，下面这个主机的连续内存更多，上面那个主机存在内存碎片问题。

slab
#

slab分配器是基于对象进行管理的。slab系统是一种专门为内核内存设计的内存分配算法。它通过将内存划分为固定大小的cache来实现，每个slab都包含同一类型的对象集。当有内存请求时，该算法首先检查适当的slab缓存中是否存在可用的对象。如果存在，则返回该对象。如果不存在，则算法会分配一个新的slab并将其添加到适当的cache中。

不同大小的对象对应不同的slab cache：

(https://bootlin.com/doc/training/linux-kernel/linux-kernel-slides.pdf)

虽然slab有不同的cache和对象，但是slab仍然使用的是物理连续的内存：

（https://i.stack.imgur.com/wo8Gg.png）

slab也有3种实现方式：

内存回收
#

推荐文章：linux强制回收内存,linux内存源码分析 - 内存回收

内存回收概述
#

当系统内存压力具大时，就会对系统的每个压力大的zone进程内存回收，内存回收主要是针对匿名页和文件页进行；
对于匿名页，内存回收过程中会筛选出一些不经常使用的匿名页，将它们写入到swap分区中，然后作为空闲页框释放到伙伴系统；
对于文件页，内存回收过程中也会筛选出一些不经常使用的文件页：
- 如果此文件页中保存的内容与磁盘中文件对应内容一致，说明此文件页是一个干净的文件页，就不需要进行回写，直接将此页作为空闲页框释放到伙伴系统中；
- 如果文件页保存的数据与磁盘中文件对应的数据不一致，则认定此文件页为脏页，需要先将此文件页回写到磁盘中对应数据所在位置上，然后再将此页作为空闲页框释放到伙伴系统中。
内存回收完成后，系统空闲的页框数量就会增加，能够缓解内存压力，但在回收过程中会对系统的IO造成很大的压力，所以，在系统内，为每个zone会设置一条线，当空闲页框数量不满足这条线时，就会执行内存回收操作，而系统空闲页框数量满足这条线时，系统是不会进行内存回收操作的。

zone的水位线与kswapd
#

（https://vivani.net/2022/06/14/linux-kernel-tuning-page-allocation-failure/)

当可用内存较低时kswapd守护进程会被唤醒以释放页

**pages_low:**当可用的空闲页面数量低于pages_low 时，buddy allocator会唤醒 **kswapd **进程，内核开始将页换出到硬盘。
**pages_min:**当可用页面数量达到 pages_min时，说明页回收工作的压力就比较大，因为内存域中急需空闲页。分配器将以同步的方式执行 kswapd 工作，有时也称为直接回收。
**pages_high:**一旦 kswapd 被唤醒开始释放页面，只有在可用页面数量达到pages_high时，内核才认为该区域是“平衡的”。如果水位线达到pages_high，kswapd 将重新进入休眠状态。空闲页多于pages_high，则内核认为zone的状态是理想的。

内存回收以zone为单位进行，/proc/zoneinfo可以查看min、low、high的值。

内存分配和回收的种类
#

快速内存分配：是get_page_from_freelist()函数，通过low阀值从zonelist中获取合适的zone进行分配，如果zone没有达到low阀值，则会进行快速内存回收，快速内存回收后再尝试分配。

慢速内存分配：当快速分配失败后，也就是zonelist中所有zone在快速分配中都没有获取到内存，则会使用min阀值进行慢速分配，在慢速分配过程中主要做三件事，异步内存压缩、直接内存回收以及轻同步内存压缩，最后视情况进行oom分配。并且在这些操作完成后，都会调用一次快速内存分配尝试获取页框。

（https://blog.csdn.net/weixin_35094083/article/details/116688112）

不同的内存分配路径中，会触发不同的内存回收方式，对zone的内存回收方式分为两种：

后台内存回收（kswapd）：在物理内存紧张的时候，会唤醒 kswapd 内核线程来回收内存，这个回收内存的过程异步的，不会阻塞进程的执行。
直接内存回收（direct reclaim）：如果后台异步回收跟不上进程内存申请的速度，就会开始直接回收，这个回收内存的过程是同步的，会阻塞进程的执行。

内存压缩
#

内存压缩见：内存的监控-/proc/pagetypeinfo部分

LRU
#

对于zone的内存回收，它针对三样东西进程回收：slab、lru链表中的页、buffer_head。这里只讨论内存回收针对lru链。

lru链表主要作用就是将页排序，将最应该回收的页放到最后面，最不应该回收的页放到最前面，然后进行内存回收时，就会从后面向前面进行扫描，将扫描到的页尝试进行回收。

lru链表描述符，里面有5个lru链表，活动/非活动匿名页lru链表，活动/非活动文件页lru链表，禁止换出页链表：

（https://lpc.events/event/11/contributions/896/attachments/793/1493/slides-r2.pdf）

内存回收来说，它只会处理前面4个lru链表，也就是活动匿名页lru链表，非活动匿名页lru链表，活动文件页lru链表，非活动文件页lru链。回收到足够页框后直接返回：快速内存回收、kswapd内存回收中会这样做。

可以通过meminfo查看global lruvec（理解为lru区域）：

## cat /proc/meminfo |grep -i active
Active: 597380 kB
Inactive: 601920 kB
Active(anon): 10896 kB
Inactive(anon): 117376 kB
Active(file): 586484 kB
Inactive(file): 484544 kB

实际上lruvec不止一个，cgroup、NUMA node都有自己的lruvec，同时global也有自己的lruvec

drop cache
#

Dropcache会记录哪些页面是缓存文件系统数据的页面，并在页面被强制回收时把数据写回磁盘，以便下次访问时可以再次缓存。

默认值：vm.drop_caches = 0。默认情况下，Linux内核不会自动清除缓存
/proc/sys/vm/drop_caches的值设置为1：内核会清除未使用的页缓存pagecache。
/proc/sys/vm/drop_caches的值设置为2：内核会释放dentry和inode所使用的内存，dentry和inode是文件系统元数据结构，用于存储文件和目录的信息。
/proc/sys/vm/drop_caches的值设置为3：效果相当于1+2，释放所有未使用的缓存

当内核决定回收某些缓存时，它会检查缓存中的数据与硬盘上的数据是否一致。如果数据不一致，内核需要将数据写回磁盘，然后才能回收该缓存。这个过程可能导致IO飙高。在进行Drop Cache操作时，建议不要有任何重要的I/O操作，因为这可能会影响系统性能。

操作命令：

echo 3 > /proc/sys/vm/drop_caches #刷cache缓存
echo 0 > /proc/sys/vm/drop_caches #恢复默认值

内存的监控
#

如果不了解内存的基本知识其实很难看懂内存监控信息，在有了以上内存基础的情况下，我们来一个个过内存相关监控命令、工具的使用。

/proc 目录有些什么？
#

/proc 主要是进程 (process)信息和系统信息

其中system information部分，有些是linux提供的一些系统状态的接口，可以查看整个操作系统层面的监控信息，比如slabinfo,swaps,zoneinfo,buddyinfo

另一部分process是每个进程运行数据和状态信息，cd到对应进程目录下，可以看到对应进程的持有的fd和进程内存信息等

进程下面还有线程，线程的信息目录：/proc/[pid]/task/[tid]/，其下内容跟进程目录下面差不多。

更多的proc信息参考proc(5) — Linux manual page

/proc/meminfo
#

/proc/meminfo是了解当前Linux系统内存使用状况的主要接口，最常用的free,vmstat,ps等命令就是通过它获取数据。/proc/meminfo的信息要更加全面，下面只列出一些常见的信息，详细含义可参考红帽文档

#一般的内存信息
cat /proc/meminfo | grep "Mem"
MemTotal: 994328 kB		#总内存大小（减去一些保留的和内核的）
MemFree: 66428 kB		#完全没有用到的物理内存
MemAvailable: 207192 kB		#在不使用交换空间的情况下，启动一个新的应用最大可用内存的大小

#IO缓冲区
cat /proc/meminfo | grep -e "Buffers" -we "Cached" 
Buffers: 12820 kB		#raw disk block使用的IO缓冲区，不会超过20MB
Cached: 254592 kB		#磁盘使用的page cache size（包含tmpfs和shmem不包含SwapCached）

#swap
cat /proc/meminfo | grep "Swap" 
SwapCached: 13936 kB		#swap cache中包含的是被确定要swapping换页，但是尚未写入物理交换区的匿名内存页
SwapTotal: 945416 kB		#swap空间总大小
SwapFree: 851064 kB		#剩余的swap的大小

#lru活动与非活动页数（一眼懂）
cat /proc/meminfo | grep -e "Active" -e "Inactive" 
Active: 194308 kB
Inactive: 553172 kB
Active(anon): 59024 kB
Inactive(anon): 437264 kB
Active(file): 135284 kB
Inactive(file): 115908 kB

#脏页
cat /proc/meminfo | grep -e "Dirty" -e "Writeback" 
Dirty: 0 kB		#还未写入的脏页
Writeback: 0 kB		#正在写入的脏页
WritebackTmp: 0 kB		#？temporary buffer for writebacks used by the FUSE module

#map信息
cat /proc/meminfo | grep -e "AnonPages" -e "Map"
AnonPages: 95296 kB		#map的匿名页
Mapped: 153192 kB		#map的文件页
DirectMap4k: 113336 kB		#map的4k内核页
DirectMap2M: 1900544 kB		#map的2M内核页
DirectMap1G: 0 kB		#map的1G内核页

#共享内存
cat /proc/meminfo | grep "Shmem"
Shmem: 28920 kB		#shmem和tmpfs的总内存大小
ShmemHugePages: 0 kB		#shmem和tmpfs的总大页内存大小
ShmemPmdMapped: 0 kB		#Shared memory mapped into userspace with huge pages

#内核内存（注意slab就是内核的）
cat /proc/meminfo | grep -ie "reclaim" -e "slab" -e "kernel"
KReclaimable: 35008 kB		#分配给内核的Reclaimable内存
Slab: 88752 kB		#slab cache
SReclaimable: 35008 kB		#slab cache中Reclaimable内存
SUnreclaim: 53744 kB		#slab cache中不能reclaim的内存
KernelStack: 5988 kB		#所有任务使用的kernel stack内存

#分配的可用内存（与MemAvailable含义不同）
## CommitLimit=[("total RAM pages" - "total huge TLB pages") * overcommit_ratio]/100 + "total swap pages"
## 简而言之，设置了MemAvailable的水位然后加上了swap就等于allocatable内存
cat /proc/meminfo | grep -ie "commit"
CommitLimit: 1442580 kB		#allocatable内存
Committed_AS: 3035924 kB		#预估当前最坏场景下，需要分配的内存


#虚拟内存
cat /proc/meminfo | grep -e "Vmalloc"
VmallocTotal: 34359738367 kB	#已分配的虚拟内存总大小
VmallocUsed: 34780 kB			#已使用的虚拟内存总大小
VmallocChunk: 0 kB			#最大的连续虚拟内存块

#page table占用的内存（一眼懂）
cat /proc/meminfo | grep PageTables
PageTables: 4120 kB

#大页内存
cat /proc/meminfo | grep -i hugepage
AnonHugePages: 32768 kB
ShmemHugePages: 0 kB
FileHugePages: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB

/proc/buddyinfo
#

buddyinfo由于信息简洁易懂，是最为常用的判断内存碎片问题的方式。详见 “内存分配-buddy章节”

$ cat /proc/buddyinfo 
Node 0, zone DMA 0 0 0 1 2 1 1 0 1 1 3 
Node 0, zone DMA32 7 6 5 6 5 6 7 7 6 2 272 
Node 0, zone Normal 317681 38869 31620 19250 8931 2579 815 182 19 5 0 

/proc/pagetypeinfo
#

pagetypinfo首先提供有关页块大小的信息。它提供与buddyinfo相同类型的信息，但按类型进行细分并详细说明每种类型的页的数量。

在理解pagetypeinfo前，需要先了解下memory compaction.

假如一个zone中的内存如下：

白色代表可用内存，红色代表已使用内存。以上内存的碎片化已经比较严重了，如果此时有请求2阶以上的内存，是无法分配的。此时该memory compaction发生作用了，压缩算法会在原有的zone上标记movable pages和Free pages链表。

movable扫描器从底部到顶部扫描，free扫描器从顶部到底部扫描，movable和free扫描器最终会在中间的某点相遇。然后通过页迁移将已使用页转移到zone的顶端。

page compation两种触发方式：

当分配page的时候，在LOW水位出现分配失败的时候，会尝试慢速内存分配，过程中就会出现page compaction
通过echo x > /proc/sys/vm/compact_memory来启动page compaction的动作，启动后内核线程kcompactd就会启动来进行页面整理

因为⻚⾯中数据被迁移到新位置，所以不会有采取的内存回收导致的那么⼤的性能问题，⽽且因为⽬标更明确，得到的连续⻚⾯的成本也更低。另外ANON⻚⾯回收是需要SWAP的，⽽这⾥不需要。

此时再来看下/proc/pagetypeinfo的信息：

$ cat /proc/pagetypeinfo 
Page block order: 9
Pages per block: 512

...（DMA忽略）
Node 0, zone Normal, type Unmovable 870 530 391 157 103 41 9 2 1 0 0 
Node 0, zone Normal, type Movable 5886 9235 5728 4072 1561 324 115 41 12 4 13018 
Node 0, zone Normal, type Reclaimable 3 4 8 11 2 3 1 1 1 0 0 
Node 0, zone Normal, type HighAtomic 0 0 0 0 0 0 0 0 0 0 0 
Node 0, zone Normal, type CMA 0 0 0 0 0 0 0 0 0 0 0 
Node 0, zone Normal, type Isolate 0 0 0 0 0 0 0 0 0 0 0 

不同的page被分类，称为pageblock。每个pageblock根据其类型不同分成⼏个列表，分配内存的时候，根据申请⻚⾯类型的不同，向相应的列表中申请⻚⾯，⽽释放的时候也会根据其所属pageblock回到相应列表。不同的pageblock：

Unmovable：无法压缩的page
Movable：可压缩的page
Reclaimable：可以回收的page
HighAtomic：为了缓解碎片问题增加的pageblock。高阶并且具备同等级别的才能从该pageblock中申请page
CMA：CMA 全称是 Contiguous Memory Allocator（连续内存分配器）
Isolate：⻚⾯不会被分配，⽤来帮助isolate⻚⾯。isolate⻚⾯的时候会将⻚块先设置为isolate防⽌其被释放

CMA看上去又是一个大块知识，可以简单理解为buddy系统的补充：

（内存之旅——如何提升CMA利用率？ https://ost.51cto.com/posts/10815）

smaps & maps & pmap
#

VSS/RSS/PSS/USS

查看一个进程占用的内存，常有VSS/RSS/PSS/USS四种形式，主要是内存计算的口径不同

（https://cloud.tencent.com/developer/article/1683708）

VSS（Virtual Set Size）只是一个虚拟空间大小，对内存实际占用量意义不大。
RSS（Resident Set Size）是对于计算一个进程总的内存占用量，包括共享库占用的共享内存大小，比如私有内存大小N，共享内存大小M，则RSS=N+M。肯能会有一点误解，因为像libc这种大部头库文件，共享者很多，都算在一个进程头上不科学。
PSS （Proportional Set Size）是单个进程运行时实际占用的物理内存大小，包含比例分配共享库占用的内存，一个共享库有 N 个进程使用，那么该库比例分配给 PSS 的大小为 1/N。PSS计算进程内存更准确，除了自己独占的内存，再加上分到的共享部分。
USS （Unique Set Size）是进程独自占用的物理内存大小，不包含共享内存

/proc/[pid]/maps

/proc/[pid]/maps可查看进程的虚拟内存的用户空间内存映射

[pg@lzl 2345]$ cat maps 
起始地址-结束地址 权限 偏移地址 主次设备号 inode编号												 文件名
00400000-00bae000 r-xp 00000000 fd:00 1093852 /pg/pg15.3/bin/postgres ---代码段
00dad000-00dc3000 rw-p 007ad000 fd:00 1093852 /pg/pg15.3/bin/postgres
00dc3000-00df5000 rw-p 00000000 00:00 0 
00f1e000-00f60000 rw-p 00000000 00:00 0 [heap] ---heap区
33a6000000-33a6022000 r-xp 00000000 fd:00 1976006 /lib64/ld-2.17.so
...
7fbe2ae09000-7fbe2ae0a000 rw-p 0000c000 fd:00 1975966 /lib64/libnss_files-2.17.so
7fbe2ae1b000-7fbe33ca7000 rw-s 00000000 00:04 12556 /dev/zero (deleted)
7fbe33ca7000-7fbe39b38000 r--p 00000000 fd:00 1181300 /usr/lib/locale/locale-archive
7fbe39b38000-7fbe39b3d000 rw-p 00000000 00:00 0 
7fbe39b46000-7fbe39b4d000 rw-s 00000000 00:10 12559 /dev/shm/PostgreSQL.3661351388
7fbe39b4d000-7fbe39b4e000 rw-s 00000000 00:04 32769 /SYSV0010c0b6 (deleted)
7fbe39b4e000-7fbe39b4f000 rw-p 00000000 00:00 0 
7fffe3933000-7fffe3948000 rw-p 00000000 00:00 0 [stack] --stack区 
7fffe397d000-7fffe397e000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]

(1)起始地址-结束地址：本段在虚拟内存中的地址范围 (2)权限：本段的权限; r-读，w-写，x-执行， p-私有 (3)偏移地址：即本段映射地址在文件中的偏移 (4)主次设备号：所映射的文件所属设备的设备号，对应vm_file->f_dentry->d_inode->i_sb->s_dev。匿名映射为0。其中fd为主设备号，00为次设备号。 (5)inode号：对应vm_file->f_dentry->d_inode->i_ino，与ls –i显示的内容相符，匿名映射为0。 (6)映射的文件名：对有名映射而言，是映射的文件名，对匿名映射来说，是此段内存在进程中的作用

以下是文心的分析：（真给它分析出来了，这是一个postgres主进程）

/proc/[pid]/smaps

/proc/[pid]/smaps 文件是基于 /proc/[pid]/maps 的扩展，比同一目录下的maps文件更为详细。每一个VMA都有如下的一系列数据：

[pg@lzl 2345]$ cat smaps 
00400000-00bae000 r-xp 00000000 fd:00 1093852 /pg/pg15.3/bin/postgres
Size: 7864 kB --VSS内存
Rss: 408 kB		--RSS内存
Pss: 140 kB		--PSS内存
Shared_Clean: 404 kB		--共享的、干净的内存大小
Shared_Dirty: 0 kB		--共享的、已脏的（即已修改）的内存大小
Private_Clean: 4 kB		--私有的、干净的内存大小
Private_Dirty: 0 kB		--私有的、已脏的内存大小
Referenced: 408 kB		--当前页面被标记为已引用或者包含匿名映射
Anonymous: 0 kB		--匿名页
AnonHugePages: 0 kB		--匿名大页
Swap: 0 kB		--已交欢出的内存大小
KernelPageSize: 4 kB		--内核页面大小
MMUPageSize: 4 kB		--pagetable页面大小
...
7fffe3933000-7fffe3948000 rw-p 00000000 00:00 0 [stack]
Size: 88 kB
Rss: 16 kB
Pss: 16 kB
...

现在知道，maps是进程的内存映射信息，smaps还包含每段映射的内存大小（VSS,RSS,PSS）。

可通过查看进程smaps的PSS、RSS等数据，计算出进程的内存用量，注意单位是kb

所有进程的物理总内存使用量：

grep Pss /proc/[1-9]*/smaps | awk '{total+=$2}; END {printf "%d kB\n", total }'

某进程PSS内存：

cat /proc/90875/smaps |grep Pss |awk '{sum+=$2 };END {print sum/1024}'

某进程的RSS内存 ：

cat /proc/68729/smaps |grep Rss |awk '{sum+=$2 };END {print sum/1024}'

某进程私有内存：

cat /proc/90875/smaps|sed '/zero/,/VmFlags/d' |grep Private |awk '{sum+=$2 };END {print sum/1024}'

pmap

pmap命令解析的是/proc/[pid]/maps和/proc/[pid]/smaps文件。参数不多，-x表示展示更多信息

[root@lzl ~]# pmap -x 2345
2345: /pg/pg15.3/bin/postgres -D /pg/1503data
Address Kbytes RSS Dirty Mode Mapping
0000000000400000 7864 212 0 r-x-- postgres
0000000000dad000 88 12 12 rw--- postgres
0000000000dc3000 200 36 32 rw--- [ anon ]
0000000000f1e000 264 12 8 rw--- [ anon ]
00000033a6000000 136 108 0 r-x-- ld-2.17.so
...
00007fbe2ae09000 4 0 0 rw--- libnss_files-2.17.so
00007fbe2ae1b000 145968 4396 4396 rw-s- zero (deleted)
00007fbe33ca7000 96836 8 0 r---- locale-archive
00007fbe39b38000 20 16 16 rw--- [ anon ]
00007fbe39b46000 28 4 4 rw-s- PostgreSQL.3661351388
00007fbe39b4d000 4 0 0 rw-s- [ shmid=0x8001 ]
00007fbe39b4e000 4 4 4 rw--- [ anon ]
00007fffe3933000 84 16 16 rw--- [ stack ]
00007fffe397d000 4 4 0 r-x-- [ anon ]
ffffffffff600000 4 0 0 r-x-- [ anon ]
---------------- ------ ------ ------
total kB 268896 5532 4540

pmap输出格式跟/proc/[pid]/maps差不多，每个vma地址一行，但是比maps多了VSS和RSS，这样就可以直接看进程虚拟内存的每个区域所使用的大小，帮助快速判断内存较多的区域在哪。

如果地址空间中[heap]太大，那有可能是堆内存产生了泄漏；再比如说，如果进程地址空间包含太多的 vma（可以把 maps 中的每一行理解为一个 vma），那很可能是应用程序调用了很多 mmap 而没有 munmap；再比如持续观察地址空间的变化，如果发现某些项在持续增长，那很可能是那里存在问题

分析示例

从主机的TOP的内存查看某pg backend进程内存看上去比较高，此时需要进一步分析map信息：

 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 
68729 postgres 20 0 5579004 5.116g 5.114g R 97.4 1.4 128:27.94 postgres: lzl: lzldb lzl 30.78.14.174(58067) DELETE 

查看这个进程Rss、Pss、Uss

cat /proc/68729/smaps |grep Rss |awk '{sum+=$2 };END {print sum/1024}'
5422.67 ---5.4G Rss
cat /proc/68729/smaps |grep Pss |awk '{sum+=$2 };END {print sum/1024}'
467.957	 ---467mb Pss
cat /proc/68729/smaps|sed '/zero/,/VmFlags/d' |grep Private |awk '{sum+=$2 };END {print sum/1024}'
179.605 ---179mb Uss

Rss-Uss=5.3G的共享内存，从Pss-Uss=290mb的proportion共享内存，大致能看出这个backend只是这个共享内存proportion的一小部分

$ pmap -x 68729
68729: postgres: pdmp: pdmpdata pdmp 30.78.14.174(46252) DELETE 
Address Kbytes RSS Dirty Mode Mapping
0000000000400000 6084 2444 0 r-x-- postgres
0000000000bf0000 4 4 4 r---- postgres
0000000000bf1000 52 52 52 rw--- postgres
...
00002b7f65bfa000 5441216 5365444 5365444 rw-s- zero (deleted) --这部分占用最多
00002b80b1daa000 48 0 0 r-x-- libnss_files-2.17.so
00002b80b1db6000 2044 0 0 ----- libnss_files-2.17.so
00002b80b1fb5000 4 4 4 r---- libnss_files-2.17.so
00002b80b1fb6000 4 4 4 rw--- libnss_files-2.17.so
00002b80b1fb7000 24 0 0 rw--- [ anon ]
00002b80ba001000 516 516 516 rw--- [ anon ]
00007fffe16f7000 132 88 88 rw--- [ stack ]
00007fffe175b000 8 4 0 r-x-- [ anon ]
ffffffffff600000 4 0 0 r-x-- [ anon ]

继续深入到smap分析，可以直接定位到zero (deleted)这部分

$ cat smaps 
00400000-009f1000 r-xp 00000000 fd:06 58726481 /paic/postgres/base/9.6.6/bin/postgres
...
2b7f65bfa000-2b80b1daa000 rw-s 00000000 00:04 72254 /dev/zero (deleted)
Size: 5441216 kB
Rss: 5365444 kB
Pss: 264618 kB
Shared_Clean: 0 kB
Shared_Dirty: 5365444 kB --共享的脏数据
Private_Clean: 0 kB
Private_Dirty: 0 kB
Referenced: 5364764 kB
Anonymous: 0 kB
AnonHugePages: 0 kB
Swap: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
VmFlags: rd wr sh mr mw me ms sd 

从以上分析可以得出：这是个pg的私有进程，变动了大量数据还没有刷脏，自己私有内存不多，大部分都是共享内存中占用的。这很有可能是一个pg中的事务变动了很多数据暂时还没提交。

另外，/dev/zero (deleted)在proc(5) — Linux manual page有解释:

Although these entries are present for memory regions that were mapped with the MAP_FILE flag, the way anonymous shared memory (regions created with the MAP_ANON | MAP_SHARED flags) is implemented in Linux means that such regions also appear on this directory. Here is an example where the target file is the deleted /dev/zero one:
 lrw-------. 1 root root 64 Apr 16 21:33
 7fc075d2f000-7fc075e6f000 -> /dev/zero (deleted)

“非专业翻译”：匿名页和共享页由 /dev/zero (deleted)表示

/proc/[pid]/status
#

status可查看进程的状态信息，包含一部分内存信息。

[root@lzl 2345]# cat status 
Name: postgres			---运行这个线程的命令
State: S (sleeping)	---进程状态
Tgid: 2345					---Thread group ID (i.e., Process ID)
Pid: 2345					---Thread ID
PPid: 1	 					---PID of parent process.
...
VmPeak: 268964 kB		---虚拟内存峰值
VmSize: 268896 kB		---虚拟内存当前值
VmLck: 0 kB
VmHWM: 13400 kB		---RSS的峰值
VmRSS: 5532 kB		---RSS的当前值
VmData: 528 kB		---数据段
VmStk: 88 kB		---stack段
VmExe: 7864 kB		---text段
VmLib: 3100 kB		---共享库代码段
VmPTE: 136 kB		---Page table entries
VmSwap: 308 kB		---swap的大小
Threads: 1			---该进程的线程数
....

status相对map，没有映射信息，内存数据更概况一些，也可以更直观的看到虚拟内存的每个段所占用的大小

查看SWAP用量最多的进程：

for file in /proc/*/status ; do awk '/VmSwap|Name|^Pid/{printf $2 " " $3}END{ print ""}' $file; done | sort -k 3 -n -r | head

cgroup memory
#

cgroup的memory控制现在已经很常见。一些主机参数需要在cgroup中设置。内存设置、监控信息均在/sys/fs/cgroup/memory/下面

cginfo查看CGROUP内存分配和使用情况： /opt/cgtools/cginfo -t perf -s mem

cginfo -t perf -s mem
==================== Cgroup Performance: memory ====================
DB_TYPE INSTANCE_NAME MEM_OOM MEM_FILE_GB MEM_MAP_GB MEM_USED_GB MEM_ALLO_GB ALLO_RATE MEM_GLOB_GB GLOB_RATE 
------- ------------- ------- ----------- ---------- ----------- ----------- --------- ----------- --------- 
postgres LZLDB 0 154.3 0.0 4.2 160.0 2.6% 375 1.1% 

查看比较详细的CGROUP内存使用状态: /sys/fs/cgroup/memory/[group]/memory.stat

$ cat memory.stat 
...
total_cache 167791534080
total_rss 4006932480
total_rss_huge 0
total_mapped_file 11747328
total_swap 0
total_pgpgin 792754417976
total_pgpgout 792712474991
total_pgfault 477971874868
total_pgmajfault 97318
total_inactive_anon 1610874880
total_active_anon 2408255488
total_inactive_file 73446166528
total_active_file 94332768256
total_unevictable 0

smem
#

smem是一款强大的展示内存使用情况的工具，读取/proc下面的smaps、meminfo等信息然后汇总输出。smem可以输出总体和具体map的内存情况，非常直观而且可以从不同的维度去分析，总体是一款分析内存使用非常好用的工具。

repo可直接下载，基本上解压即可使用。更多用法可参考smem memory reporting tool，以下只简单示例：

查看系统内存使用 -w：

[root@lzl ~]# smem -w -k
Area Used Cache Noncache 
firmware/hardware 0 0 0 
kernel image 0 0 0 
kernel dynamic memory 183.9M 84.0M 99.9M 
userspace memory 112.3M 62.2M 50.1M 
free memory 700.3M 700.3M 0 

查看每个用户的内存消耗 -u:

[root@lzl ~]# smem -s pss -urk
User Count Swap USS PSS RSS 
oracle 25 85.2M 30.8M 95.7M 383.0M 
root 93 112.4M 38.5M 42.3M 86.2M 
pg 12 5.9M 1.6M 2.5M 5.9M 
mysql 1 169.7M 1.7M 1.7M 2.0M 

查看某个用户的内存消耗-U

[root@lzl ~]# smem -U pg -k
 PID User Command Swap USS PSS RSS 
 2345 pg /pg/pg15.3/bin/postgres -D 364.0K 124.0K 134.0K 228.0K 
 2352 pg postgres: logical replicati 636.0K 144.0K 161.0K 196.0K 
 ...

过滤某个进程 -P（PROCESSFILTER，不是pid）：

[root@lzl ~]# smem -P postgres -p
 PID User Command Swap USS PSS RSS 
 2346 pg /pg/pg16.0/bin/postgres -D 0.01% 0.01% 0.01% 0.01% 
 2350 pg postgres: walwriter 0.01% 0.01% 0.01% 0.01% 
 ...

查看进程的mapping和内存占用情况 -m：

[root@lzl ~]# smem -P postgres -mpr -s pss
Map PIDs AVGPSS PSS 
<anonymous> 13 0.02% 0.24% 
[heap] 3 0.07% 0.20% 
/usr/lib64/libpython2.6.so.1.0 1 0.11% 0.11% 
/pg/pg15.3/bin/postgres 6 0.01% 0.06% 
/pg/pg16.0/bin/postgres 6 0.01% 0.06% 
/dev/zero 12 0.00% 0.03% 
[stack] 13 0.00% 0.02% 
...

smem看进程内存的USS\PSS\RSS很直观，不过有个问题，smem不能过滤pid，只能通过用户名或PROCESSFILTER去过滤，对于一个主机部署多个数据库实例时，过滤父PID或子PID，不是很友好。

top
#

top可实时的展示系统运行状态。top玩法也可以非常花哨，直接top运行同样可以展示非常多的信息。

使用top中的排序：

command sorted-field supported
M %MEM Yes
N PID Yes
P %CPU Yes
T TIME+ Yes

可以用%MEM来排序内存占用较多的进程，%MEM表示RES的内存百分比

top - 23:38:01 up 3 days, 22:32, 2 users, load average: 1.12, 1.42, 1.09
Tasks: 198 total, 13 running, 183 sleeping, 0 stopped, 2 zombie
Cpu(s): 0.0%us, 0.3%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 1020348k total, 325848k used, 694500k free, 1352k buffers
Swap: 4128760k total, 635872k used, 3492888k free, 150288k cached

 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 
18537 oracle 20 0 636m 24m 21m S 0.0 2.4 0:05.41 oracle 
18533 oracle 20 0 638m 24m 21m S 0.0 2.4 0:02.01 oracle 
... 
18509 oracle 20 0 634m 4384 4036 S 0.0 0.4 0:01.93 oracle 
 2639 root 20 0 729m 4052 1444 S 0.0 0.4 8:45.32 nautilus 

内存相关的解读：

第四行：内存使用信息：物理内存量、已用内存量、空闲内存量、缓冲内存量第五行：交换分区信息：可用交换区总量、已用交换区总量、空闲交换区总量、内核用于缓存的数量

第六行（内存相关）：

VIRT：VSS
RES：RSS（likely），anything occupying physical memory
SHR：Shared Memory Size。It will include shared anonymous pages and shared file-backed pages
%MEM： RSS百分比，A task’s currently resident share of available physical memory.

另外，查看内存的时候不要忘了看一眼进程的状态

S（示例第八列）Process Status：

D = uninterruptible sleep。不可中断的睡眠状态。表示该进程正在等待某个外部事件完成，如磁盘I/O操作或网络请求。通常情况下，D进程不能被直接终止。
I = idle
R = running
S = sleeping
T = stopped by job control signal
t = stopped by debugger during trace
Z = zombie

top命令可以看到主机的内存汇总信息，进程使用内存信息有RSS,SHR，粗略算一下RES-SHR=USS也可以计算私有内存的占用大小，另外还可以看到进程状态，所以top -p查看某进程的内存基本信息还是很好用的。

free
#

free展示主机的swap、内存的总量和剩余量，信息都是解析自/proc/meminfo

user@ubuntu:~$ free

 total used free shared buff/cache available
Mem: 8029356 794336 6297928 183384 937092 6816804
Swap: 0 0 0

total ：Total usable memory (MemTotal and SwapTotal in /proc/meminfo). This includes the physical and swap memory minus a few reserved bits and kernel binary code.
used ： Used or unavailable memory (calculated as total - available)
free：Unused memory (MemFree and SwapFree in /proc/meminfo) shared Memory used (mostly) by tmpfs (Shmem in /proc/meminfo)
buffers：Memory used by kernel buffers (Buffers in /proc/meminfo)
cache：Memory used by the page cache and slabs (Cached and SReclaimable in /proc/meminfo)。不仅有pagecache，还有SReclaimable的slab！
buff/cache：Sum of buffers and cache
available：cache包含pagecache和SReclaimable，free包含mem free和swap free；而available包含pagecache和即将被reclaim的内存；表示可用内存，但它们的计算方式不同，在实际应用中，由于缓存的存在，available通常会比free大

Page Cache： Page cache 主要用来作为文件系统上的文件数据的缓存来用，尤其是针对当进程对文件有 read/write 操作的时候。

Buffer Cache： Buffer cache 则主要是设计用来在系统对块设备进行读写的时候，对块进行数据缓存的系统来使用

ps aux
#

ps最大的好处就是从进程的角度分析进程状态（包括内存），COMMAND带[ ]标志的进程为kernel进程。

[pg@lzl ~]$ ps aux|head -1;ps aux|grep postgres
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
pg 2345 0.0 0.0 268896 236 ? Ss Jan01 0:03 /pg/pg15.3/bin/postgres -D /pg/1503data
pg 2353 0.0 0.0 269040 196 ? Ss Jan01 0:00 postgres: checkpointer 
pg 2354 0.0 0.0 269032 160 ? Ss Jan01 0:02 postgres: background writer 
pg 2356 0.0 0.0 269032 116 ? Ss Jan01 0:01 postgres: walwriter 
pg 2357 0.0 0.0 270508 824 ? Ss Jan01 0:02 postgres: autovacuum launcher 
pg 2358 0.0 0.0 270492 620 ? Ss Jan01 0:00 postgres: logical replication launcher 
pg 29818 0.0 0.0 103372 868 pts/0 S+ 09:16 0:00 grep postgres

VSZ,RSS单位是kb。内存信息比较少，VSZ没什么价值，RSS可以参考一下，没有PSS，USS这类信息，能分析的内容不多

ipcs
#

ipcs -m 是一个用于查询 IPC（进程间通信）共享内存资源的命令。分析共享内存的时候比较有用。

[pg@lzl ~]$ ipcs -m

------ Shared Memory Segments --------
key shmid owner perms bytes nattch status 
0x0010c0b6 32769 pg 600 56 6 

共享内存的 key 值
共享内存的编号 (shmid)
创建该共享内存的用户
权限（perms）
创建的大小（bytes）
连接到该共享内存的进程数（nattach）
共享内存的状态

此时连接一个会话到PostgreSQL，会多一个backend进程

------ Shared Memory Segments --------
key shmid owner perms bytes nattch status 
0x0010c0b6 32769 pg 600 56 7 

nattch+1，说明私有的backend进程也分享了一部分PG共享出来的内存。此时理解下面这个图也更深刻

（http://gauss.ececs.uc.edu/Courses/c4029/code/memory/virtual.pdf）

vmstat
#

vmstat是Virtual Meomory Statistics（虚拟内存统计）的缩写，可对操作系统的虚拟内存、进程、CPU活动进行监控。它是对系统的整体情况进行统计，不足之处是无法对某个进程进行深入分析。 有用的参数说明：

vmstat [options] [delay [count]]
OPTIONS:
-a 显示活跃和非活跃内存
-m 显示slabinfo
-s 显示内存相关统计信息及多种系统活动数量
-t Append timestamp to each line，在最后加个输出时间戳
-w Wide output mode.没有加w的话，输出比较窄，可以减少对不齐问题

-bash-4.1$ vmstat -w 1 3
procs -------------------memory------------------ ---swap-- -----io---- --system-- -----cpu-------
 r b swpd free buff cache si so bi bo in cs us sy id wa st
 0 1 661652 763348 324 76100 15 12 54 21 18 45 0 0 79 21 0
 2 1 661652 763340 304 75764 0 0 0 32 12 84 0 1 0 99 0
41 1 661652 760744 244 78300 228 0 3216 0 265 442 0 0 0 100 0

pidstat
#

pidstat是sysstat工具的一个命令，用于监控全部或指定进程的CPU、内存、线程、设备IO等系统资源的占用情况。

有用的参数说明：

pidstat OPTIONS interval [ count ] 
-d :Report I/O statistics 
-u :Report CPU utilization
-r :Report page faults and memory utilization
-w :Report task switching activity
-p :pid[,...] 
-l :Display the process command name and all its arguments.

查看某进程的内存情况：

-bash-4.1$ pidstat -r -l -p 2345
Linux 2.6.32-431.el6.x86_64 (lzl) 01/06/2024 _x86_64_ (1 CPU)

02:48:32 PM PID minflt/s majflt/s VSZ RSS %MEM Command
02:48:32 PM 2345 0.23 0.00 268896 240 0.02 /pg/pg15.3/bin/postgres -D /pg/1503data 

各类指标比较容易理解，VSZ,RSS说的都不想说了

minflt/s：这是“minor page faults”的缩写，指的是每秒发生的“次要页面错误”的数量。当一个程序试图访问一个不在物理内存中的页面时，就会发生页面错误。如果这个页面确实在硬盘上的交换区（swap）中，那么这是一个次要页面错误（minor page fault）。
majflt/s：这是“major page faults”的缩写，指的是每秒发生的“主要页面错误”的数量。与次要页面错误不同，主要页面错误发生在程序试图访问一个不在物理内存中，且也不在硬盘上的交换区中的页面时。

sar
#

sar（System Activity Reporter 系统活动情况报告）是目前 Linux 上最为全面的系统性能分析工具之一，可以从多方面对系统的活动进行报告，包括：文件的读写情况、系统调用的使用情况、磁盘 I/O、CPU 效率、内存使用状况、进程活动及 IPC 有关的活动等。SAR工具是sysstat软件包的一部分。

(https://www.brendangregg.com/Perf/linux_observability_sar.png)

sar非常强大，man的参数介绍就有1k多行，本篇不太可能解释完（偷懒）。

内存相关的参数：

sar OPTIONS interval [ count ] 
-B :Report paging statistics
-r :Report memory utilization statistics
-W :Report swapping statistics.
-H :Report hugepages utilization statistics
-s [ start_time ] ] [ -e [ end_time ] 

示例：sar查看内存利用率 sar -r 1 3

kbmemfree：这个值和 free 命令中的 free 值基本一致，所以它不包括 buffer 和 cache 的空间
kbmemused：这个值和 free 命令中的 used 值基本一致，所以它包括 buffer 和 cache 的空间
%memused：这个值是 kbmemused 和内存总量(不包括 swap)的一个百分比
kbbuffers : free 命令中的 buffer
kbcached： free 命令中 cache
kbcommit：保证当前系统所需要的内存，即为了确保不溢出而需要的内存(RAM + swap)
%commit：这个值是 kbcommit 与内存总量(包括 swap)的一个百分比

示例：sar查看内存页的状态 sar -B 1 3

pgpgin/s：表示每秒从磁盘或SWAP置换到内存的字节数(KB)
pgpgout/s：表示每秒从内存置换到磁盘或SWAP的字节数(KB)
fault/s：每秒钟系统产生的缺页数，即主缺页与次缺页之和(major + minor)
majflt/s：每秒钟产生的主缺页数
pgfree/s：每秒被放入空闲队列中的页个数
pgscank/s：每秒被 kswapd 扫描的页个数
pgscand/s：每秒直接被扫描的页个数
pgsteal/s：每秒钟从 cache 中被清除来满足内存需要的页个数
%vmeff：每秒清除的页(pgsteal)占总扫描页(pgscank + pgscand)的百分比

示例：sar查看swap信息 sar -W 1 3 报告说明

pswpin/s：每秒系统换入的交换页面（swap page）数量
pswpout/s：每秒系统换出的交换页面（swap page）数量

示例：sar查看历史内存信息 sar -B -s "08:00:00" -e "10:00:00"

#不加-e表示从开始时间点到现在的信息
$ sar -B -s "08:00:00"
09:45:01 PM pgpgin/s pgpgout/s fault/s majflt/s pgfree/s pgscank/s pgscand/s pgsteal/s %vmeff
09:46:01 PM 414429.37 395024.08 179478.63 0.07 352922.62 12003.78 4266.52 16269.42 99.99
09:47:01 PM 879907.08 337948.43 157970.97 0.02 402290.21 0.00 0.00 0.00 0.00
09:48:01 PM 772977.43 507343.30 150255.50 0.05 466742.08 0.00 5821.28 5821.27 100.00

以上pgsank表示kswapd进程介入回收内存的速度，pgscand表示直接内存回收的速度

gcore
#

gcore是gdb的一部分，可生成进程的core dump文件

示例dump一个PostgreSQL的backend进程

[root@lzl ~] ps -ef|grep 8296
pg 8296 2345 0 09:41 ? 00:00:00 postgres: pg lzldb [local] idle 
[root@lzl ~] cat /proc/8296/smaps |grep Pss |awk '{sum+=$2 };END {print sum/1024}' 
0.351562
[root@lzl ~] cat /proc/8296/smaps |grep Rss |awk '{sum+=$2 };END {print sum/1024}'
0.445312
[root@lzl ~] cat /proc/8296/smaps|sed '/zero/,/VmFlags/d' |grep Private |awk '{sum+=$2 };END {print sum/1024}'
0.0078125

8296进程的uss只有7.8 bytes，RSS 445 bytes。dump内存：

gcore -o /tmp/dump 8296

dump要花点时间，而且dump下来的文件比较大，并且会夯住进程

[root@lzl 8296]# ls -lh /tmp/dump.8296 
-rw-r--r-- 1 root root 252M Jan 7 10:59 /tmp/dump.8296

gdb
#

gdb可查看内存中具体位置和内容

示例查看PostgreSQL backend的缓存数据

1.新开一个会话查找一个分区表，会话保持不断开

[pg@lzl ~]$ psql
psql (15.3)
Type "help" for help.

postgres=> \c lzldb
You are now connected to database "lzldb" as user "pg".
lzldb=> select * from lzlpartition limit 1;
 appl_no | is_deleted | date_created | date_updated 
---------+------------+--------------+--------------
(0 rows)

2.pmap，smaps查看进程内存占用情况，找到想dump的内存段

[root@lzl 13393]# pmap -x 13393
13393: postgres: pg lzldb [local] idle 
Address Kbytes RSS Dirty Mode Mapping
0000000000400000 7864 1204 0 r-x-- postgres
..
00007fbe2ae1b000 145968 2164 176 rw-s- zero (deleted) ---RSS这里占用最多
00007fbe33ca7000 96836 0 0 r---- locale-archive
00007fbe39b38000 20 0 0 rw--- [ anon ]
00007fbe39b46000 28 0 0 rw-s- PostgreSQL.3661351388
00007fbe39b4d000 4 0 0 rw-s- [ shmid=0x8001 ]
00007fbe39b4e000 4 0 0 rw--- [ anon ]
00007fffe3933000 84 36 0 rw--- [ stack ]
00007fffe397d000 4 4 0 r-x-- [ anon ]
ffffffffff600000 4 0 0 r-x-- [ anon ]

[root@lzl 13393]# cat /proc/13393/smaps |grep -A 13 zero
7fbe2ae1b000-7fbe33ca7000 rw-s 00000000 00:04 12556 /dev/zero (deleted)
Size: 145968 kB
Rss: 2164 kB
Pss: 2164 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 1988 kB
Private_Dirty: 176 kB
Referenced: 2164 kB
Anonymous: 0 kB
AnonHugePages: 0 kB
Swap: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB

3.gdb dump memory

dump内存的起始位置为smaps中的vm地址+0x

[pg@lzl tmp]$ gdb
(gdb) attach 13393
(gdb) dump memory /tmp/delete.dump 0x7fbe2ae1b000 0x7fbe33ca7000

4.查看dump文件

可简单通过strings 查看

[root@lzl 13393]# strings /tmp/delete.dump|grep lzl|sort|uniq
...
 @lzlpartition_202301
lzlpartition_202301
lzlpartition_202301_appl_no_idx
lzlpartition_202301_date_created_idx
...
lzlpartition_202306
lzlpartition_202306_appl_no_idx
lzlpartition_202306_date_created_idx
 @lzlpartition_attach
lzlpartition_attach
 @nk_lzlpartition
nk_lzlpartition
select * from lzlpartition limit 1;

会话只要查询了分区表，就把所有分区、索引等元数据全部缓存到backend进程中

注意：

gdb attach [pid]会夯住进程，不要随意执行
dump文件大小等于VSS，一般远大于RSS/PSS/USS

内存小节
#

references
#

轻松突破文件IO瓶颈：内存映射mmap技术 https://blog.51cto.com/u_15481245/6582927

一步一图带你深入理解 Linux 物理内存管理 https://cloud.tencent.com/developer/article/2352771?areaId=106001

从DBA的角度系统学习一下内存管理 https://mp.weixin.qq.com/s/CybzGP44dVWQN5hfFrVx7A

https://linux2me.wordpress.com/2017/09/15/linux-introduction-to-memory-management/

Memory management in Linux https://www.slideshare.net/raghusiddarth/memory-management-in-linux-11551521?from_search=2

Linux Performance Tunning Memory https://www.slideshare.net/shayc1/linux-performance-tunning-memory?from_search=4

Linux内核这样学才能学会（内存篇） https://mp.weixin.qq.com/s/lKKHH1MMiZbnIbDQt3-IAQ

https://courses.engr.illinois.edu/cs241/sp2014/lecture/09-VirtualMemory_II_sol.pdf

Linux的进程虚拟地址空间 https://maodanp.github.io/2019/06/02/linux-virtual-space/

redhat官方文档 https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/virtualization_tuning_and_optimization_guide/chap-virtualization_tuning_optimization_guide-numa

Data Processing on Modern Hardware https://db.in.tum.de/teaching/ss21/dataprocessingonmodernhardware/MH_8.pdf?lang=de

Chapter 2 Describing Physical Memory https://www.kernel.org/doc/gorman/html/understand/understand005.html

各类命令的man手册

linux强制回收内存,linux内存源码分析 - 内存回收(整体流程) https://blog.csdn.net/weixin_35094083/article/details/116688112

内存之旅——如何提升CMA利用率？ https://ost.51cto.com/posts/10815

The implementations of anti pages fragmentation in Linux kernel https://teawater.github.io/presentation/antif.pdf

T H E /proc F I L E S Y S T E M https://www.kernel.org/doc/Documentation/filesystems/proc.txt

The /proc/meminfo File in Linux https://www.baeldung.com/linux/proc-meminfo

the proc filesystem https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/s2-proc-meminfo

linux的/proc/{pid}/maps介绍及使用(定位内存泄漏) https://blog.csdn.net/mijichui2153/article/details/123934531

Linux top命令的cpu使用率和内存使用率 https://blog.csdn.net/weixin_45030965/article/details/127693042

smem memory reporting tool https://www.selenic.com/smem/

Linux performance optimization https://feiyang233.club/post/linux/

gdb onlinedocs https://sourceware.org/gdb/current/onlinedocs/gdb

Linux_Core_Dumps https://averageradical.github.io/Linux_Core_Dumps.pdf

最后的DBA

UUIDv4和v7两篇精彩文章-碰撞和性能

太长不看 #

UUID v4 碰撞事故 #

原因一：熵源不可靠 #

原因二：npm uuid 包有已知 bug #

原因三：Linux 内核 /dev/random 竞态 #

原因四：Go 的 UUID 库不检查返回值 #

原因五：AMD CPU RNG 的历史缺陷 #

UUID v7 在 PG 16 中的性能对比 #

测试条件 #

性能结果 #

为什么差这么多 #

总结 #

一个 DBA 视角看 0526 安可数据库名单

太长不看 #

最新名单 #

开闸放水 #

影响 #

令人唏嘘 #

参考 #

当 PostgreSQL 成为 AI 的双手——Bruce Momjian 的 MCP Server 实战

理论层：用 Transformer 解释 RAG → MCP 的演进（Slide 1-33） #

RAG vs MCP：一句话说清 #

“是词还是 MCP”——那套向量嵌入图解 #

这个模型对吗？ #

实践层：两个能跑的 demo（Slide 34-69） #

Demo 1：让 ChatGPT 读取真实世界的盖革计数器 #

Demo 2：用 PG 做椒盐卷饼店的库存系统 #

生产还差多远 #

两层之间 #

个人博客上线

上线啦！ #

亮点 #

上线感悟 #

花了多少钱 #

最后 #

参考 #

案例-起库失败和sysv共享内存

问题现象 #

报错分析：pre-existing shared memory block #

3种共享内存 #

源码分析 #

sysv shmem #

什么是shmkey和shmid #

PG是怎么拿shmkey的 #

PG在云环境下的shmkey #

shmid的关联性 #

测试 #

生产问题复现 #

实例奔溃正常起库 #

持有文件但不持有shmem #

删除postmaster.pid文件起库失败 #

关闭一个其他库，启动当前库 #

报错分析：lock file "postmaster.pid" already exists #

总结 #

AI时代下的DBA、写作、学习和未来

AI时代的写作 #

对运维的思考 #

运维的本质和AI Ops #

AIOps、Agent的研究成果 #

DBA的价值 #

DBA的价值是拍板背锅侠吗 #

Postgres DBA的特殊性 #

为什么还要学习 #

为什么大家还爱看"人"写的文章 #

偏爱漏洞的心理 #

白嫖大神的ATTENTION #

AGI能解决所有问题吗？ #

驳Musk #

AI解决不了所有问题的数学基础 #

总结 #

ref #

pg数据库运维经验2025

CPU #

执行计划 #

DISTINCT不准确 #

generic plan的干扰 #

行锁导致的LWLock:Lockmanager #

idle连接数 #

太长不看
#

UUID v4 碰撞事故
#

原因一：熵源不可靠
#

原因二：npm uuid 包有已知 bug
#

原因三：Linux 内核 /dev/random 竞态
#

原因四：Go 的 UUID 库不检查返回值
#

原因五：AMD CPU RNG 的历史缺陷
#

UUID v7 在 PG 16 中的性能对比
#

测试条件
#

性能结果
#

为什么差这么多
#

总结
#

太长不看
#

最新名单
#

开闸放水
#

影响
#

令人唏嘘
#

参考
#

理论层：用 Transformer 解释 RAG → MCP 的演进（Slide 1-33）
#

RAG vs MCP：一句话说清
#

“是词还是 MCP”——那套向量嵌入图解
#

这个模型对吗？
#

实践层：两个能跑的 demo（Slide 34-69）
#

Demo 1：让 ChatGPT 读取真实世界的盖革计数器
#

Demo 2：用 PG 做椒盐卷饼店的库存系统
#

生产还差多远
#

两层之间
#

上线啦！
#

亮点
#

上线感悟
#

花了多少钱
#

最后
#

参考
#

问题现象
#

报错分析：`pre-existing shared memory block`
#

3种共享内存
#

源码分析
#

sysv shmem
#

什么是shmkey和shmid
#

PG是怎么拿shmkey的
#

PG在云环境下的shmkey
#

shmid的关联性
#

测试
#

生产问题复现
#

实例奔溃正常起库
#

持有文件但不持有shmem
#

删除postmaster.pid文件起库失败
#

关闭一个其他库，启动当前库
#

报错分析：`lock file "postmaster.pid" already exists`
#

总结
#

AI时代的写作
#

对运维的思考
#

运维的本质和AI Ops
#

AIOps、Agent的研究成果
#

DBA的价值
#

DBA的价值是拍板背锅侠吗
#

Postgres DBA的特殊性
#

为什么还要学习
#

为什么大家还爱看"人"写的文章
#

偏爱漏洞的心理
#

白嫖大神的ATTENTION
#

AGI能解决所有问题吗？
#

驳Musk
#

AI解决不了所有问题的数学基础
#

总结
#

ref
#

CPU
#

执行计划
#

DISTINCT不准确
#

generic plan的干扰
#

行锁导致的LWLock:Lockmanager
#

idle连接数
#

idle in transaction
#

内存
#

内存问题和大页
#

值得注意的cgroup知识
#

未解之谜
#

关注OS
#

关注OS的一切
#

物理读
#