居然这样用数据库! 你是友商派来的卧底吧?
digoal约 3 分钟文中参考文档在github需点击阅读原文打开, 同时推荐2个学习环境:
1、懒人Docker镜像, 已打包200+插件:《最好的PostgreSQL学习镜像》
插播广告1：2024年第13届PostgreSQL中国技术大会来啦！！！
插播广告2: 今天下午拉上兄弟和闺蜜来参加现场鞭策：
「杭州*康恩贝」4月26日PolarDB开源数据库沙龙，开启报名！
德哥邀你鞭策数据库第3期 - 老板知道吗? 你这样建只读实例也太浪费钱了
第一期视频回放地址: https://www.bilibili.com/video/BV1Rf4y1P7UU/
1、产品的问题点
每增加1个从库或只读实例就需要增加一份数据拷贝
复制时需要传输所有主库产生的WAL或逻辑增量日志
从库不支持逻辑复制(PG 16开始支持了)
不产生wal的行为不能复制到从库, 例如之前的版本hash index不产生wal, 从库无法使用hash index.
2、问题点背后涉及的技术原理
通过全量的数据文件拷贝+逻辑或物理的增量复制创建从库, 每一个从库都是一份完整的拷贝.
3、这个问题将影响哪些行业以及业务场景
读压力很大, 并且需要超过1个只读实例才能满足读请求诉求的业务. 例如偏重计算(业务逻辑放在数据库中)的业务. 基于推荐算法的短视频、社交、内容、电商等C端业务.
主库使用了主从HA架构后, 依旧有只读实例诉求的场景. 这个几乎是通用的, 所有业务都被命中.
4、会导致什么问题?
昂贵的只读实例, 不仅要计算资源, 还需要同样的存储资源.
每个只读实例都需要与主库建立连接复制增量WAL或逻辑日志, 需要消耗主库的网络和IO资源, 只能创建有限的只读实例个数.
只读实例可能恢复慢, 特别是mysql基于逻辑增量的架构, 事务结束后才能apply日志, 大事务对数据库延迟影响较大.
主库发生HA后, 如果新主库的日志量偏少, 只读库将无法成为新主库的从库, 需要重建, 导致新一轮的全量数据拷贝. 影响业务.
5、业务上应该如何避免这个坑
建立很多只读实例的客户, 成本问题无解
采用级联模式复制, 减少每个节点的下游节点个数.
逻辑复制慢的问题, 可以考虑PG的物理流复制, 延迟和事务大小无关
主库发生HA后如果只读库不能成为新主库的从库, 可以使用pg_rewind来避免需要拷贝全量数据.
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
级联模式增加了管理成本, 跳数增加, 延迟增加. 还有上游发生问题时, 整个级联下游全部受到影响.
物理流复制虽然延迟低, 但是apply可能与query本身产生冲突, 需要使用feedback来减少上游vacuum铲掉下游以来的tuple, 但是又会带来膨胀、vacuum无用功等增加cpu和io消耗的问题.
pg_rewind增加了管理成本. 普通用户不会用.
7、数据库未来产品迭代如何修复这个坑
Oracle RAC
PolarDB
欢迎关注我的github (https://github.com/digoal/blog) , 学习数据库不迷路.
近期正在写公开课材料, 未来将通过视频号推出, 欢迎关注视频号:
文章中的参考文档请点击阅读原文获得.