- 博客(356)
- 收藏
- 关注
RSS订阅原创 论文精读|PolarDB-MP|2024 SIGMOD最佳工业论文
PolarDB-MP提出了一种新型多主云原生数据库架构，通过分离式共享内存和共享存储解决现有架构的扩展性问题。传统主从架构受限于主库吞吐，shared-nothing架构面临分布式事务开销，而现有共享存储多主方案存在冲突解决效率低的问题。PolarDB-MP的创新点包括：1) 所有节点平等访问数据，避免分布式事务；2) 基于RDMA的低延迟通信；3) 局部逻辑序列号(LLSN)确保一致性；4) 多主融合服务器(PMFS)实现事务/缓冲/锁融合。实验表明其在50%共享数据场景下，8节点可达7.8倍单节点吞吐。
2025-11-09 22:53:09
597
原创 案例-从distinct不准确到DISTINCT的计算原理
PostgreSQL统计信息中n_distinct值不准确的问题分析：大表默认采样3万行数据可能导致distinct值预估偏低。采样算法基于Haas-Stokes公式，其预估结果与采样中distinct值数量和单次出现值数量直接相关。测试显示，提高采样数量可改善准确性但增加分析时间。解决方案包括临时调整default_statistics_target参数或永久设置列级STATISTICS值（最大10000）。注意列的收集阈值优先级高于全局参数，且表阈值为各列最大阈值。
2025-10-19 10:38:16
414
原创 从静态表查询冲突到其原理
静态表查询冲突分析 摘要：在PostgreSQL主从架构中，静态历史表（无更新）的从库查询仍会遭遇"canceling statement due to conflict with recovery"错误。分析发现这是由于WAL日志中的HEAP2_CLEAN记录（对应页修剪操作）触发冲突所致。关键发现： 即使没有显式VACUUM操作，后台页修剪(PRUNE)也会生成WAL记录 这些记录包含remxid信息，会与从库查询的快照产生冲突 冲突发生在ResolveRecoveryConflic
2025-09-13 09:39:33
937
原创 案例-添加索引性能下降和generic plan
执行计划变化导致性能问题 问题现象：添加created_date索引后，SQL执行时间从3秒骤增至30多秒，导致CPU飙升。 执行计划对比： 加索引前：使用Nested Loop连接，通过task_no索引扫描各分区表，再过滤created_date条件 加索引后：改用Hash Join，直接利用created_date索引扫描所有分区表，导致扫描数据量剧增（rows=114435） 根本原因：优化器选择的新执行计划虽然利用了新增索引，但扫描数据量过大，反而导致性能下降。建议考虑调整查询条件或创建复合索引来
2025-09-13 09:35:15
963
原创 控制文件上的参数和主从参数不一致问题
8个参数在主库被修改并重启后，均会更新本地控制文件，如果参数有变会将改变后的参数写入wal中同步给下游，下游redo这个parameter change wal record，即更新本地的控制文件，从库根据一定条件来判断主从或者其他功能是否可用。
2025-07-29 10:05:09
1077
原创 案例-授权和walsender跑不动
PostgreSQL WALSender阻塞问题分析摘要 现象显示WALSender进程LSN未推进，CPU使用率高，堆栈显示阻塞在pathman插件的invalidate_psin_entries_using_relid函数。通过分析发现： WALSender在处理一个大型事务（XID=4285897514），该事务修改了约1.8万条pg_class记录 事务最后生成了大量无效消息（7万catcache和3万relcache） 这些修改主要涉及18523个系统表对象，占pg_class总记录的13% 问题
2025-06-21 10:39:56
896
原创 Linux内存进阶
进一步理解Linux内存，vm、cgroup如何运作和调配，如何监控内存pages的行为，postgresql在运维过程中会遇到什么OS内存问题···
2025-06-19 23:34:21
1076
原创 我的年终总结2024
我似乎每年都在说work-learning balance···由于今年工作量剧增，有段时间甚至都没办法学习了，balance已经被击碎。其实只要周围没人，学习效率就是高的。收集了一下今年我比较认可的话：不要让别人成为那你任务链上的依赖 --heisenberg.liu需要执行力的方案一般都是简单的方案 --heisenberg.liu没有落地的事情等于没有做 --somebody自己去想办法解决问题，而不是等别人回消息 --somebody。
2025-01-11 17:24:16
1615
原创 pg数据库运维经验2024
这篇文章主要是讲pg运维常见问题，两三年见一次的疑难杂症就不说了。主要是技术性运维总结，主打通俗易懂和快速上手，尽量避免源码层面等深入分析。
2025-01-08 21:14:28
1692
原创 PG停库逻辑和walsender阻止停库问题分析
有几种方法可以关闭pg库。在底层，它们都归结为向postmaster进程发送一个信号。signalpg_ctl含义SIGTERM不允许新的连接，但允许现有会话正常结束其工作。只有在所有会话终止后，它才会关闭SIGINT服务器不允许新的连接，并向所有现有的子进程发送SIGTERM，中止当前的事务并迅速退出。等待几乎所有子进程（有几个子进程不需要）退出，最后关闭SIGQUIT将向所有子进程发送SIGQUIT，并等待它们终止。如果在5秒内有子进程没有终止，它们将被发送SIGKILL注意，pg_ctl没有发送。
2025-01-04 13:11:45
1052
原创 读书笔记——DDIA-v2 设计数据密集型应用（第二版）
ddia-v2看完感觉爱不释手，只要是数据相关的知识都娓娓道来，为什么会这样？现在是怎样的？这样有什么问题？其中的看法和想法实在精辟、干练，甚至连每个章节的航海图都很有意思。
2024-09-19 23:14:09
2581
原创 Postgresql CLOG文件及其从库同步解析
放眼所有关系型数据库，PostgreSQL的clog也是很特殊的日志。CLOG的存在跟PG的MVCC机制不无关系
2024-09-03 20:38:47
1493
原创 PostgreSQL案例：planning time超长问题分析
库总是OOM，分析到是执行计划生成有问题，planning time 1秒，planning shared hit 100w。一通分析，定位到是统计信息基表pg_statistic膨胀，由于会话首次SQL执行时的CatCacheMiss，导致backend访问并缓存了pg_statistic过多的死元组数据。应用连接总会启用新会话，多个backend的总内存过大从而导致OOM。
2024-08-21 08:41:34
1603
1原创 案例：逻辑复制把checkpoint、walsender、backup全部卡死
pg数据库复制槽卡死、checkpoint卡死、备份卡死问题分析
2024-04-10 01:04:54
1369
原创 ORDER BY limit 10比ORDER BY limit 100更慢
pg数据库中执行sql时，ORDER BY limit 10比ORDER BY limit 100更慢，分析执行计划是如何选择的
2023-11-13 22:15:04
704
事务的历史与SSI-PostgreSQL数据库技术峰会成都站分享
2023-06-21
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人