性能评测 | GreatDB VIP PLUGIN方案 VS MySQL InnoDB Cluster高可用方案

前言

最近，我们与许多数据库用户进行了沟通和调研，了解到，目前仍有相当一部分投产的MySQL高可用或故障转移方案，用到了读写分离功能或业务接入VIP（Virtual IP Address）的方式，来屏蔽后端数据库架构。

MySQL中，VIP机制一般借助于2个组件，即结合HaProxy和Keepalived两个软件完成。

HaProxy是一款高性能的负载均衡器，支持TCP/HTTP流量的代理和转发。Keepalived是一个开源软件，它实现了虚拟IP地址的分配和故障转移，而且支持主备模式，能确保高可用性，许多生成环境都采用此方式作为数据库故障切换的高可用方案之一。

随着国产化发展进程加速，一批优秀的国产数据库高可用方案也随之应运而生，万里数据库的核心产品安全数据库GreatDB ，以内置VIP plugin的形式对外提供读写分离和故障转移功能。

安全数据库GreatDB结合客户的众多部署和投产实践，将上述HaProxy+Keepalived 2个软件的能力，结合组复制的paxos协议选主切换机制，以数据库可插拔的plugin形式，内置集成了VIP插件。

用户可通过install plugin greatdb_ha soname 'greatdb_ha.so';实现快速、灵活、便捷的方式对外提供VIP，屏蔽后端数据库的架构复杂性。

另一方面，2017年，MySQL推出MySQL InnoDB Cluster（简称：MIC）高可用架构，在MySQL8.0发版后不断更新迭代，通过轻量化的mysql-router路由组件及mysql-shell管理工具，搭配MySQL的Group Replicaton组复制，形成了配套的高可用方案架构，以此来提供读写分离和自动故障转移能力。

今天，我们就来横向对比一下2种方案在各自性能上的表现，以及适用场景和优缺点。

01/两种高可用架构介绍

1、MySQL Innodb Cluster架构

MySQL Innodb Cluster（简称为MIC）是基于MySQL的group_replication组复制插件，提供自动成员资格管理、容错、自动故障转移等功能。

在MGR组复制基础上扩展了2个组件工具，即mysql-shell和mysql-router。

其中，mysql-shell拓展了整个高可用架构的管理能力，通过mysql-shell的AdminAPI 在 SQL、JavaScript 、Python语言之间快速切换，非常适合脚本编写和自动化部署 MySQL的高可用复制，增加了数据库实例扩展的灵活性。通过使用MySQL Shell的AdminAPI，改进了原始手动配置多个实例之间的存量数据同步，以及节点配置的检查、用户创建、权限分配、插件加载等诸多配置环节。

mysql-router则是提供对业务透明的故障转移及读写分离能力。官方将其定位为轻量级的路由插件，运行在MGR内部，结合mysql-shell创建的mysql_innodb_cluster_metadata库，mysql-router通过获取集群元数据，自动识别MGR内部的primary和secondary节点，通过默认6446 读写、6447只读端口来提供读写分离支持。

（图片来源：MySQL开源社区8.0产品文档）

架构描述：

MGR 组复制支持单主模式和多主模式，一般MIC使用场景多使用单主模式，即分区primary 主节点和secondary备节点（从属节点），本文主要针对单主模式下组复制性能的测试对比。

2、万里数据库GreatDB Paxos架构

GreatDB VIP Plugin通过虚拟IP地址提供对复制组的访问（单主模式）。

启用插件时，VIP默认绑定组复制中的primary节点网卡。当primary节点手动或自动切换时，VIP随之漂移到其他GreatDB实例上，以保证业务的持续读写能力，从而实现透明的故障转移，并做到性能上接近0损耗的高性能访问，技术上实现高效易用的目标。

（图片来源：GreatDB官方产品架构图简化）

架构描述：

业务侧只需关心对外暴露的VIP地址和原始的组复制PORT，无需关系谁是primary主节点，VIP会自动判断组复制中group_replication_group_seeds对应IP所在的网卡，绑定网卡子口，如网卡为eth0:0 192.168.1.100/24。

同时支持跨网段，前提是VIP和IP路由转发正常(都在网络白名单或有相同网关地址）。

02/测试环境和测试方法

1、测试对象

1）MySQL官方MySQL Innodb Cluster架构

2）万里数据库GreatDB Paxos+VIP 高可用架构

通过sysbench分别压测原生私有交付的组复制架构和增加组件mysql-router、启用VIP插件的情况下，对比两种高可用架构差异带来的性能影响和变化。

使用软件版本：

1、MySQL8.0.32

2、万里数据库GreatDB最新版本

3、压测工具sysbench-master 1.1.0

2、测试方法介绍

• 压测工具：sysbench

• 压测环境：50张table，每张表100w行数据，压测时长不低于5分钟，分别测试16、32、64成倍数增加的性能变化差异。每个并发测试完成后均清理压测数据，重启数据库、清理缓存，重新初始化数据后，执行下一轮并发压测。参数配置：my.cnf

• 数据库：3节点组复制方案

• 主备模式：单主模式

• 数据一致性：均设置为最终一致性

sysbench  oltp_read_write.lua  --mysql-user=$username --mysql-password=$pwd --mysql-host=$host  --mysql-port=$port --mysql-db=sysbench --threads=16/32/64  --report-interval=1 --tables=50 --table-size=100000  --time=300  run

主机环境：

测试主机采用3台16c 16g 200g 的KVM主机，操作系统均为CentOS 8.5 。安装部署使用GreatADM数据库管理平台，统一图形化安装MySQL8.0.32、GreatDB 最新版本组复制架构。

针对MIC的2个插件mysql-router和mysql-shell在GreatADM配置好的组复制基础上，手动配置mysql-router并初始化，启动插件，mysql-router做辅助MGR命令管理。

03/GreatADM 安装部署Paxos（mgr）高可用架构

1、部署2套数据库

此处请参考GreatSQL社区往期分享【探索MGR图形化部署】，点击查看文章原文。

2、配置MySQL InnoDB Cluster组件mysql-router

1）MySQL InnoDB Cluster启用mysql-router插件

首先

使用mysql-shell（解压之后可直接到mysql-shell/bin下调用mysqlsh)，为已经配置好的MGR创建一个集群名字，如下：

[root@gip bin]# cd /root/mysql-shell/bin;./mysqlsh  -ugreatdb -p'!QAZ2wsx' -P3311 -h172.17.138.161 MySQL  172.17.138.161:3311 ssl  JS >  MySQL  172.17.138.161:3311 ssl  JS > dba.createCluster('mycluster') MySQL  172.17.138.161:3311 ssl  JS > dba.getCluster();<Cluster:mycluster> MySQL  172.17.138.161:3311 ssl  JS > \sqlSwitching to SQL mode... Commands end with ; MySQL  172.17.138.161:3311 ssl  SQL > show databases;+-------------------------------+Database                      |+-------------------------------+information_schema            |mysql                         |mysql_innodb_cluster_metadata |performance_schema            |sys                           |sysbench                      |+-------------------------------+ MySQL  172.17.138.161:3311 ssl  JS > \qBye!

其次

开始初始化mysql-router，采用最直接的bootstrap方式引导，会自动生成mysqlrouter的目录和conf配置文件，如下。

本次在mgr的primary主节点配置1个mysql-router即可：

[root@gip mysql-router]# cd /root/mysql-router/bin;./mysqlrouter --bootstrap greatdb@localhost:3311 --directory /root/mysqlrouter --conf-use-sockets --user=root --conf-bind-address=172.17.138.161 --forcePlease enter MySQL password for greatdb: Bootstrapping MySQL Router instance at '/root/mysqlrouter'...Creating account(s) (only those that are needed, if any)Verifying account (using it to run SQL queries that would be run by Router)Storing account in keyringAdjusting permissions of generated filesCreating configuration /root/mysqlrouter/mysqlrouter.confMySQL Router configured for the InnoDB Cluster 'mycluster'After this MySQL Router has been started with the generated configuration    $ ./mysqlrouter -c /root/mysqlrouter/mysqlrouter.confInnoDB Cluster 'mycluster' can be reached by connecting to:MySQL Classic protocolRead/Write Connections: localhost:6446, /root/mysqlrouter/mysql.sock  #router的读写端口Read/Only Connections:  localhost:6447, /root/mysqlrouter/mysqlro.sock #router的只读端口MySQL X protocolRead/Write Connections: localhost:6448, /root/mysqlrouter/mysqlx.sockRead/Only Connections:  localhost:6449, /root/mysqlrouter/mysqlxro.sock

最后

启动mysql-router即可

[root@gip bin]# [root@gip mysqlrouter]# pwd/root/mysqlrouter[root@gip mysqlrouter]# lsdata  log  mysqlrouter.conf  mysqlrouter.key  run  start.sh  stop.sh[root@gip mysqlrouter]# sh start.sh [root@gip mysqlrouter]# PID 307283 written to '/root/mysqlrouter/mysqlrouter.pid'stopping to log to the console. Continuing to log to filelog[root@gip mysqlrouter]# mysql -ugreatdb -p'!QAZ2wsx' -h172.17.138.161 -P6446   #测试通过6446连接MGR

3、GreatDB 启用VIP PLUGIN 配置VIP

通过拓扑界面选择【配置数据库VIP】

填写【VIP地址配置】--【预检查】，检查对应的VIP是否被占用，以及对应配置vip所需要的操作系统权限和运行使用的lib库正常加载。

【提交】之后，数据库会在my.cnf配置文件中添加greatdb_ha.so 插件，完成VIP的参数变量加载。此阶段需要重启数据库实例，请勿在业务高峰或有业务运行时配置VIP，否则可能导致业务中断。

重启完成之后，拓扑结构如下：

【登录数据库】：查看数据库实例的VIP变量配置信息，3个数据库实例配置相同，自动识别要绑定的网卡名称。

通过GreatADM图形化界面配置，相对简单高效，屏蔽了参数配置和lib加载的复杂性。

04/执行对比测试

1、MySQL MGR启用和不启用mysql-router性能耗损测试

数据库版本：MySQL Community Server 8.0.32

mysql-shell：ver 8.0.34 for Linux on x86_64

mysql-router: ver 8.0.34 for Linux on x86_64

压测命令：

sysbench  oltp_read_write.lua  \ #使用 oltp_read_write.lua  混合读写脚本--mysql-user=username \ --mysql-password='pwd' \--mysql-host=172.17.138.161 \ --mysql-port=3311  \   #MGR端口3311 ，MIC mysql-router为6446  --mysql-db=sysbench \--threads=64 \    #分别测试16、32、64并发--report-interval=1 \--tables=50 \     --table-size=100000  \--time=300   run

测试结果：

性能曲线对比：

结论：实际MGR单主模式下，通过mysql-router压测，在16、32、64 并发下，性能相对于直接压测primary节点分别下降了-14.2%、-24.7%、-17.3%，3个并发3次的平均性能损耗在18.7%。

2、GreatDB 启用和未启用VIP Plugin性能耗损测试

数据库版本：Server version:8.0.32-23-GreatDB最新版本

压测命令：

sysbench  oltp_read_write.lua  \ #使用 oltp_read_write.lua  混合读写脚本--mysql-user=username \ --mysql-password='pwd' \--mysql-host=172.17.138.161 \   #vip地址 172.17.138.100 --mysql-port=3322  \   #数据库访问端口3322，vip和物理ip访问相同端口  --mysql-db=sysbench \--threads=64 \    #分别测试16、32、64并发--report-interval=1 \--tables=50 \     --table-size=100000  \--time=300   run

测试结果：

性能曲线对比：

结论：实际GreatDB paxos架构，单主模式下，相对于通过内置VIP plugin配置的VIP压测，直接压测primary节点的性能在16、32、64 并发下分别下降-2%、+0.9%、-1.4%，3个并发下3次性能耗损平均为0.83%。

05/综合对比

结果横向对比：通过对比GreatDB最新版本和原始社区MySQL8.0.32版本，在相同的3台配置主机上，使用相同my.cnf参数情况下，使用50张10w行表数据分别进行16、32、64并发的读写压力测试，GreatDB的paxos优化改进方案较原生MySQL MGR的性能分别提升12.6%、18.4%、26.8%，3个并发3次测试，平均性能提升19.3%左右。

结果横向对比：GreatDB最新版本提供企业版本的VIP故障转移能力，相较于MySQL Innodb Cluster在16、32、64并发下，性能提升分别为26.1%、49%、46.7%，3个并发3次测试，平均性能提升约40.6%。

06/总结

根据以上对比分析，我们了解到两者在组复制方案性能上的差异。

2个方案均基于group_replication组复制插件，建立多个数据副本，通过paxos协议实现高可用的选主和故障切换。

虽然mysql-router定位尽可能简单、轻量化，但增加mysql-router的路由转发后，基于端口的读写路由和基于权重轮询的负载均衡，在性能上表现不尽人意。

而GreatDB 采用集成的greatdb_ha.so插件化支持，通过内置plugin方式，实现故障切换对外无感知，配置简单，且性能消耗相对于mysql-router来说，TPS性能提升近40%，并且可以灵活地install plugin和uninstall plugin，做到了真正的高效易用。

GreatDB Paxos+VIP 高可用架构方案特点

1、兼容性更强

GreatDB 数据库内置集成plugin，不需要额外组件，数据库自身插件兼容性更强；

2、架构稳定性更好

结合GreatDB对group_replication的网络层优化，事务认证流控代码层改进，架构稳定性更好；

3、性能提升

GreatDB针对优化器的开发增强，支持基于cost的并行查询等能力，相比社区版本MGR，性能提升19.3%左右；

4、提高运维效率

可维护性方面，GreatDB开发支持的AWR自动负载信息库、ASH活跃会话历史分析报告，让用户在运行维护方面可追踪性能的变化趋势，增强问题定位和排查的效率。

GreatDB Paxos+VIP 方案适用场景

1、可用于原始基于MySQL5.7的双主+keepalived或搭配Haproxy等方案架构，故障切换次数和故障恢复代价高的升级替换场景；

2、可用于借助官方MySQL InnoDB Cluster架构，受性能和业务稳定性困扰的场景，此类场景可考虑升级为GreatDB Paxos+VIP方案；