背景
1、产品的问题点
- 每增加1个从库或只读实例就需要增加一份数据拷贝
- 复制时需要传输所有主库产生的WAL或逻辑增量日志
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、数据库未来产品迭代如何修复这个坑