[数据库]——由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版本则实现了更多的功能，有待笔者进一步的深入研究。

后续

已成功加入polardb团队，和我想的居然有点不太一样，让我在好好研究几天更新文档，么么叽！