标签

数据库

PostgreSQL data_checksums:一个只读 GUC 背后十三年的数据完整性故事

来源: postgr.es 73
在 PostgreSQL 里, 只会返回 或 ——和 一样,它是个只读的预设参数,初始化集群时就定了,之后无法通过 修改。但这个看似平淡的开关,背后是一场持续了十三年、至今仍在演进的数据完整性战役。 PostgreSQL 的数据文件由一个个固定大小的页面(默认 8KB)组成。每次读写页面时,操作系统和硬件并不保证内容完好——磁盘静默损坏、内存位翻转、内...

在 Kubernetes 里跑 PostgreSQL 19 Beta:用 CloudNativePG 快速上手

来源: postgr.es 67
PostgreSQL 19 已进入 beta 阶段,社区开放了 beta 测试计划,邀请用户提前验证新特性与兼容性。如果你的工作负载已经跑在 Kubernetes 上,CloudNativePG operator 是目前最顺手的路径——它原生支持指定 PostgreSQL 版本镜像,一条声明就能拉起一个完整的 PG 集群,不需要手动拼 PVC、Conf...

PostgreSQL 补丁为什么没人审——以及你可以怎么做

来源: postgr.es 51
三月份,Lucas Draescher 向 PostgreSQL 提交了他的第一个补丁,修复了使用 时文件描述符泄漏的问题。补丁干净、动机明确,已经迭代到第三版。然后它在 commitfest 里静静躺了两个月——零评审。 这不是例外,这是常态。PostgreSQL 靠志愿者运转,核心提交者人数有限,补丁队列却很长。一个写得不错的补丁等上几个月没人看,...

MySQL 9.7 JSON Duality View:一次往返插入两张表

来源: jfg-mysql.blogspot.com 215
拆表是常见的优化手段——把一张宽表拆成两张窄表,减少冗余、提升查询效率。但拆表之后,原本一条 就能搞定的事,变成了需要事务包裹的两条 。从自动提交的单条写入,变成一个事务块,工作负载的形态变了,锁的持有时间也变了。 MySQL 9.7 的 JSON Duality View 给了另一种解法:对着视图做一条 ,数据库在内部把数据拆到两张表里,原子性由视图...

Uber 如何用 250ms 批量窗口让账本系统扛住每秒 30+ 次热账户更新

来源: infoq.com 91
金融账本系统有一个经典难题:某些"热账户"会被大量交易同时写入。一个高频乘客的账户在一秒内可能产生多笔扣款、退款、奖励入账,如果每笔交易都争抢同一行记录的锁,吞吐量很快就会塌方。Uber 在分布式账本基础设施中碰到了这个问题——原来多小时的批处理管道,他们用 250ms 批量窗口 + Redis 协调 + 乐观原子更新这套组合拳,压到了分钟级完成,单账...

MySQL 社区贡献机制正在升级:从提交代码到共建未来

来源: blogs.oracle.com 66
MySQL 的生命力从来不只来自 Oracle 的工程团队,更来自全球数以万计的开发者——写应用、跑生产库、提交补丁、造工具、补文档、答问题、提反馈。第四次 MySQL 公开讨论会(Public Discussion #4)聚焦的就是这件事:贡献流程正在改进,下一步怎么走,需要社区一起定方向。 过去向 MySQL 提贡献,最常被吐槽的是流程模糊、反馈周...

文件描述符耗尽:那个把 PostgreSQL 拉垮的内核限制

来源: postgr.es 83
大多数被归咎于"数据库挂了"的 PostgreSQL 宕机,真正的故障点在更底层——内核的文件描述符(file descriptor)用完了,PostgreSQL 只是第一个倒下的进程。这篇文章拆解整个故障链路:从连接数膨胀到 FD 耗尽,从日志特征到诊断命令,再到根治方案和临时止血手段。 Linux 内核把几乎所有 I/O 对象都抽象为文件描述符:T...

pgBackRest + pg_tde:加密数据库的备份还原实测

来源: postgr.es 52
Percona 之前发过一篇博客,说 pgBackRest 配合 pg_tde(透明数据加密扩展)时,异步归档不可用——原因是对加密的 WAL 段做归档会出问题。Stefan Fercot 在会议走廊里听到这个说法后觉得不对劲:pgBackRest 应该能透明处理加密 WAL。于是他亲手搭了一套环境跑了一遍,结论是:异步归档完全可用,之前说的限制并不成...

PostgreSQL 游标查询的隐藏代价:cursor_tuple_fraction 如何拖慢全量扫描

来源: postgr.es 57
在 PostgreSQL 里声明一个游标(cursor)然后逐行 fetch,看起来是再正常不过的操作。但很多人没意识到:一旦查询走游标路径,优化器会默认假设你只打算读取结果集的 10%,并据此选择"快速返回前几行"的执行计划。如果你实际上会把游标拉到底,这个假设会让整条查询跑得比普通 SELECT 还慢。 PostgreSQL 对普通 和游标查询的规...