技术干货 | 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

相关文章

Springboot中分析SQL性能的两种方式详解

《Springboot中分析SQL性能的两种方式详解》文章介绍了SQL性能分析的两种方式:MyBatis-Plus性能分析插件和p6spy框架,MyBatis-Plus插件配置简单,适用于开发和测试环... 目录SQL性能分析的两种方式:功能介绍实现方式:实现步骤:SQL性能分析的两种方式:功能介绍记录

springboot将lib和jar分离的操作方法

《springboot将lib和jar分离的操作方法》本文介绍了如何通过优化pom.xml配置来减小SpringBoot项目的jar包大小,主要通过使用spring-boot-maven-plugin... 遇到一个问题,就是每次maven package或者maven install后target中的ja

配置springboot项目动静分离打包分离lib方式

《配置springboot项目动静分离打包分离lib方式》本文介绍了如何将SpringBoot工程中的静态资源和配置文件分离出来,以减少jar包大小,方便修改配置文件,通过在jar包同级目录创建co... 目录前言1、分离配置文件原理2、pom文件配置3、使用package命令打包4、总结前言默认情况下,

Tomcat高效部署与性能优化方式

《Tomcat高效部署与性能优化方式》本文介绍了如何高效部署Tomcat并进行性能优化,以确保Web应用的稳定运行和高效响应,高效部署包括环境准备、安装Tomcat、配置Tomcat、部署应用和启动T... 目录Tomcat高效部署与性能优化一、引言二、Tomcat高效部署三、Tomcat性能优化总结Tom

MySQL 缓存机制与架构解析(最新推荐)

《MySQL缓存机制与架构解析(最新推荐)》本文详细介绍了MySQL的缓存机制和整体架构,包括一级缓存(InnoDBBufferPool)和二级缓存(QueryCache),文章还探讨了SQL... 目录一、mysql缓存机制概述二、MySQL整体架构三、SQL查询执行全流程四、MySQL 8.0为何移除查

微服务架构之使用RabbitMQ进行异步处理方式

《微服务架构之使用RabbitMQ进行异步处理方式》本文介绍了RabbitMQ的基本概念、异步调用处理逻辑、RabbitMQ的基本使用方法以及在SpringBoot项目中使用RabbitMQ解决高并发... 目录一.什么是RabbitMQ?二.异步调用处理逻辑:三.RabbitMQ的基本使用1.安装2.架构

C#使用yield关键字实现提升迭代性能与效率

《C#使用yield关键字实现提升迭代性能与效率》yield关键字在C#中简化了数据迭代的方式,实现了按需生成数据,自动维护迭代状态,本文主要来聊聊如何使用yield关键字实现提升迭代性能与效率,感兴... 目录前言传统迭代和yield迭代方式对比yield延迟加载按需获取数据yield break显式示迭

Python实现高效地读写大型文件

《Python实现高效地读写大型文件》Python如何读写的是大型文件,有没有什么方法来提高效率呢,这篇文章就来和大家聊聊如何在Python中高效地读写大型文件,需要的可以了解下... 目录一、逐行读取大型文件二、分块读取大型文件三、使用 mmap 模块进行内存映射文件操作(适用于大文件)四、使用 pand

C# 读写ini文件操作实现

《C#读写ini文件操作实现》本文主要介绍了C#读写ini文件操作实现,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧... 目录一、INI文件结构二、读取INI文件中的数据在C#应用程序中,常将INI文件作为配置文件,用于存储应用程序的

Ubuntu系统怎么安装Warp? 新一代AI 终端神器安装使用方法

《Ubuntu系统怎么安装Warp?新一代AI终端神器安装使用方法》Warp是一款使用Rust开发的现代化AI终端工具,该怎么再Ubuntu系统中安装使用呢?下面我们就来看看详细教程... Warp Terminal 是一款使用 Rust 开发的现代化「AI 终端」工具。最初它只支持 MACOS,但在 20