【DB吐槽大会】第42期 - PG 读写分离不友好

背景

1、产品的问题点

• PostgreSQL 读写分离非常不友好, 没有内置的对业务完全透明的读写分离功能.

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

• 为什么要读写分离?

• 读请求占比较高, 并且单个实例无法支撑业务的请求吞吐时, 通过增加只读实例, 将读请求分流到只读实例以满足业务需求.

• 什么是业务透明的读写分离?

• 应用发起SQL, 数据库根据SQL是否会对数据库产生写操作自动分发到主库或只读库.

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

• 读占比和吞吐较大的业务
• 读请求相对来说比较复杂, 需要耗费较大IO和CPU计算, 怕影响主实例(RW实例)的业务

4、会导致什么问题?

• 没有读写分离功能, 业务必须连接多个数据源, 在代码中自己判断, 将读、写请求发送到不同的数据源. 增加了程序设计复杂度.
• 而且只读和读写节点可能发生角色切换, 代码里面不仅要判断SQL是否要路由到RO, 还要判断当前数据源到底是RO还是RW角色.

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

• 使用 pgpool-II 中间件

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

• 通过pgpool-II连接数据库, 性能存在巨大的损耗

• 多一跳延迟增加、
• pgpool-II自身的损耗
• 高并发小事务损耗50%以上 (tpc-b测试样例)

• 功能不完备, 例如:

• 函数内的query不能再路由
• 自定义函数需要配置黑白名单, 否则统一路由到rw节点. (函数白名单、黑名单需要手工维护)

• 增加了1个组件增加了1份故障点
• 增加了配置复杂度, 例如

• 心跳检测配置
• 从库与主库延迟多少后自动踢出只读实例列表
• 恢复后是否自动加入只读实例列表
• 连接池个数, 空闲自动释放时间, 生命周期等

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

• 希望内核层面支持对业务透明的自动读写分离

• 不管是rw还是ro节点, 平等对待所有连接. 应用可以使用驱动来load balance连接
• 从库与主库延迟自动踢出只读实例列表, 恢复后是否自动加入只读实例列表
• 解析SQL, 生成执行计划, 自动路由plan execute
• 根据SQL的代价来决定是否要将sql分发给只读实例. 用户可以设置代价阈值.
• 不依赖外部产品