性能评测 | 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 > \sql

Switching 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 > \q

Bye!

其次

开始初始化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 --force

Please 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 keyring

Adjusting permissions of generated files

Creating configuration /root/mysqlrouter/mysqlrouter.conf

MySQL Router configured for the InnoDB Cluster 'mycluster'

After this MySQL Router has been started with the generated configuration

    $ ./mysqlrouter -c /root/mysqlrouter/mysqlrouter.conf

InnoDB Cluster 'mycluster' can be reached by connecting to:

MySQL Classic protocol

Read/Write Connections: localhost:6446, /root/mysqlrouter/mysql.sock  #router的读写端口

Read/Only Connections:  localhost:6447, /root/mysqlrouter/mysqlro.sock #router的只读端口

MySQL X protocol

Read/Write Connections: localhost:6448, /root/mysqlrouter/mysqlx.sock

Read/Only Connections:  localhost:6449, /root/mysqlrouter/mysqlxro.sock

最后

启动mysql-router即可

[root@gip bin]# 

[root@gip mysqlrouter]# pwd

/root/mysqlrouter

[root@gip mysqlrouter]# ls

data  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方案；

3、可用于借助Sqlproxy等实现读写分离，人工维护、读写扩展性受限的业务场景，此类场景可考虑升级GreatDB Paxos+VIP方案，有利于增强可扩展性和读写性能。

就在本周六，MySQL5.7版本也将迎来其生命周期的终结，GreatDB Paxos+VIP 方案同样可满足希望获得长期维保支持或想平行迁移到企业级商业数据库的企业用户需求。

此外，如果想寻找第二个有长期社区更新支持的开源版本，可选择万里数据库主导成立的GreatSQL开源社区中的GreatSQL开源数据库，GreatSQL开源数据库亦可同步支持vip plugin高可用方案。

————————————————

版权声明：本文为CSDN博主「万里数据库」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/GreatDB/article/details/133941949