技术干货 | GreatDB新一代读写分离架构,如何炼就近乎0损耗的性能?

本文主要是介绍技术干货 | GreatDB新一代读写分离架构,如何炼就近乎0损耗的性能?,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

优化数据库性能并降低成本是每位架构师和DBA都必须面对的挑战。其中,读写分离是一种常见方法:即通过将读操作和写操作分发到不同的数据库实例,实现多副本负载和性能提升。

传统的中间件方案,例如基于Proxysql、HAProxy、MySQL Router等方案,中间件路由转发效率瓶颈会导致性能明显下降,并且发生故障时,中间件的维护、数据库主备副本切换后的数据一致性判断、实例可用性等都需要DBA介入处理。

(传统读写分离架构)

那么,如何优化读写分离的中间件层或架构呢?

一、GreatDB Paxos高可用架构
我们来看下万里安全数据库GreatDB如何实现读写分离架构:  

读写分离的核心思想是将数据库的读操作和写操作分发到不同的数据库实例。通常情况下,业务SQL读写操作会被分发到主库(primary)上,而只读操作则被分发到其他副本节点(secondary)。

GreatDB Paxos+VIP架构通过判断数据库primary、secondary等角色节点,对外暴露读写VIP或只读VIP的方式提供给业务层。业务侧只需要接入不同的只读VIP和可读写VIP,即可实现读、写业务在不同数据库实例上完成,从而提供高效的数据读写分离。

二、安装配置步骤


安装前准备工作:


1、初始化Paxos实例部署组复制

    我们使用GreatADM管理平台快速部署GreatDB Paxos架构。按照规划,172.17.134.68为primary主实例,172.17.134.60-61为secondary 从实例,GreatADM自动在拓扑上打上数据库database_1-database_3的标签,方便大家辨识数据库实例节点。如下:

2、加载VIP PLUGIN并配置写VIP

通过图形化运维管理平台GreatADM在线加载VIP配置插件"greatdb_ha.so",默认提供基于primary主实例的读写vip配置,基于secondary从实例的只读vip,则可根据用户实际读写比例按需进行配置。过程如下:

图片

查看对应3个GreatDB实例的cnf配置文件,增加了如下几项参数:

SQL登录数据库,可通过show plugins命令查看加载的高可用插件mysql> show plugins;
+----------------------------------+----------+--------------------+----------------------+---------+
| Name                             | Status   | Type               | Library              | License |
+----------------------------------+----------+--------------------+----------------------+---------+
......
| group_replication                | ACTIVE   | GROUP REPLICATION  | group_replication.so | GPL     |
| greatdb_ha                       | ACTIVE   | DAEMON             | greatdb_ha.so        | GPL     |
+----------------------------------+----------+--------------------+----------------------+---------+


参数具体作用介绍:

SQL
1、启用VIP plugin 开启新插件,在my.cnf配置文件中增加
plugin_load_add=greatdb_ha.so
或者在启动数据库实例后, 执行
install plugin greatdb_ha soname 'greatdb_ha.so';2、开启浮动VIP功能
loose-greatdb_ha_enable_mgr_vip = 13、配置写浮动ip,写vip会随着primary主实例的切换漂移到新主实例上,做到绑定primary主实例的vip切换
loose-greatdb_ha_mgr_vip_ip = 172.17.134.2004、配置VIP所在网段的子网掩码
loose-greatdb_ha_mgr_vip_mask = '255.255.255.0'5、配置网卡名称,插件会将vip绑定到组复制的primary主实例所在机器指定网卡,比如配置为eth0,
为了防止网卡原有的ip被覆盖,实际绑定后,会绑定在名为eth0:0的网卡子口上
loose-greatdb_ha_mgr_vip_nic = 'eth0'6、目前只支持单主MGR模式,所以需要设置:
loose-group_replication_single_primary_mode= TRUE
loose-group_replication_enforce_update_everywhere_checks= FALSE


注意事项:
启用VIP绑定网卡,因需要root操作系统权限,需要做提权操作。
配置浮动IP需要相关内核权限,方法有两种,如下:

方法1:给greatdbd进程的启动用户(例如是greatdb用户)设置root权限,通过setcap为greatdbd可执行文件添加CAP_NET_ADMIN和CAP_NET_RAW的capability。需要sudo权限或root调用setcap命令,如下提权:

SQL
setcap CAP_NET_ADMIN,CAP_NET_RAW+ep bin/greatdbd

如果是setcap命令为greatdbd添加capability后, 需要登录系统的用户和启动greatdbd的保持一致,用root用户登录系统,再用普通用户启动greatdbd,setcap会失效,从而绑定浮动IP的时候报错没有权限。

方法2:对于LD_LIBRARY_PATH:可以把非系统目录下的动态库添加软链接到系统库,或在/etc/ld.so.conf.d/ 下添加greatdb.conf文件,并添加非系统库路径,一般是/path/to/greatdb/bin/../lib/private, 可以通过ldd bin/greatdbd查看。

SQL
示例如下:
[root@gip ~]# cat /etc/ld.so.preload
/greatdb/svr/greatdb/bin/../lib/private/libcrypto.so.1.1
/greatdb/svr/greatdb/bin/../lib/private/libssl.so.1.1
/greatdb/svr/greatdb/bin/../lib/private/libprotobuf-lite.so.3.19.4

完整greatbdb_ha.so plugin加载之后的my.cnf增加的参数:

SQL
[mysqld]
plugin-load-add=greatdb_ha.so
loose-greatdb_ha_enable_mgr_vip=1
loose-greatdb_ha_mgr_vip_ip =172.17.134.200
loose-greatdb_ha_mgr_vip_mask=255.255.0.0
loose-greatdb_ha_mgr_vip_nic=eth0
loose-group_replication_single_primary_mode=1
loose-group_replication_enforce_update_everywhere_checks=0


3、手动启用只读VIP并做配置

只读VIP可根据用户实际需求选配,当然用户可直接接入secondary节点,接入只读VIP的好处是:当secondary节点故障时可自动切换,保证业务的连续性。

接下来,只读vip是默认在两个secondary实例上配置浮动vip,配置方式如下:

JavaScript
配置读浮动ip, secondary节点会绑定读ip,允许配置多个只读vip,中间以‘,’逗号分隔,有几个secondary节点就可以配置几个read_viploose-greatdb_ha_mgr_read_vip_ips = "172.17.134.201"

当然,当secondary故障,也可选择读vip转移到primary实例,需要按需设置如下参数:

SQL
loose-greatdb_ha_mgr_read_vip_floating_type = "TO_ANOTHER_SECONDARY"配置读ip失效以后的处理方式有2种,分为两个参数值("TO_PRIMARY", "TO_ANOTHER_SECONDARY"):
当secondary节点故障是,重新绑定到primary上,或者重新绑定到另外一个活动的secondary节点上,默认值是TO_PRIMARY绑定到primary上。


两种模式下,vip故障切换过程如下:

假如GreatDB的3个数据库节点为A/B/C实例。

实例A为primary实例,其他2个B、C为secondary实例。假如B、C两个节点上支持各配置一个只读VIP,对业务层暴露1个,另1个可作为冗余备用。当主实例故障不可用时,原始绑定primary实例的写VIP会自动漂移到新选举出的primary实例B上。

实例B原有的只读VIP根据配置参数greatdb_ha_mgr_read_vip_floating_type的不同,其漂移行为有所不同:
1、当greatdb_ha_mgr_read_vip_floating_type=TO_PRIMARY时,实例B的读浮动IP将不受影响,因为它当前就是故障后集群的primary主节点;
2、当greatdb_ha_mgr_read_vip_floating_type=TO_ANOTHER_SECONDARY时,实例B的读浮动IP将主动漂移到实例C,即实例C将同时拥有两个读浮动IP。

其他参数

配置ARP包广播重复次数。当节点绑定浮动IP以后,广播ARP包来更新广播域内的ARP缓存,此参数是广播次数,默认是5次,合法取值范围为3-20,动态参数。

SQLloose-greatdb_ha_send_arp_packge_times = 5


配置通信端口,通过端口进行数据传输。当发生状态变更时,primary node根据原本的绑定关系,按照变更小、平均分配的原则重新分配绑定关系,并将绑定关系通过配置端口发送给secondary 节点, secondary节点根据绑定关系解绑或绑定指定vip。此参数为静态参数,需要重启实例才可生效。

Plain Text
loose-greatdb_ha_port = 33932


配置完成之后,在各个实例节点使用

set global greatdb_ha_force_change_mgr_vip=1 启用完整的写VIP+只读VIP配置,通过show variables like '%vip%'; 查看配置信息。

4、查看实例和网卡VIP绑定关系

JavaScript
·
mysql> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST   | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | a4dc970c-6bd6-11ee-bfe0-00163efffd9c | 172.17.134.68 |        3308 | ONLINE       | SECONDARY   | 8.0.32         | XCom                       |
| group_replication_applier | bc1563c5-6bd6-11ee-bd65-00163e036eee | 172.17.134.61 |        3308 | ONLINE       | PRIMARY     | 8.0.32         | XCom                       |
| group_replication_applier | bc16dfeb-6bd6-11ee-a8c1-00163ee52ace | 172.17.134.60 |        3308 | ONLINE       | SECONDARY   | 8.0.32         | XCom                       |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
3 rows in set (0.00 sec)1、查看primary 172.17.134.61实例主机的IP绑定信息,读写vip绑定在172.17.134.61主机eth0网卡上:2、[root@gip ~]# ip a |grep eth0
eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000inet 172.17.134.61/20 brd 172.17.143.255 scope global noprefixroute dynamic eth0inet 172.17.134.200/20 brd 172.17.143.255 scope global secondary eth0:13、查看secondary 实例主机的IP绑定信息如下,只读vip绑定在172.17.134.60主机eth0网卡上4、[root@gip ~]# ip a|grep eth0
eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000inet 172.17.134.60/20 brd 172.17.143.255 scope global noprefixroute dynamic eth0inet 172.17.134.201/20 brd 172.17.143.255 scope global secondary eth0:0
[root@gip ~]# 
[root@gip ~]# 

接下来,我们用sysbench来实际测试下写VIP+只读VIP的读写分离效果。

三、读写分离测试


使用sysbench数据库进行读写分离测试,分别使用oltp_read_write.lua + 写vip172.17.134.200做数据初始化写入,用oltp_read_only.lua+ 只读vip 做数据readonly查询。

首先连接写VIP创建测试库test_vip;并直接sysbench初始化写入测试数据,命令如下:

SQL
[root@gip ~]# greatdb -ugreatdb -p'!QAZ2wsx' -h172.17.134.200 -P3308 -e "create database test_vip" ;sysbench  /usr/share/sysbench/oltp_read_write.lua  --mysql-host=172.17.134.200  --mysql-port=3308   --mysql-user=greatdb --mysql-password='!QAZ2wsx' --mysql-db=test_vip --report-interval=1 --tables=10 --table-size=100000 --time=60 --threads=10 prepare ;sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)
Initializing worker threads...
Creating table 'sbtest1'...
Creating table 'sbtest3'...
Creating table 'sbtest9'...
Creating table 'sbtest4'...
Creating table 'sbtest10'...
Creating table 'sbtest6'...
Creating table 'sbtest5'...
Creating table 'sbtest7'...
Creating table 'sbtest2'...
Creating table 'sbtest8'...
Inserting 100000 records into 'sbtest3'
Inserting 100000 records into 'sbtest9'
Inserting 100000 records into 'sbtest6'
Inserting 100000 records into 'sbtest1'
Inserting 100000 records into 'sbtest4'
Inserting 100000 records into 'sbtest7'
Inserting 100000 records into 'sbtest5'
Inserting 100000 records into 'sbtest8'
Inserting 100000 records into 'sbtest2'
Inserting 100000 records into 'sbtest10'
Creating a secondary index on 'sbtest10'...
Creating a secondary index on 'sbtest7'...
Creating a secondary index on 'sbtest9'...
Creating a secondary index on 'sbtest6'...
Creating a secondary index on 'sbtest1'...
Creating a secondary index on 'sbtest2'...
Creating a secondary index on 'sbtest5'...
Creating a secondary index on 'sbtest3'...
Creating a secondary index on 'sbtest4'...
Creating a secondary index on 'sbtest8'...
[root@gip ~]# 
查看初始化的数据信息
[root@gip ~]# greatdb -ugreatdb -p'!QAZ2wsx' -h172.17.134.200 -P3308 -e "show tables from test_vip" 
greatdb: [Warning] Using a password on the command line interface can be insecure.
+--------------------+
| Tables_in_test_vip |
+--------------------+
| sbtest1            |
| sbtest10           |
| sbtest2            |
| sbtest3            |
| sbtest4            |
| sbtest5            |
| sbtest6            |
| sbtest7            |
| sbtest8            |
| sbtest9            |
+--------------------+
[root@gip ~]# 
[root@gip ~]# ip a |grep eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000inet 172.17.134.61/20 brd 172.17.143.255 scope global noprefixroute dynamic eth0inet 172.17.134.200/20 brd 172.17.143.255 scope global secondary eth0:1
[root@gip ~]# 数据初始化成功,测试数据正常写入,写vip有效绑定primary主实例,数据库可正常写入和查询。


只读vip压测:

SQL
[root@gip ~]#sysbench  --test=/usr/share/sysbench/oltp_read_only.lua  --mysql-host=172.17.134.201  --mysql-port=3308   --mysql-user=greatdb --mysql-password='!QAZ2wsx' --mysql-db=test_vip --report-interval=1 --tables=10 --table-size=100000 --time=60 --threads=5 run
WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.
sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)
Running the test with following options:
Number of threads: 5
Report intermediate results every 1 second(s)
Initializing random number generator from current time
Initializing worker threads...
Threads started!
[ 1s ] thds: 5 tps: 49.92 qps: 844.67 (r/w/o: 739.84/0.00/104.83) lat (ms,95%): 167.44 err/s: 0.00 reconn/s: 0.00
[ 2s ] thds: 5 tps: 54.96 qps: 895.40 (r/w/o: 785.48/0.00/109.93) lat (ms,95%): 108.68 err/s: 0.00 reconn/s: 0.00
[ 3s ] thds: 5 tps: 52.03 qps: 803.46 (r/w/o: 699.40/0.00/104.06) lat (ms,95%): 179.94 err/s: 0.00 reconn/s: 0.00
[ 4s ] thds: 5 tps: 45.99 qps: 731.90 (r/w/o: 639.91/0.00/91.99) lat (ms,95%): 287.38 err/s: 0.00 reconn/s: 0.00
[ 5s ] thds: 5 tps: 47.02 qps: 757.29 (r/w/o: 664.26/0.00/93.04) lat (ms,95%): 277.21 err/s: 0.00 reconn/s: 0.00
[ 6s ] thds: 5 tps: 45.99 qps: 749.82 (r/w/o: 656.84/0.00/92.98) lat (ms,95%): 204.11 err/s: 0.00 reconn/s: 0.00
[ 7s ] thds: 5 tps: 46.02 qps: 720.33 (r/w/o: 628.28/0.00/92.04) lat (ms,95%): 297.92 err/s: 0.00 reconn/s: 0.00
[ 8s ] thds: 5 tps: 47.97 qps: 764.58 (r/w/o: 669.63/0.00/94.95) lat (ms,95%): 282.25 err/s: 0.00 reconn/s: 0.00
[ 9s ] thds: 5 tps: 43.98 qps: 716.64 (r/w/o: 627.69/0.00/88.96) lat (ms,95%): 287.38 err/s: 0.00 reconn/s: 0.00
[ 10s ] thds: 5 tps: 49.05 qps: 773.79 (r/w/o: 676.69/0.00/97.10) lat (ms,95%): 277.21 err/s: 0.00 reconn/s: 0.00
[ 11s ] thds: 5 tps: 43.96 qps: 721.41 (r/w/o: 632.48/0.00/88.93) lat (ms,95%): 303.33 err/s: 0.00 reconn/s: 0.00
[ 12s ] thds: 5 tps: 50.02 qps: 793.33 (r/w/o: 693.29/0.00/100.04) lat (ms,95%): 287.38 err/s: 0.00 reconn/s: 0.00
[ 13s ] thds: 5 tps: 46.97 qps: 754.54 (r/w/o: 660.60/0.00/93.94) lat (ms,95%): 308.84 err/s: 0.00 reconn/s: 0.00
[ 14s ] thds: 5 tps: 40.03 qps: 634.51 (r/w/o: 554.45/0.00/80.06) lat (ms,95%): 325.98 err/s: 0.00 reconn/s: 0.00
[ 15s ] thds: 5 tps: 52.00 qps: 835.06 (r/w/o: 732.05/0.00/103.01) lat (ms,95%): 108.68 err/s: 0.00 reconn/s: 0.00......[root@gip ~]# ip a|grep eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000inet 172.17.134.60/20 brd 172.17.143.255 scope global noprefixroute dynamic eth0inet 172.17.134.201/20 brd 172.17.143.255 scope global secondary eth0:0
[root@gip ~]# 尝试连接只读VIP做写入操作:[root@gip ~]#greatdb -ugreatdb -p'!QAZ2wsx' -h172.17.134.201 -P3308 -e "create database test_write" 
greatdb: [Warning] Using a password on the command line interface can be insecure.
ERROR 1290 (HY000) at line 1: The MySQL server is running with the --super-read-only option so it cannot execute this statement
[root@gip ~]# 结论:只读VIP可正常做只读压测,绑定secondary节点,只读功能正常,拒绝写入数据。

四、方案优势


通过读写分离架构和网卡子口绑定VIP的方式,可以实现数据库实例的分离和近0性能损耗的目标。

GreatDB Paxos+VIP架构优化精简了中间件的SQL转发过程,从根本上做到了读写负载分离,且greatdb_ha.so plugin和数据库集成于一身,实现了简单、易用、高效,具体优势如下:


1提高数据库性能
通过将读操作和写操作分发到不同的数据库实例,可以充分利用多副本负载的优势,提高数据库的性能和响应速度;

2降低成本
基于现有的物理网卡子口,实现网络带宽的高效使用,无需独立部署中间件层,剔除人工维护中间件时间,降低硬件成本;

3增强可用性
在主节点发生故障时,只读VIP可以自动转移到其他活动的实例节点继续提供服务,避免了单点故障和瓶颈问题,增强了系统可用性和稳定性;

4简化维护和管理
内置plugin方式,解决了传统业务借助keepalived、lvs等外部软件安装部署及配置的过程,并且可以动态灵活地启用、禁用,搭配万里数据库GreatADM图形化管理平台,可实现一键式的交付部署,提升整体方案交付效率;

5扩展性增强
读写分离架构和网卡子口绑定VIP+paxos高可用组复制,可以更方便地实现扩展。最多可扩展为9个数据副本,实现系统的在线水平扩展,从而能够满足客户日益增长的业务需求。

综上所述,使用GreatDB Paxos+VIP架构既可保证业务层读写分离的诉求,又能尽可能地减少性能损耗,使性能损耗近乎为0。与此同时,保证了故障切换对业务透明,不需要DBA过多技术投入、维护代价较低。

因此,对于需要提高数据库性能并降低成本的企业来说,GreatDB Paxos+VIP架构是一种非常有吸引力的高可用方案。

这篇关于技术干货 | GreatDB新一代读写分离架构,如何炼就近乎0损耗的性能?的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/364958

相关文章

SpringBoot3实现Gzip压缩优化的技术指南

《SpringBoot3实现Gzip压缩优化的技术指南》随着Web应用的用户量和数据量增加,网络带宽和页面加载速度逐渐成为瓶颈,为了减少数据传输量,提高用户体验,我们可以使用Gzip压缩HTTP响应,... 目录1、简述2、配置2.1 添加依赖2.2 配置 Gzip 压缩3、服务端应用4、前端应用4.1 N

SpringBoot实现数据库读写分离的3种方法小结

《SpringBoot实现数据库读写分离的3种方法小结》为了提高系统的读写性能和可用性,读写分离是一种经典的数据库架构模式,在SpringBoot应用中,有多种方式可以实现数据库读写分离,本文将介绍三... 目录一、数据库读写分离概述二、方案一:基于AbstractRoutingDataSource实现动态

Java利用JSONPath操作JSON数据的技术指南

《Java利用JSONPath操作JSON数据的技术指南》JSONPath是一种强大的工具,用于查询和操作JSON数据,类似于SQL的语法,它为处理复杂的JSON数据结构提供了简单且高效... 目录1、简述2、什么是 jsONPath?3、Java 示例3.1 基本查询3.2 过滤查询3.3 递归搜索3.4

Python如何使用__slots__实现节省内存和性能优化

《Python如何使用__slots__实现节省内存和性能优化》你有想过,一个小小的__slots__能让你的Python类内存消耗直接减半吗,没错,今天咱们要聊的就是这个让人眼前一亮的技巧,感兴趣的... 目录背景:内存吃得满满的类__slots__:你的内存管理小助手举个大概的例子:看看效果如何?1.

springboot security之前后端分离配置方式

《springbootsecurity之前后端分离配置方式》:本文主要介绍springbootsecurity之前后端分离配置方式,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的... 目录前言自定义配置认证失败自定义处理登录相关接口匿名访问前置文章总结前言spring boot secu

Python中随机休眠技术原理与应用详解

《Python中随机休眠技术原理与应用详解》在编程中,让程序暂停执行特定时间是常见需求,当需要引入不确定性时,随机休眠就成为关键技巧,下面我们就来看看Python中随机休眠技术的具体实现与应用吧... 目录引言一、实现原理与基础方法1.1 核心函数解析1.2 基础实现模板1.3 整数版实现二、典型应用场景2

Java异常架构Exception(异常)详解

《Java异常架构Exception(异常)详解》:本文主要介绍Java异常架构Exception(异常),具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录1. Exception 类的概述Exception的分类2. 受检异常(Checked Exception)

Redis中高并发读写性能的深度解析与优化

《Redis中高并发读写性能的深度解析与优化》Redis作为一款高性能的内存数据库,广泛应用于缓存、消息队列、实时统计等场景,本文将深入探讨Redis的读写并发能力,感兴趣的小伙伴可以了解下... 目录引言一、Redis 并发能力概述1.1 Redis 的读写性能1.2 影响 Redis 并发能力的因素二、

Golang中拼接字符串的6种方式性能对比

《Golang中拼接字符串的6种方式性能对比》golang的string类型是不可修改的,对于拼接字符串来说,本质上还是创建一个新的对象将数据放进去,主要有6种拼接方式,下面小编就来为大家详细讲讲吧... 目录拼接方式介绍性能对比测试代码测试结果源码分析golang的string类型是不可修改的,对于拼接字

mysql线上查询之前要性能调优的技巧及示例

《mysql线上查询之前要性能调优的技巧及示例》文章介绍了查询优化的几种方法,包括使用索引、避免不必要的列和行、有效的JOIN策略、子查询和派生表的优化、查询提示和优化器提示等,这些方法可以帮助提高数... 目录避免不必要的列和行使用有效的JOIN策略使用子查询和派生表时要小心使用查询提示和优化器提示其他常