MySQL久经沙场,各种架构,各种生态组件,各种业务各种用法千奇百怪。今天盘点一下常用的高可用架构都有哪些,以及国产兼容MySQL产品的架构有那些变革。

     1、主备复制架构:在数据多副本备份场景下,传统的主从复制架构中,一般从库作为主库数据的备份,执行异步或者半同步复制,当主库发生故障时,临时启用备库数据,对外提供服务。但这存在一个问题,就是主库和从库因异步复制,或网络延迟引起的数据差异,往往需要DBA人为介入判断考虑是否启用备库对外,并且主库故障后手动进行回切补数据的过程也较为繁琐。主从复制架构可以是延迟备库,可以是做数据副本备份使用,也可以对业务提供读写分离,主库只写,备库只读。但是如果想在主备库都可读写,且相互同步,则衍生出双主复制。

2、双主互为主从架构:也叫双主复制,这种方式和主从一样,一般都是异步同步binlog进行逻辑回放,可以达到主备可读可写。但随着业务对连续性的服务要求提升,希望其支持主从故障切换,且切换时,不需要业务层变更接入的IP和端口信息,这就可以考虑在双主复制上边加一层虚拟IP,即VIP。常用的方式是结合 keepalived 使用VIP 对外提供服务,一旦主库发生故障,备库可以在很短的时间内接管服务。但现实投产环境,仍然是写一个节点,另一个节点作为backup,不会同时2个都写,否则可能需要处理好auto_increment自增主键的步长,避免两边主键冲突导致的复制中断问题。

3、keepalived+双主复制架构:需要单独下载和配置keepalived的.conf,同时数据库主备两边需要编写数据库状态的循环检测脚本,以及故障发生时,处理故障的逻辑。一般情况下业务层接入的是keepalived层虚拟出来的vip地址,可以做到一次的故障切换,大多切换之后,需要用户处理原始故障节点的MySQL实例。

4、MGR 组复制:组复制相较于主从复制,对mysql实例的节点数有了最低的要求,要求>=3个,内部采用paxos多数派协议进行事务验证。MGR支持单主模式和多主模式,一般投产环境下MGR多用单主模式,即1个primary,2个secondary,且故障切换时可以设置节点的权重切换优先级,做到自动故障切换,业务层一般只接primary节点,故障切换之后,业务层需要更换新主节点的IP地址。多主模式下各节点均为primary,可以多读多写,只不过事务冲突和锁等待问题较多,性能表现并不是很好,用的相对较少。但是相较于主备复制,多了一些限制条件,比如GTID,binlog行格式,表要求有主键,以及不支持外键约束等,使用时业务层如果有业务表无主键或者有外键关联的需要处理下才能用。

5、Innodb Cluster集群:基于MGR的基础之后,增加了mysqlrouter的路由层和mysqlshell的接口管理client。多了一层中间件,这样后端mgr发生主从切换时,业务层就不用更换数据库的ip地址了。mysql router采用读port和写port 2个端口来支持读写分离,但实际用sysbench和benchmarksql压测,加了mysqlrouter的MGR,和单纯的3节点的MGR高并发下性能耗损对比超过50%,TPS/QPS波动幅度较大,波峰波谷的范围>80%。不过mysqlshell的管理工具在配置mgr,以及做数据库升级时的检测功能,个人用起来觉得太赞了。支持java、sql、python,且内置java定义好的程序,很方便,比如做primary 和secondary切换,单主模式和多主切换等操作时。

6、MMM,MHA这两种可能时间相对久远一些,多是5.7版本使用较多的,个人仅仅接触过MHA,其他的没用过,不好多说。不过高可用切换基本上每自动切换一次,DBA就要出一次故障报告,以及恢复实例步骤说明。而且是一次性的切,个人角度觉得上边集中架构里,MGR应该是相对最友好的。基本上对DBA来说,故障切换之后的"后事"处理少一些。

7、基于mycat、dble的高可用:这个基本上带有一些分库分表业务属性的,赋能中间件的高可用,目前在国产分布式数据库中,特别是基于中间件形成的存算分离的分布式,把中间件层的能力做到了MySQL的 server层的能力,对SQL语法,分片,执行计划,基于RBO的优化改进等等发挥到了极致。这里不多说了,总之还是基于主从复制和组复制这两种底座上建立起来的,加之国产数据库把原始DB的概念和内嵌,插接plugin,外部组件等分类边界现在搞的说辞已经逐步模糊化了,不知道一个数据库产品,到底卖的的时纯DB,还是组件了。如果卖DB估计是考虑到gpl 开源协议的风险问题,然后规避一下?个人猜测而已。

变革在哪里,创新在哪里,优化改进在哪里?

关于目前兼容MySQL的国产数据库产品,在上述架构上有那些变革,我看到了一种比较新颖的架构,万里数据库下边的开源社区,搞的VIP plug+MGR。

创新点1:

将vip模块以plugin形式,打包到数据库中。用户可按需启用vip,且vip还分为读vip,和写vip。自己看: https://greatsql.cn/docs/8.0.32-25/5-enhance/5-2-ha-mgr-vip.html,我觉得很有意思,而且对业务,对DBA来说是个备选参考。

MySQL做业务读写vip,一定要用开源组件吗_mysql

创新点2:

另外基于MGR复制,除了primary,secondary角色节点之外,额外开发增加了一种角色Arbitrator仲裁节点,或者投票节点,只在高可用切换时做多数派选举使用。 https://greatsql.cn/docs/8.0.32-25/5-enhance/5-2-ha-mgr-arbitrator.html

改进点3:

load data 这个导入csv,或者txt,或者从Oracle,以及sqlserver,postgresql过来的文本数据,MySQL导入这个功能在很久以前就支持,不过单线程,放到单个事务加载,加载速度这个令人着急。greatsql、greatdb这俩支持并行导入,支持文件切分,按切分的chunk导入,这个倒是把mysql的单线程,无法并发,事务过大超过binlog大小的问题解决了。感觉很赞。

plugin_load_add=greatdb_ha.so
  • 1.