[数据库]——由POLARDB引发的思考
POLARDB
笔者实习期间在某公司做云计算开发,组内项目不成熟正巧赶上换底座的工作,要求实现进程宕机和节点宕机的高可用无感知切换。
凑巧分到了实现Mysql数据库高可用部分,实现过程中磕磕绊绊,但是关于数据库有了初步的架构认识。
今天“阿里爸爸”面试官老师打电话过来问是否有意向进行数据库内核开发工作,介绍后原来是早有耳闻的POLARDB,怀着好奇心研究了下POLARDB的架构,解开了我在搭建数据库高可用的许多疑惑
我是如何实现的
高可用其实是一个宏观的问题,所以先来看看总体的架构图
每次宕机后,前者都会按顺序拉起后者
systemd --> supervisor --> 所有无状态服务
那么这样的架构为什么就可以实现MySQL的高可用,其实分为两种情况:
- 情况一:MySQL进程死亡,那么supervisor就会定时的探测其状态,如果发现死亡则主动拉起
- 情况二:MySQL所在的物理机宕机,keepalived将故障的机器移出集群,备用节点上的nginx启动backup数据库代理
- 情况三:仅nginx宕机,keepalived可以写定时脚本检测所要保活的任务是否正常,如果不正常则自杀,所在MySQL物理机被移出集群
更细致的细节
我们的项目由于只搭载在俩台管控系统上,所以选择管控节点的主备方案:但是,我们的数据库方案其实并没选择一主一从方案
为什么数据库不选择一主一从
因为MySQL是靠nginx走的4层代理,如果数据库在一主一从的情况下主库发生宕机,数据将会开始在从库写入,如果不巧此时主库恢复,经过测试nginx又会重新代理主库,这样就造成了数据的不一致
我们选择了双主方案,发生相同情况时只要IO线程和SQL线程没有死亡,那么就算重新代理主库也能保证数据同步
双主模式是否会引起俩节点同时写入的情况?
可以看出当前模式下其实就算是双主配置,由于nginx同一时间只会代理一个节点的数据库,所以不会发生俩个节点同时写入的情况
但!!也不完全一定,如果用户将主备节点错误配置到了俩个网络分区,此时就发生了keepalived脑裂,他们认为他们之间互相死亡,所以会对俩个数据库同时写入
双主架构如何实现
笔者有了解过galera集群方式、MHA三节点方式,但是都不如俩个数据库互为主从模式简单
最初,我们使用了MySQL 5.6版本更高级的GTID技术,完全基于事务,不用在发生错误时去手动连接pos点,但最后却犯了致命的错误放弃了
并不是GTID不可用,而是这个技术限制不可以事务中创建大量的临时表,但是java的hibernate必须创建临时表,最终导致只能选择普通的主从复制方式。
存在的问题
虽说项目上线后,程序经过测试确实实现了高可用,而且比预期好很多,但是还是发现了下面的问题
- 管控扩容的问题:当前架构只适合主备模式,后期如果需要加入更多的数据库该如何扩容
- 达不到无感知切换程度:当nginx需要切换backup进行代理时,需要一定的时间来进行切换
- 异步复制延迟大:当出现重大事故需要全量数据恢复时,主从复制延迟缺陷就体现了出来
- 冷数据脏数据无法清理:由于之前开发的错误,导致数据库中有大量的冷数据和脏数据
POLARDB如何解决我的问题
ps:图片来自POLARDB v2.0新闻发布会
从架构上来看,我的nginx反向代理就像是POLARDB的PolarProxy,也是只向用户暴露唯一访问地址
第二层的数据库引擎可以类比为我的数据库节点
第三层也是让我觉得设计非常惊艳的一层,普通数据库其实计算存储是一体的,但POLARDB则使用了共享存储,这就以为者解决了我所遇到的最大问题
- 达不到无感知切换程度:POLARDB采用共享存储,主从切换可以做到秒级
- 异步复制延迟大:POLARDB采用共享存储架构,主从切换不需要数据重构
而数据库节点无法扩容的问题也得到了良好的解决:
- 管控扩容的问题:POLARDB的计算节点可以分钟级扩容,任何时刻发现业务量突变即可快速扩容
冷数据的问题也在2.0版本的OSS存储得到解决(但发布会并未透露如何解决的),也整理了POLARDB其他的优点
POLARDB的特点
1、升级硬件需要迁移数据,升级周期长,无法从容应对突如其来的业务高峰。
(POLARDB的计算节点可以分钟级扩容,任何时刻发现业务量突变即可快速扩容。)
2、金融级可靠性要求RPO=0,传统架构使用实例层同步多副本,性能损耗巨大。
(POLARDB的存储为多副本,底层使用RDMA、Parallel Raft、3D Xpoint等最新的软硬件技术,性能比传统架构最高提升6倍。)
3、实例层复制HA架构,主从切换时间长,无法满足金融级连续性要求。
(POLARDB采用共享存储,主从切换可以做到秒级,同时在计算与业务层之间有一层代理层,代理层可以帮助用户识别计算节点的异常,自动切换,在大多数时候业务感知不到计算节点的切换,保证了业务连续性。)
4、传统HA架构采用主从异步复制,切换后从库可能需要重建,耗费资源多,重建时间长,存在长时间单点故障。
(POLARDB采用共享存储架构,主从切换不需要数据重构。)
5、每个只读节点都需要一份与主完全一样的副本,成本高。
(POLARDB采用共享存储架构,增加计算节点,不需要增加存储副本数,使得整体成本相比传统架构低很多。)
6、读写分离采用逻辑REDO复制,主从延迟高。
(POLARDB的数据存储为共享存储,不需要同步REDO数据,只需要同步REDO的位点,主从延迟在毫秒级。)
7、sharding架构没有想象的好,功能阉割、对业务有巨大侵入(限制SQL较多)。
(POLARDB完全兼容MYSQL,对业务没有任何侵入,用户不需要修改一行代码即可使用POLARDB。)
8、TB以上实例备份慢,往往数十小时。
(POLARDB使用快照备份技术,无论数据量多大,秒级备份)
POLARDB 2.0版本则实现了更多的功能,有待笔者进一步的深入研究。