有想法的py工程师-CSDN博客

原创 PostgreSQL archive_command 场景下的 postgres 免密 SSH 配置与排查实录

SELinux context 是否为 ssh_home_t。，无法使用 ssh-copy-id，只能手工注入。，jumpserver 仅用于“人工运维操作”。authorized_keys 权限是否 600。模拟主库，执行 archive_command。的系统上，免密会“看起来都对但就是不生效”。postgres home 权限是否 700。archive_command 运行时是。postgres 是否允许 ssh 登录。A → B 的 22 端口是否放通。仅用于人工登录，不参与运行时链路。

2026-02-05 10:21:50 417

原创一次 PostgreSQL WAL 积压的完整排查过程：从“网络/IO 怀疑”到“归档模型瓶颈”

ready 多，通常不是“失败”，而是“吞吐不够”PostgreSQL 的 archive_command 天生是。

2026-02-05 10:19:34 479

原创 PostgreSQL 分区表 + Debezium CDC：为什么 REPLICA IDENTITY FULL 不生效？

那只对这两个分区设置 FULL，先验证 before 是否正常、WAL 是否可控，再决定是否扩展到历史分区。否则即便 FULL 生效，Debezium 也可能拿不到完整 old row。若只需要少量字段的 before，优先考虑 trigger + audit 表。若忘记设置 FULL，新分区的 UPDATE again 没 before。对分区表，父表设置 REPLICA IDENTITY FULL 是不够的。FULL 有明显的 WAL 与磁盘风险，务必评估。CDC 中 before 是否存在，

2025-12-18 10:43:45 754

原创 PostgreSQL + Debezium CDC 踩坑总结

在生产环境中为 PostgreSQL（分区表）引入 Debezium CDC，将数据同步到 Kafka。大字段（bytea / text / json）极易造成 WAL 暴涨。在 pg_publication_tables 中看到的，实际上是。或 connector 使用了错误/历史的 publication。CDC 模式：逻辑复制（Logical Replication）否则直接禁止 DELETE / UPDATE（数据库级保护）或复用已有 publication（已包含其他业务表）

2025-12-18 09:25:54 1111

原创 Amazon Linux 2 安装 postgresql-contrib 导致 PostgreSQL 小版本自动升级问题总结

摘要：在Amazon Linux 2上安装PostgreSQL的pg_trgm扩展时，直接安装postgresql-contrib包会触发PostgreSQL小版本自动升级（如14.12→14.20），存在生产环境风险。原因在于contrib包对主程序有严格版本依赖。解决方案包括：（1）安装与当前版本一致的contrib包（推荐）；（2）使用yum versionlock锁定版本后再安装。操作前务必通过yum install --assumeno验证依赖关系，避免非预期升级

2025-12-18 09:00:00 639

原创 PostgreSQL × Debezium × Kafka CDC（Change Data Capture）监控体系

你的上一条回答：payload.ts_ms - payload.source.ts_ms。识别延迟是来源于 DB、Debezium、Kafka 或下游。WAL 激增会导致 Debezium backlog。下游逻辑错误不会影响 Debezium，但会产生延迟。会影响 WAL 写入速度与 Debezium 延迟。Debezium 延迟会导致 WAL 无法被回收。Kafka 的性能直接影响整个 CDC 延迟。若 ISR 不健康，会影响 Kafka 写速度。Kafka 负载高会导致 CDC 暂停/堆积。

2025-12-09 09:56:28 1030

原创 PostgreSQL × Debezium × Kafka 时间戳机制 [附对照表]

表示该行变更（INSERT/UPDATE/DELETE）在 PostgreSQL 中被写入 WAL buffer 的时间。Debezium 解析 WAL 并封装 Kafka 消息的时间。它来自 PostgreSQL 本身，记录在 WAL 日志中。因此这个时间可能比 source.ts_ms 晚很多。数据库 WAL 记录的时间（变更发生时的真实时间）立刻生成，包含 timestamp。正常情况下几乎不可能出现分钟级延迟。不是 Debezium 读取时间。不是 Kafka 写入时间。不是 commit 时间。

2025-12-09 09:20:38 819

原创【Kafka 生产实战】如何判断消费组是否落后？Consumer Lag 全面解析 + 监控 + 实战案例

fetch.min.bytes / fetch.max.bytes：单次拉取数据大小上限。未消费的消息数量 = LOG-END-OFFSET - CURRENT-OFFSET。如果消费组一直落后，旧数据会在消费之前就被 Kafka 根据保留策略清理掉，max.poll.interval.ms：处理时间上限，避免误判为“挂掉”说明这几个 Topic 的消费组已经完全追上消息，运行正常。max.poll.records：一次拉取的最大消息数。fetch.max.wait.ms：拉取等待时间。

2025-11-21 08:30:00 707

原创【Kafka + Debezium 生产环境】如何监控 PostgreSQL 复制槽、Kafka Topic、Connector 状态（含 Zabbix 监控策略）

本文基于真实生产经验（Postgres slot 限制 5GB，Kafka topic 限制 8GB），给出一套。为了保证数据链路稳定，必须对 Kafka、Debezium、PostgreSQL 进行。下面是基于“5GB slot 限制 + 8GB topic 限制”的最佳触发阈值。意味着单个 slot 最多保留 5GB WAL。超过后会报错并停止同步。replication slot 保留 WAL 太多 → 撑爆磁盘。以下是必须监控的指标，按重要程度排序。基于这些参数，我将给出完整监控策略。

2025-11-20 11:44:09 1131

原创 PostgreSQL 索引算法全解析：原理、复杂度、流程图、图谱与 SQL 实例（超全收藏版）

但很多人对“索引算法”了解并不全面，只知道 B-tree，却不知道 PostgreSQL 实际支持。，分别适用于范围查询、JSON、全文、数组、空间、日志大表等完全不同的场景。：每个块记录 min/max（粗粒度索引）索引，是数据库性能优化中最关键的一环。：可扩展树结构，空间/模糊/范围。这是选择索引最重要的参考信息。JSONB、数组、全文搜索。通用、范围、排序、主流默认。JSONB、数组、全文搜索。空间、范围、模糊、KNN。

2025-11-20 08:45:00 420

原创 2025 年最大互联网事故：Cloudflare 宕机导致全球网站瘫痪

网站无法访问、网站打开很慢、页面加载失败、DNS 错误、API 请求失败、网站超时、网站 500 错误、503 错误、静态资源加载失败、图片加载失败、CSS 加载失败、网页渲染错误、服务器崩溃、网站宕机怎么办……SEO 排名恢复、站点地图提交、修复抓取错误、提升抓取预算、网站健康检查、SEO 日志分析、网站速度优化、多 CDN 方案、灾备方案、网站故障恢复、抓取频率提升、内容更新提升排名……许多依赖 Cloudflare 的机构网站同样出现宕机，包括监管部门与情报机构。

2025-11-19 09:50:38 1467

原创微软究竟怎么了？Bug 还在，AI 又来，Windows 用户怒火冲天

近来， Microsoft 在系统中大力推广 AI 功能，比如内置 AI 助手、自动截图记录、时间线回溯等，但与此同时，“Bug 还没修完”“用户隐私还没搞定”这些声音也越来越多。微软推出名为 Recall 的功能：在 Windows 中持续截屏、记录用户操作（包括用过的应用、访问过的网站、聊天记录等），然后用 AI 帮助用户“回忆”操作轨迹。不想被记录、不想被动接受、不信任微软的“帮你记忆”承诺。：语气中的“又”体现出一种反复、叠加的不满，用户感到微软在强推 AI ，而不是先修好基础系统。

2025-11-19 09:31:51 952

原创【PostgreSQL 索引巡检篇】如何判断索引是否有效？是否需要重建？完整巡检指南（实战 + SQL）

我们之前的库两年来从来没有进行过索引巡检，以至于进行索引重建后，较原来库体积减少了1/3，真的很吓人。CREATE INDEX CONCURRENTLY 失败会留下无效索引，需要巡检并清理。idx_tup_read / idx_tup_fetch → 判断是否回表。而绝大多数慢 SQL，其实都可以通过正确的索引巡检提前发现并避免。这一篇，我们完整讲透 PostgreSQL 的索引巡检体系。如果发现重复，可删掉扫描次数较低或意义较弱的索引。的索引，删除只会提升写入性能，不会带来负面影响。

2025-11-19 09:00:00 818

原创【PostgreSQL 索引实战篇】CREATE INDEX CONCURRENTLY 到底是不是零停机？详细原理 + 实战流程

PostgreSQL 会扫描全表，按照当前的数据构建一个初始索引。如果此时有长事务，会进入“等待状态”，你会看到索引构建似乎不动了。如果 idx_scan 长期为 0，说明索引未被 SQL 使用。这是 PostgreSQL 13+ 才有的功能，非常实用。掌握这一篇文章，你已经具备在生产环境安全构建索引的能力。然而很多人以为它是“完全零影响”的，事实并不是这样。很多人只知道它“不阻塞写”，但不知道为什么能做到。因为旧事务可能修改了某些行，需要等它们提交或回滚。索引元数据不包含“是否为并发建索引”的标记。

2025-11-19 08:45:00 575

原创【PostgreSQL 索引原理篇】为什么建了索引却没生效？一篇彻底讲清楚 B-tree / GIN / GiST / BRIN

明明给字段建了索引，信心满满地执行 SQL，结果一看执行计划——依旧是 Seq Scan，全表扫描跑得飞起，性能没丝毫改善。合理选择索引类型，往往比“盲目建索引”更重要。如果你也遇到过类似问题，那么这篇文章可能比加一台服务器更能提升你的查询性能。为了真正掌握它，你需要了解 PostgreSQL 索引背后的原理与规则。很多人对索引的理解停留在“有索引 = 查询快”。这两个索引类型可以让你解决大量“为什么不走索引”的问题。掌握这一篇，你已经能避免 80% 的索引相关性能问题。范围查询：>、<、BETWEEN。

2025-11-18 15:27:19 585

原创 PostgreSQL 索引从原理到实战：创建、删除、重建、查看一篇说透

本文从索引原理到 CONCURRENTLY 的使用，再到索引的创建、删除、重建、巡检等完整实践，为你提供一篇可以直接落地的 PostgreSQL 索引管理指南。：对于 TB 级大表，如果在线建索引依然耗时过长，可通过分区表、逻辑拆表、迁移影子表等方式结合实现零停机索引构建。是否使用了 Index Scan / Index Only Scan 是判断索引效果的关键。这是不少工程师的真实痛点。索引的创建、删除、重建都可以使用 CONCURRENTLY。善用部分索引、表达式索引、INCLUDE 覆盖索引。

2025-11-18 15:23:05 1559

原创 office 365 E3 for symphony/E3 dev免费订阅申请

还需要注意的是，如果你的Microsoft 365 Admin Center 账号选择的注册区域不是CN，那么你就需要拥有对应注册区域的Visa卡或百事达等国外银行卡，比如Microsoft 365 Admin Center账号注册时选择的区域是美国（US），那么你需要一个美国银行卡，但如果你的Microsoft 365 Admin Center注册区域是中国（CN）那么你就可以直接使用支付宝方式付款。适用于全新账号, 没有亿点点难度，旧账号亲测会出现租户报错的问题，直接注册新号最方便。

2025-11-14 17:24:34 2041

原创 PostgreSQL 大表字段回填最佳实践：高并发无锁更新 + 分批提交 + 完整进度显示

摘要：本文针对高QPS环境下大表NULL值更新问题，提出了一种安全高效的backfill方案。传统方法存在全表锁、长事务、性能下降等风险，本文方案采用小批量更新（1000行/批）+SKIPLOCKED锁机制+部分索引+分批提交技术，避免了业务阻塞和性能抖动。关键创新点包括：使用PROCEDURE实现显式提交、动态进度计算、批次耗时监控、可调节休眠间隔。通过生产案例验证，该方案在36万行数据更新时保持稳定性能，相比直接UPDATE方案，将系统影响降低90%以上。最佳实践建议：设置500-2000的批次大小，0

2025-11-14 15:06:56 988

原创 PostgreSQL 缓存污染 vs 缓存击穿你必须搞懂的两个痛点

你准备把书放到书架最右边（B-tree 右端叶子页），结果这块书架被搬走了（page 不在 buffer），你得重新拿新的书架板（磁盘读），就慢了。PG 大象肚子本来装的是营养（热点页），结果突然被人硬塞进一堆垃圾塑料袋（冷数据），导致它消化不良。pg_buffercache、pg_stat_io、pg_statio 系列、延迟采样脚本等。大表 dump 改用 --no-sync 或 --jobs=4（不要全速读）使用 pg_dump --no-sync + 低优先级 I/O。

2025-11-14 08:30:00 1578

原创 PostgreSQL 备份导致的 Cache Pollution（缓存污染）

摘要：PostgreSQL运维中常忽视缓存污染问题，即大规模顺序读操作（如pg_dump）占用shared_buffers，导致业务热点页被挤出，引发SQL性能下降。本文通过真实案例，分析pg_dump扫描大表时如何污染缓存，并提出工程解决方案：调整备份时间、限制并发、补偿预热、增大shared_buffers或改用物理备份。理解缓存污染机制有助于优化数据库稳定性，避免性能波动。

2025-11-13 09:13:40 666

原创 PostgreSQL Buffer缓存淘汰机制详解：Clock vs Clock-Sweep vs LRU

本文系统比较了数据库缓存淘汰算法LRU、Clock和PostgreSQL采用的Clock-Sweep。LRU通过双向链表精确反映访问顺序但实现复杂；Clock算法简化实现但仅区分0/1状态；Clock-Sweep在Clock基础上引入多级访问计数（usage_count），实现访问频率的渐进衰减。三者对比显示，Clock-Sweep在保持近似LRU效果的同时，具有实现简单、并发性能好等优势，特别适合数据库高并发场景，是PostgreSQL性能优化的关键设计之一。

2025-11-13 09:00:00 738

原创 PostgreSQL 可视化监控利器 —— pg_top 安装与使用全攻略（查看正在执行的SQL占用的资源）

《PostgreSQL性能监控神器pg_top实用指南》摘要：pg_top是一款类似Linux top命令的PostgreSQL实时监控工具，可直观展示数据库活跃连接、执行SQL、CPU/内存占用和锁状态等信息。文章详细介绍了pg_top的安装方法（支持主流Linux发行版）、常用快捷键操作（按CPU/内存排序、查看SQL文本和锁信息等）以及典型应用场景（定位性能问题、排查锁竞争）。通过对比其他监控工具，指出pg_top在实时诊断中的独特优势，并提供常见问题解决方案。

2025-11-12 09:50:44 1690

原创 PostgreSQL 生产环境慢SQL时的系统快照与PG快照抓取

20_pg_stat_activity.txt、21_blocking_graph.txt、22_pg_locks.txt：会话与锁。10_pg_stat_wal.txt、11_pg_stat_bgwriter.txt：WAL 与 bgwriter 指标。23_locks_by_pid_*.txt、24_activity_by_pid_*.txt：最慢 PID 附加。30_table_stats.txt、31/32/33_progress_*.txt：表统计与后台进度。

2025-11-12 09:29:27 610

原创 PostgreSQL 实战分析：UPDATE 语句性能异常与缓存击穿诊断

SQL 本身较为简单，仅更新数个字段，理论上应为毫秒级执行，但在监控中观测到延迟偶尔飙升至。同时，本文中讨论的情况，实际上就是从buffer中查询变为了从磁盘查询，也就是从ms到s的变化。从 pg_stat_activity 快照中可见，当触发慢 SQL 时，数据库并无显著锁等待，wait_event_type 为空，说明不是事务阻塞导致。d_heap（新增 heap 块读取量）在本周期突增，显示 UPDATE 过程中大量触发物理页加载，而 H_heap（命中）虽高但增长幅度小。

2025-11-11 17:46:46 747

原创 PostgreSQL insert 偶发变慢的原因分析 —— 从缓存击穿到系统 I/O

这些 SQL 操作并非批量导入（如 COPY），也不是长事务，而是普通的行级插入，主要涉及订单、账户、日志等高频表。在一次生产环境性能监控中，我们发现数据库中部分 INSERT 操作持续变慢，延迟从毫秒级飙升到秒级，触发告警。驻留率（cached ratio）低于 5%，即大多数页不在 shared_buffers 中。pg_stat_activity 显示 insert 查询运行时间较长，无锁等待。42_pg_buffercache_hot.txt —— 缓冲池中热点表命中率；

2025-11-11 17:32:41 983

原创 PostgreSQL 从库停止回放问题排查

PostgreSQL从库WAL回放暂停事件分析：从库因参数不匹配触发停机。调查显示从库WAL回放长期暂停（108天滞后），执行恢复命令后遇到主库max_connections参数变更（225）与从库设置（150）冲突，导致保护性停机。根本原因可能是备份脚本执行pg_wal_replay_pause()后未恢复。解决方案包括调整从库参数至主库相同值并重启服务，建议加强参数同步、权限控制和回放状态监控。该事件凸显了配置一致性和完整操作流程的重要性。

2025-11-03 10:21:21 956

原创 PostgreSQL 性能测试利器：pgbench 使用详解

摘要：本文详细介绍了PostgreSQL自带的性能测试工具pgbench的使用方法。作为官方基准测试工具，pgbench基于TPC-B模型，可评估数据库吞吐量和延迟等性能指标。文章内容包括环境准备、数据初始化（约100万条记录）、标准基准测试（10并发下达2950 TPS）和自定义SQL测试的实现步骤，并提供真实命令示例和结果解析。最后给出性能优化建议（如调整shared_buffers、优化SQL等）和推荐实践方案，特别强调在服务迁移前使用pgbench进行新服务器性能测试的重要性，同时提醒避免在生产环境

2025-10-31 14:46:21 1075

原创 PostgreSQL CDC 数据流系统中连接器配置详解

本文介绍了PostgreSQL CDC(ChangeDataCapture)通过Debezium连接器的配置方法。主要内容包括：1)CDC原理和架构流程，实现数据库变更实时捕获传输；2)详细解析连接器配置文件(pg-source.json)的关键参数，如表过滤、列排除、复制槽等配置；3)实际操作命令和Kafka调优建议，如调整消息大小限制；4)监控调试方法和注意事项，强调需及时清理复制槽避免磁盘爆满。该方案可高效实现数据变更的实时捕获与传输，同时通过精细化配置优化性能。

2025-10-31 08:45:00 586

原创从零搭建 Kafka + Debezium + PostgreSQL：打造实时 CDC 数据流系统

到这里，你已经完成了从零到可用的 Kafka + Debezium + PostgreSQL CDC 数据流系统。在现代数据架构中，越来越多系统需要捕获数据库的变更（例如新增订单、更新库存）并实时推送给下游系统。路径：/home/kafka/connect-configs/pg-source.json。：数据源，用逻辑复制（logical replication）输出 WAL 日志。：专门的数据库 CDC 工具，负责捕获数据库变更。：高性能消息中间件，负责数据流中转与缓存。的实时数据捕获（CDC）系统。

2025-10-30 16:23:38 1270

PostgreSQL生产库按需抓去Slow SQL快照与动态热点集合的Bash实现

空空如也