查看原文
其他

别搞HA,别搞HA,别搞HA!

digoal PostgreSQL码农集散地
2024-09-30

文中参考文档可点击阅读原文打开, 推荐《最好的PostgreSQL学习镜像》。本公众号持续发布AI、PostgreSQL、DuckDB、观察感悟等相关文章. 


没有HA如何做到0丢失?瞬间崩溃恢复?

0丢失很简单,不需要高端存储云盘的多副本技术随便就可以做到,还需要啥HA?实在很重要的数据搞个跨机房或者跨地域容灾防天灾。

最快的崩溃恢复技术却不简单,能做到任何时候崩溃恢复无需等待,有这样的技术吗?沃特?还真做到了!一定要看完本文。

这也是我推荐云上使用的数据库别搞HA,因为数据库流复制那种HA,弊端太多:成本翻一倍,异步的切来切去丢数据\脑裂,同步的性能损耗大\故障点增加\成本翻几倍,功能损失让人抓狂(逻辑槽支持不好,啥都要写wal等),版本管理插件管理配置管理更加复杂坑更多等等,毛病实在太多。老司机都难免翻车。

其实你搞那么多事情\搞主从HA不就是要解决0丢失和快速崩溃恢复吗?咱直奔主题,别搞错了,HA不是目的,它只是手段  !

1、产品的问题点

  • PG 崩溃恢复能快点吗

2、问题点背后涉及的技术原理

  • 数据库进程被KILL -9、OOM、数据库强制非正常停库、或者操作系统、存储或其他故障导致数据库非正常停库时, 数据库再次启动需要进行恢复.
  • 恢复需要用到从上一个完成的检查点的逻辑开始位点处的WAL日志 - 到最新的WAL日志文件之间的所有WAL文件.
    • 需要多少个wal文件取决于检查点的长短, 通常内存很大的机器, 会设置较大的shared buffer, 同时设置较长的checkpoint周期来优化数据库写性能.
  • 恢复过程中被恢复的数据块包含full page时, 只需要从wal拿对应full page+wal增量record进行恢复, 但是恢复过程中数据块可能从shared buffer挤出, 那么就需要从datafile读取对应块然后+wal record恢复.
    • 这可能是非常耗费IO的操作. shared buffer较小时block被反复挤出和读入, IO消耗更加明显.

3、这个问题将影响哪些行业以及业务场景

  • 所有行业, 特别是规格大的实例

4、会导致什么问题?

  • IO如果较差的话, 崩溃恢复速度慢.
  • 特别是在业务高峰期 + 检查点长 + IO延迟高, 如果系统出现OOM的话, 崩溃恢复时间长对业务造成的影响巨大

5、业务上应该如何避免这个坑

  • 使用standby, 如主库崩溃, 激活从库.
  • 不管是数据文件还是wal文件都使用性能好(IOPS高、带宽吞吐大、单次IO RT低)的SSD
  • 缩短checkpoint周期, 让一个周期内的wal文件尽量的少

6、业务上避免这个坑牺牲了什么, 会引入什么新的问题

  • 使用HA架构会增加风险和复杂度, 例如双节点的异步HA, 可能丢数据风险. 三节点的同步HA, 成本高, 复杂度高.
  • 使用性能很好的SSD(IOPS高、带宽吞吐大、单次IO RT低), 增加了成本
  • 提高checkpoint频率, 会损耗写性能. 并且会导致full page write增加, 使得产生更多的wal文件, 甚至导致standby的延迟增加
    • 《PolarDB 为什么要解决FPW的性能问题?》
    • 《DB吐槽大会,第11期 - FPW | Double Write》

7、数据库未来产品迭代如何修复这个坑

  • 希望内核层面支持更友好的恢复功能
    • polardb pg共享存储版本支持lazy恢复模式, 几乎可以毫秒级恢复. 原理参考: 《一起学PolarDB - 第7期 - 为什么数据库越大崩溃恢复越慢?》
    • https://github.com/alibaba/PolarDB-for-PostgreSQL
    • 并行的恢复, 提高恢复速度. 目前PolarDB支持并行wal回放
    • 例如可以支持立即开放只读功能, 恢复过程允许只读操作,自动过滤不一致数据块,或自动使用旧的快照, 又或者读到该数据块时再进行恢复(PolarDB)

如果你对PolarDB感兴趣, 可以阅读:

  • 《2024-开源PolarDB|PostgreSQL 应用开发者&DBA 公开课》
  • 《《一起学PolarDB》系列》


往期吐槽文章:
欢迎大家留言或联系我把踩过的坑发过来, 一起鞭策开源和国产数据库: 
德哥邀你鞭策数据库第1期 - PG MVCC
Tom Lane老师, 求求你别挤牙膏了, 先解决xid回卷的问题吧
3 为什么增加只读实例不能提高单条SQL的执行速度?
4 德哥邀你鞭策数据库第4期-逻辑日志居然只有全局开关
第5期吐槽:经常OOM?吃内存元凶找到了:元数据缓存居然不能共享
第6期吐槽:2024了还没用上DIO,不浪费内存才怪呢!
7 第7期吐槽:今年才等来slot failover,附上海DBA招聘信息
8 第8期吐槽:高并发短连接性能怎么这么差?
9 第9期鞭策:“最先进”的开源数据库上万连接就扛不动了,怪研发咯?
10 第10期吐槽:说删库跑路的都是骗子,千万别信,他们有的宝贝你可能没有!
11 第11期吐槽:关闭FPW来提升性能,你想过后果吗! 本期彩蛋-老板提出变态的要求,你会答应吗?
12 第12期吐槽:SQL执行计划不对?能好就见鬼了!优化器还在用几十年前的参数模板,环境自适应能力几乎为零
13 第13期吐槽:十个中年人有九个发福的,数据库用久了也会变胖!这一期吐槽PG膨胀收缩之痛,tom lane啊您为啥不根治膨胀呢?
14 吐槽(鞭策)PG以来我掉了“一半流量”!老外听不得忠言逆耳吗? (本期抽奖-掌上游戏机)
15 第15期吐槽:没有全局临时表,除了难受还有哪些潜在危害?
16 空缺,因为这一期的吐槽PG社区已经落实了.
17 第17期吐槽:被DDL坑过的人不计其数!严重时引起雪崩,危害仅次于删库跑路!PG官方不支持online DDL确实后患无穷
18 第18期吐槽:都走索引了为什么还要回表访问?原来是索引里缺少了“灵魂”
19 第19期吐槽:从DuckDB导入到PG后膨胀了5倍,把存储销售乐坏了!什么情况?
20 第20期吐槽:PG17新版本这么香,为什么不升级呢?居然是因为这个
21 第21期吐槽:90%的性能抖动是缺少这个功能造成的!也是DBA害怕开发去线上跑SQL的魔咒
22 第22期吐槽:DB容灾节点延迟了,网络带宽瓶颈?用CPU换啊!该“魔法”PG还不支持!
25 第25期吐槽:PG的物理Standby无法Partial导致单元化架构/SaaS使用不灵活
99 第99期吐槽:SQL hang住锁阻塞性能暴跌!抓不到捣蛋SQL的DBA很尴尬。
26 第26期吐槽:开发者使用PG的第1件事-配置访问控制策略,体验有待加强
27 第27期吐槽:block size既大又小!谁把成年人惯成这样的?
28 想撼动Oracle,PG系国产你还不配!吐槽你连最基本的空间分配都没做好
29 吐槽PG表空间搞得跟"玩具"一样,全靠ZFS来凑
30 快改密码!你的PG密码可能已经泄露了
31 注意别踩坑!PG大表又发现一处隐患
100 直播+吐槽: 看看你的PG有没有被注水? 聊聊孤儿文件
32 第32期吐槽: PG大表激怒架构师,分区后居然不能创建唯一约束?
33 有奖谜题:PG里100%会爆的定时炸弹是什么?34 第34期吐槽:PG做SaaS/DBaaS?隔墙有耳。(本期彩蛋PG岗位招聘)35 "富人"的烦恼36 PG商业上失败的重要原因之一38 猪怕过年,DBA怕什么?

39 连老司机都不敢随便刷新PG的物化视图

40 老板问你数据库在“瞎忙”还是“真忙”?怎么回答?

41 第41期吐槽:无法预测大查询剩余执行时间
42 第42期吐槽:PG 读写分离不友好


本期彩蛋 - 开源Clup: PostgreSQL&PolarDB集群管理软件

clup由《PostgreSQL从小工到专家》作者唐成乘数科技出品, 包含开源版本和企业版本, 是非常成熟的PostgreSQL&PolarDB集群管理软件. 

官网: https://www.csudata.com/clup

开源项目地址: https://gitee.com/csudata

使用CLup可以轻松管理几十套至上百套PostgreSQL、PolarDB高可用的数据库集群,发生故障自动切换,不影响生产系统的运行。故障切换后有详细的故障日志,方便定位故障原因,还可以手工一键切换。CLup还提供了数据库的一些基本监控和TOP SQL的监控,CLup后续版本还会增加更多的功能。

  • 管理基于PostgreSQL流复制的集群

  • 管理基于共享存储的PolarDB集群

  • 产品优势

推荐2本新书:

文章中的参考文档请点击阅读原文获得. 


欢迎关注我的github (https://github.com/digoal/blog) , 及视频号:


个人观点,仅供参考
继续滑动看下一个
PostgreSQL码农集散地
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存