优化数据库性能并降低成本是每位架构师和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     |+----------------------------------+----------+--------------------+----------------------+---------+

参数具体作用介绍：

SQL1、启用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= TRUEloose-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命令，如下提权：

SQLsetcap 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=1loose-greatdb_ha_mgr_vip_ip =172.17.134.200loose-greatdb_ha_mgr_vip_mask=255.255.0.0loose-greatdb_ha_mgr_vip_nic=eth0
loose-group_replication_single_primary_mode=1loose-group_replication_enforce_update_everywhere_checks=0

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

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

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

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

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

SQLloose-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，动态参数。

SQL loose-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:  mtu 1500 qdisc pfifo_fast state UP group default qlen 1000    inet 172.17.134.61/20 brd 172.17.143.255 scope global noprefixroute dynamic eth0
    inet 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:  mtu 1500 qdisc pfifo_fast state UP group default qlen 1000    inet 172.17.134.60/20 brd 172.17.143.255 scope global noprefixroute dynamic eth0
    inet 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 eth02: eth0:  mtu 1500 qdisc pfifo_fast state UP group default qlen 1000    inet 172.17.134.61/20 brd 172.17.143.255 scope global noprefixroute dynamic eth0
    inet 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 runWARNING: 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: 5Report intermediate results every 1 second(s)
Initializing random number generator from current timeInitializing 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 eth02: eth0:  mtu 1500 qdisc pfifo_fast state UP group default qlen 1000    inet 172.17.134.60/20 brd 172.17.143.255 scope global noprefixroute dynamic eth0
    inet 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损耗的性能？