使用ProxySQL实现MySQL Group Replication的故障转移、读写分离（一）

概述导读：在之前，我们搭建了MySQL组复制集群环境，MySQL组复制集群环境解决了MySQL集群内部的自动故障转移，但是，组复制并没有解决外部业务的故障转移。举个例子，在A、B、C 3台机器上搭建了组复

导读：

在之前，我们搭建了MysqL组复制集群环境，MysqL组复制集群环境解决了MysqL集群内部的自动故障转移，但是，组复制并没有解决外部业务的故障转移。举个例子，在A、B、C 3台机器上搭建了组复制环境，且运行在单主模式下，这里假设A为主节点，应用程序连接A写数据，如果A节点发生宕机，主节点切换到B机器上，此时，应用程序是不会自动连接到B服务器上的，需要人工进行切换。

在这篇文章中，我们要介绍的Proxysql就能够解决上面的问题，Proxysql能够实现业务层面故障转移、读写分离功能，当然Proxysql不仅仅只有这两项功能，还有更多的其它功能。其架构如下：

我们不妨来了解一下。

（一）Proxysql简介

Proxysql是一款MysqL代理软件，其核心特点为读写分离、故障转移，详细其功能如下：

应用层代理。Proxysql不仅能够实现负载均衡，还可提供端到端连接处理、实时信息统计和数据库流量检查；零停机时间变更。Proxysql在内存中直接进行配置修改，然后可以持久存储到磁盘和推送到运行中；数据库防火墙。可充当应用程序与数据库之间的防火墙，使DBA可以保护数据库免受恶意活动或有问题的程序的影响；高级查询规则。使用Proxysql丰富的查询规则定义查询路由，有效的分发和缓存数据，从而最大的提高数据库服务缓存效率；数据分片与转换故障转移检测。Proxysql通过连续监视数据库后端并在拓扑更改时将流量重新路由到运行正常的节点。

这里，我们使用Proxysql来对MysqL组复制环境实现读写分离以及故障转移。我的环境如下：

IP地址	主机名	用途
192.168.10.11	mgr-node1	MysqL组复制成员
192.168.10.12	mgr-node2	MysqL组复制成员
192.168.10.13	mgr-node3	MysqL组复制成员
192.168.10.10	proxysql	Proxysql代理服务器

MysqL采用多主模式，搭建过程见文档：《MySQL组复制MGR（二）-- 组复制搭建》，本文把重点放在Proxysql的搭建与配置上。

（二）安装Proxysql

安装Proxysql，有2种方法，如果有网络，可以直接使用yum安装，如果没有网络，可以下载Proxysql发行包安装，下载地址为：https://github.com/sysown/proxysql/releases。这里为了方便，直接使用yum在线安装。
添加yum源，使用linux root用户执行如下配置：

cat <<EOF | tee /etc/yum.repos.d/proxysql.repo[proxysql_repo]name= Proxysql YUM repositorybaseurl=https://repo.proxysql.com/Proxysql/proxysql-2.0.x/centos/$releasevergpgcheck=1gpgkey=https:repo.proxysql.com/Proxysql/repo_pub_keyEOF

安装proxysql：

yum install -y proxysql OR install proxysql-version

如果要查看安装的文件在哪，可以使用如下命令：

[root@proxysql yum.repos.d]# rpm -ql proxysql/etc/logrotate.d/proxysql/etc/proxysql.cnf/etc/systemd/system/proxysql-initial.service/etc/systemd/system/proxysql.service/usr/bin/proxysql/usr/share/proxysql/tools/proxysql_galera_checker.sh/usr/share/proxysql/tools/proxysql_galera_writer.pl

查看Proxysql进程：

yum.repos.d]# ps -ef|grep proxyavahi 740 1 0 15:52 ? 00:00 avahi-daemon: registering [proxysql-65.local]root 761 00 /usr/sbin/gssproxy -Dproxysql 2058 16:09 ? 00 /usr/bin/proxysql --IDle-threads -c /etc/proxysql.cnfproxysql 2059 proxysql.cnfroot 2087 1589 09 pts/00 grep --color=auto proxy

查看端口，6032是proxysql的管理端口，6033是对外服务端口

yum.repos.d]# netstat -anlp | proxysqltcp 0.0.0.0:6032 0.0:* ListEN 2059/proxysqltcp 6033 2059/proxysql

（三）启动关闭Proxysql

启动Proxysql

service proxysql start

关闭Proxysql

service proxysql stop

重启Proxysql

service proxysql restart

查看Proxysql的状态

service proxysql status

（四）Proxysql基础知识了解

Proxysql的配置，相对而言还是比较复杂的。因此，在配置Proxysql之前，我们需要对其架构有一些了解，这样在配置的时候，才不会一脸懵逼。

(4.1)Proxysql多层配置系统

前面我们说到Proxysql具有“零停机时间变更”功能，它是通过3层配置来实现的，3层配置包括：Runtime、Memory、disk & Configuration file。

Runtime层表示Proxysql工作线程使用的内存数据结构；Memory(也被称为main)层经由一个MysqL兼容接口露出的内存数据库，用户可以使用MysqL客户端连接到管理界面，查看、编辑Proxysql配置表；disk & Configuration file。disk层是一个存放在磁盘上的sqlite3数据库，disk层可将内存中的配置信息保存到磁盘，以便Proxysql重新启动后配置还可用。

3个层面的信息有什么区别呢？我个人的理解是：3个层面保存的都是Proxysql的配置信息，如果管理员未作修改，那么3个层面的配置信息是相同的。如果管理员要修改配置信息，首先需要修改Memory层，要让修改的信息立刻生效，则需要把Memory层的变更信息推到Runtime层；要让修改的配置信息在Proxysql重启后还能保存下来，则需要把Memory层的信息推到disk层。Runtime层是Proxysql正在使用的配置信息，Memory层是用户可以编辑的信息，disk层可以把配置信息永久保存在磁盘上。

各层之间数据如何同步呢？我们可以看上图的箭头部分，通过load/save命令来实现同步。具体命令如下：

[1] LOAD <item> FROM MEMORY/LOAD <item> TO RUNTIME将配置项从内存数据库加载到运行时数据结构[2] SAVE <item> TO MEMORY/SAVE <item> FROM RUNTIME将配置项从运行时保存到内存数据库中[3] LOAD <item> TO MEMORY/LOAD <item> FROM disK将持久性配置项目从磁盘数据库加载到内存数据库[4] SAVE <item> FROM MEMORY/SAVE <item> TO disK将配置项从内存数据库保存到磁盘数据库[5] LOAD <item> FROM CONfig将配置项从配置文件加载到内存数据库中

常用的配置有：

# 激活用户配置到RUNTIMELOAD MysqL USERS TO RUNTIME;# 保存用户信息到磁盘上SAVE MysqL USERS TO disK;---------------------------------# 激活MysqL服务器信息到RUNTIMELOAD MysqL SERVERS TO RUNTIME;# 保存MysqL服务器信息到磁盘SAVE MysqL SERVERS TO disK;---------------------------------# 激活查询路由规则到RUNTIMELOAD MysqL query RulES TO RUNTIME;# 保存查询路由规则到磁盘SAVE MysqL query RulES TO disK;----------------------------------# 激活MysqL变量到RUNTIMELOAD MysqL VARIABLES TO RUNTIME;# 保存MysqL变量到磁盘SAVE MysqL VARIABLES TO disK;----------------------------------# 激活proxysql admin变量到RUNTIMELOAD admin VARIABLES TO RUNTIME;# 保存proxysql admin变量到磁盘SAVE admin VARIABLES TO disK;

(4.2)Proxysql的配置管理接口

Proxysql有2种配置方式：

使用Proxysql的命令行管理接口进行配置使用配置文件进行配置

通常使用第一种方法进行配置，这里我们只了解第1种方法。

Proxysql管理界面使用的是MysqL协议的界面，通过使用MysqL客户端连接到sqlite3进行配置的查询、管理。可以使用默认的admin用户连接到proxysql数据库。

[root@proxysql ~]# MysqL -uadmin -padmin -h127.0.0.1 -P6032MysqL> show databases;+-----+---------------+-------------------------------------+ | seq | name          | file                                || 0   | main          |                                     | 2   disk          /var/lib/proxysql/proxysql.db       3   | stats         4   | monitor       5   | stats_history /proxysql_stats.db ---+---------------+-------------------------------------+

这些数据库作用如下：

main：内存配置数据库，使用此数据库，可以方便的查询和更新Proxysql的配置。与上面所曾配置系统的Memory层对应；disk：“main”数据库的磁盘镜像。重新启动Proxysql时，main中的数据就是从该数据库加载的。与上面所曾配置系统的disk层对应；stats：Proxysql收集的一些指标。如每个查询规则的匹配次数，当前正在运行的查询等；monitor：包含于Proxysql连接的后端服务器的指标。如连接带后端服务器对其进行Ping *** 作的最小、最大时间；

Proxysql设定了2个用户来管理配置数据库：

账号admin  密码admin : 该用户具有全部标的读写权限；账号stats  密码stats : 该用户具有统计信息表的只读权限；

（五）一步一步配置Proxysql--基础配置

（5.1）检查配置信息

查看相关配置表是否存在信息，因为还没开始配置，所以是不存在信息的，如果已经配置过了，可以先删除信息。

MysqL> select * from MysqL_servers;Empty set (0.00 sec)MysqL MysqL_users;Empty 0.01 MysqL_query_rules;Empty  MysqL_group_replication_hostgroups;Empty 0.00 sec)

（5.2）组的配置

所谓组的配置，即定义读组、写组等，可以使用如下两个表来定义读写组：

MysqL_replication_hostgroups：该表用于传统的master/slave的异步复制或者半同步复制的配置。MysqL_group_replication_hostgroups:该表用于MysqL Group Replication、InnoDB Cluster or galera/Percona XTradB Cluster的配置

因为我们这里是使用proxysql来实现MGR集群业务层面的实现故障转移以及读写分离的，所以配置MysqL_group_replication_hostgroups表即可，该表定义如下：

show create table MysqL_group_replication_hostgroups;----------------------------------------------------------CREATE table MysqL_group_replication_hostgroups (    writer_hostgroup INT CHECK (writer_hostgroup>=0) NOT NulL PRIMARY KEY,backup_writer_hostgroup CHECK (backup_writer_hostgroup0 AND backup_writer_hostgroup<>writer_hostgroup) NulLINT CHECK (reader_hostgroup<>writer_hostgroup <>reader_hostgroup AND reader_hostgroup>0),offline_hostgroup CHECK (offline_hostgroupAND offline_hostgroup<>offline_hostgroup CHECK (active IN (0,1)) DEFAulT 1CHECK (max_writers >= 0) CHECK (writer_is_also_reader 1,1); Font-weight: bold">2)) CHECK (max_transactions_behindVARCHARUNIQUE (reader_hostgroup),1)"> (offline_hostgroup),1)">UNIQUE (backup_writer_hostgroup))

这些字段含义如下：

write_hostgroup：默认情况下会将所有流量发送到这个组。具有read_only=0的节点也将分配到这个组；backup_writer_hostgroup：如果集群有多个写节点(read_only=0)且超过了max_writers规定数量，则会把多出来的写节点放到备用写组里面；reader_hostgroup：读取的流量应该发送到该组，只读节点(read_only=1)会被分配到该组；offline_hostgroup：当Proxysql监视到某个节点不正常时，会被放入该组；active：是否启用主机组，当启用时，Proxysql将监视主机在各族之间移动；max_writers：最大写节点的数量，超过该值的节点应该被放入backup_write_hostgroup；writer_is_also_reader：一个节点既做写节点也做读节点，如果该值为2，则backup_writer_hostgroup的节点做读写点，但是writer_hostgroup不会做读节点；

我们对该表进行如下配置：

MysqL_group_replication_hostgroups;----------------+-------------------------+------------------+-------------------+--------+-------------+-----------------------+-------------------------+---------+| writer_hostgroup | backup_writer_hostgroup | reader_hostgroup | offline_hostgroup | active | max_writers | writer_is_also_reader | max_transactions_behind | comment 1 2 3 4 1 1 0 100 NulL ----------------+-------------------------+------------------+-------------------+--------+-------------+-----------------------+-------------------------+---------+

（5.3）视图添加

如果Proxysql是与组复制MGR一起使用的，那么还需要在MGR集群添加如下视图：

USE sys;DEliMITER $$FUNCTION IFZERO(a INT,b INT)RETURNS DETERMINISTICRETURN IF(a = FUNCTION LOCATE2(needle TEXT(10000),haystack RETURN IFZERO(LOCATE(needle,haystack,offset),LENGTH(haystack) + )$$FUNCTION GTID_norMAliZE(g 10000)))DETERMINISTICRETURN GTID_SUBTRACT(g,''FUNCTION GTID_COUNT(gtID_set BEGIN DECLARE result BIGINT ; DECLARE colon_pos DECLARE next_dash_pos DECLARE next_colon_pos DECLARE next_comma_pos SET gtID_set = GTID_norMAliZE(gtID_set); SET colon_pos = LOCATE2(':',gtID_set,1)">); WHILE colon_pos != LENGTH(gtID_set) DO SET next_dash_pos -); SET next_colon_pos SET next_comma_pos IF next_dash_pos < next_colon_pos AND next_dash_pos < next_comma_pos THEN SET result = result SUBSTR(gtID_set,next_dash_pos - (next_dash_pos - (colon_pos ; ELSE END IF next_colon_pos; WHILERETURN result;END$$FUNCTION gr_applIEr_queue_length()RETURN (SELECT sys.gtID_count( GTID_SUBTRACT( (SELECTReceived_transaction_set FROM performance_schema.replication_connection_statusWHERE Channel_name = group_replication_applIEr' ),(SELECT@@global.GTID_EXECUTED) ))); gr_member_in_primary_partition()VARCHAR(3SELECT IF( MEMBER_STATE=ONliNE' AND ((SELECT COUNT(*) performance_schema.replication_group_members WHERE MEMBER_STATE != ') >=((FROM performance_schema.replication_group_members)/2) YESNO' ) FROM performance_schema.replication_group_members JOINperformance_schema.replication_group_member_stats USING(member_ID));VIEW gr_member_routing_candIDate_status AS sys.gr_member_in_primary_partition() as viable_candIDate,1)">IF( (SELECT (SELECT GROUP_CONCAT(variable_value) performance_schema.global_variables WHERE variable_name IN (read_only'super_read_only')) OFF,OFF'),1)">') read_only,sys.gr_applIEr_queue_length() as transactions_behind,Count_Transactions_in_queue as transactions_to_cert' performance_schema.replication_group_member_stats;$$DEliMITER ;

然后授权给监控用户，这里需要特别注意，我的监控用户在5.5.1步才创建，因此这一步需要放到5.5.1后执行：

grant select on sys.to monitoring_user;

（5.4）MysqL服务器添加

MysqL_server表是用来存储Proxysql路由转换的MysqL节点的信息。

> insert into MysqL_servers (hostgroup_ID,hostname,port) values(192.168.10.113306);MysqL192.168.10.12192.168.10.13); MysqL_servers;------------+---------------+------+-----------+--------+--------+-------------+-----------------+---------------------+---------+----------------+---------+| hostgroup_ID | hostname | port | gtID_port | status | weight | compression | max_connections | max_replication_lag | use_ssl | max_latency_ms 1 192.168.10.11 3306 0 | ONliNE 0 1000 0 0 0 | 10.12 10.13 ------------+---------------+------+-----------+--------+--------+-------------+-----------------+---------------------+---------+----------------+---------+

然后执行下面的命令生效：

LOAD MysqL SERVERS TO RUNTIME;SAVE MysqL SERVERS TO disK;

（5.5）监控配置及检查

这里配置监控信息，用来监控Proxysql与后端的MysqL通信是否正常。

（5.5.1）监控用户配置

在Proxysql的变量表里面设定监控用户密码，用于Proxysql监控后端MysqL服务器的用户信息

UPDATE global_variables SET variable_valuemonitorWHERE variable_nameMysqL-monitor_username;query OK,1 row affected (MysqL-monitor_passwordselect variable_name,variable_value from global_variables where variable_name in ();----------------------+----------------+| variable_name | variable_value | MysqL-monitor_password | monitor -monitor_username ----------------------+----------------+

需要注意，既然使用该用户监控后台MysqL数据库，那么后台MysqL数据库也需要创建该用户并授权，monitor用户需要有usage权限去连接、Ping和检查read_only信息，如果要检测复制延迟，还需要具有replication clIEnt权限。特别注意，不能使用MysqL_users里面的用户来做监控用户。

在MysqL服务器上创建监控用户-- 需要注意，这里MysqL使用的是MGR，所以只需要在一台节点创建用户即可，其它节点会自动同步用户信息create user monitor@%' IDentifIEd by ;grant usage,replication clIEnt on *.to monitor@%';flush privileges;

注意：因为Proxysql+组复制添加了新的视图，见”5.3 视图添加”，因此还需授权：

to monitor;

(5.5.2)配置监控间隔

这里把连接、Ping、read_only监控间隔改为2s，也可以根据需要改成其它，也可以不做修改

MysqLupdate global_variables set variable_value2000'     -> in(MysqL-monitor_connect_intervalMysqL-monitor_Ping_intervalMysqL-monitor_read_only_interval);query OK,1)">3 rows affected (0.00like MysqL-monitor%;------------------------------------------------------------+----------------+| variable_name                                                -monitor_enabled                                        | true           -monitor_connect_timeout                                600            -monitor_Ping_max_failures                              3              -monitor_Ping_timeout                                   1000           -monitor_read_only_max_timeout_count                    -monitor_replication_lag_interval                       10000          -monitor_replication_lag_timeout                        -monitor_groupreplication_healthcheck_interval          5000           -monitor_groupreplication_healthcheck_timeout           800            -monitor_groupreplication_healthcheck_max_timeout_count -monitor_groupreplication_max_transactions_behind_count -monitor_galera_healthcheck_interval                    -monitor_galera_healthcheck_timeout                     -monitor_galera_healthcheck_max_timeout_count           -monitor_replication_lag_use_percona_heartbeat          |                -monitor_query_interval                                 60000          -monitor_query_timeout                                  100            -monitor_slave_lag_when_null                            60             -monitor_threads_min                                    8              -monitor_threads_max                                    128            -monitor_threads_queue_maxsize                          -monitor_wait_timeout                                   -monitor_writer_is_also_reader                          -monitor_username                                       -monitor_password                                       -monitor_history                                        600000         -monitor_connect_interval                               2000           -monitor_Ping_interval                                  -monitor_read_only_interval                             -monitor_read_only_timeout                              500            30 rows in 0.01 sec)

在修改完变量之后，一定要加载到内存中生效以及永久保存到磁盘中：

LOAD MysqL VARIABLES SAVE MysqL VARIABLES disK;

(5.5.3)检查监控信息是否存在异常

监控配置完成后，我们需要检查Proxysql与后端MysqL通信是否有异常，monitor数据库中的表用于存储监视信息，需要注意的是，这些表并非都已经被使用。

> show tables monitor;------------------------------------+| tables | MysqL_server_aws_aurora_check_status | MysqL_server_aws_aurora_failovers | MysqL_server_aws_aurora_log | MysqL_server_connect_log | MysqL_server_galera_log | MysqL_server_group_replication_log | MysqL_server_Ping_log | MysqL_server_read_only_log | MysqL_server_replication_lag_log ------------------------------------+

查看Proxysql与后台服务器连接是否正常：

from monitor.MysqL_server_connect_log order by time_start_us desc limit 10; -------------+------+------------------+-------------------------+---------------+ | time_start_us | connect_success_time_us | connect_error 1596263409501584 2191 NulL 1596263409480641 1911 1596263409459524 3671 1596263407504677 1451 1596263407481776 1398 1596263407458859 1378 1596263405490389 3480 1596263405474367 2804 1596263405458569 1612 1596263403497485 2132 10 rows 0.00 sec)

查看组复制是否正常，检查节点是否只读和交易滞后时间：

from MysqL_server_group_replication_log -------------+------+------------------+-----------------+------------------+-----------+---------------------+-------+ | success_time_us | viable_candIDate | read_only | transactions_behind | error 1596263494597039 5671 | YES | NO NulL 1596263494596052 3231 1596263494595139 3245 1596263489596357 3027 1596263489595491 3306 1596263489594645 3110 1596263484595710 3680 1596263484594839 3618 1596263484594114 3214 1596263479595072 1887 0.01 sec)

查看Proxysql Ping后端MysqL服务器是否正常：

from MysqL_server_Ping_log -------------+------+------------------+----------------------+------------+ | Ping_success_time_us | Ping_error 1596263541810631 496 NulL 1596263541786903 612 1596263541762973 749 1596263539796079 565 1596263539779040 403 1596263539762769 1141 1596263537797512 848 1596263537779520 845 1596263537761840 742 1596263535814945 843 0.00 sec)

通过监控信息，我们可以得出结论，所有配置都是健康的，继续下一步。

(5.6)用户配置

（5.6.1）Proxysql的双层用户认证机制

如果使用了Proxysql来做中间路由，那么与我们平时登录数据库有一些区别：平时我们直接使用数据库的用户密码，即可访问到数据库，如果使用了Proxysql，则要先使用账号密码访问到Proxysql的数据库，然后再由Proxysql进行用户请求的转发，那么，Proxysql中的用户与数据库层的用户有什么关联呢？很奇怪，这部分Proxysql居然没在文档里面给出来。

只能自己测试了，经过个人测试，发现：当中间件用户与数据库用户以及密码一致时，才能正常访问数据库。测试结果如下：

MysqL数据库用户(MysqL.user表)	Proxysql用户（main.MysqL_users表）	使用Proxysql的6033端口访问数据库
usera	usera	正常访问
userb		无法登入proxysql
	userc	可以登入proxysql，但是无法读写

这里是我的测试过程：

在MysqL数据库上创建用户：usera和userb

user `usera`@`%` IDentifIEd 123456grant all privileges to `usera`@`%`;user `userb`@`to `userb`@``;flush privileges;

在Proxysql上创建用户：usera和userc

into MysqL_users(username,password,default_hostgroup) values(userausercload MysqL users to runtime;save MysqL users to disk;

登入测试(分为2步：先登入，再查询)：
（1）usera用户登入无问题，查询无问题

-uusera -p123456 -P6033 -h192.168.10.MysqLselect count( lijiamandb.test03; --------+ | *) | --------+1 row 0.01 sec)

（2）userb无法登入，提示用户名密码错误

-uuserb MysqL: Warning] Using a password on the command line interface can be insecure. ERROR 1045 (28000): Proxysql Error: Access denIEd for user userb'@192.168.10.10' (using password: YES)

（3）userc可以正常登入，但是查询的时候提示密码不对

-uuserc lijiamandb.test03;ERROR 28000): Access denIEd ' (using password: YES)

用户认证小结：只有Proxysql中的用户名密码与MysqL中的用户名密码相同时，才能正常访问底层MysqL数据库。因此，如果要使用Proxysql访问数据库，需要在MysqL和Proxysql中都要创建相同的账号，并且密码也要保持一致。

（5.6.2）Proxysql用户创建

Proxysql的用户保存在MysqL_users表中，用户创建直接执行insert插入即可。如创建一个用户名为“lijiaman”，密码为“123456”，默认用户组为1的用户：

lijiaman1);需要特别注意，现在该用户只在Memory层进行了修改，没有同步到RUNTIME层生效，也没有保存到磁盘，需要使用下面的命令来完成 *** 作。
disk;

MysqL_users表最重要的字段为：

usernamepassworddefault_hostgroup：默认组。如果此用户发送的查询没有匹配的规则，则它生成的流量将发送到指定的主机组transaction_persistent：如果为与MysqL客户端连接到Proxysql的用户设置了此选项，则在主机组内启动的事务将保留在该主机组内，而不管其他任何规则。例如，一个事务中存在读与写 *** 作，如果不指定该选项，可能会把读与写请求分发到不同的主机上，造成数据不一致。

（六）故障转移(failover)测试

在上一节，我们已经配置了：

组：写组、备用写组、读组、离线组。并且读组最多只有1台server；MysqL Server:配置了3台Server，并且将其放入到了写组中；监控信息：用户信息

此时，Proxysql已经具备故障转移的能力了，我们进行测试一下。

STEP1：现在的配置如下，192.168.10.13主机是写节点，其它2个节点是备用写节点：

MysqL_serve在memory层r的配置信息MysqL3 rows sec)加载到RUNTIME后，由于组定义中最多只有1个写节点，其余的主节点移动到备用写组里面MysqL runtime_MysqL_servers;2 0.01 sec)

使用Proxysql来访问MyQSL集群，发现可以支持读写

使用Proxysql 6033端口访问MysqL数据库use testdb 通过主机名，额可以看到，我们访问到的是写节点MysqL@@hostname----------+@@hostname | mgr-node3 sec) 可以这次插入、查询数据MysqLinto test01 a test01;--+------+| ID | name | | a 0.00 sec)

STEP2：关闭写节点

# 直接关闭主机[root@mgr-node3 ~]# reboot

Connection closed by foreign host.disconnected from remote host(mgr-node3) at 19:31.Type `help' to learn how to use Xshell prompt.

[c:\~]$ -- 需要注意的是，以前连接在主节点上的会话会断开，不会转移到新的主节点，很正常，Oracle也不会 MysqL> select * from test01; ERROR 2013 (HY000): Lost connection to MysqL server during query

STEP3：查看是否会有备用写节点转为写节点，可以看到192.168.10.12服务器已经转为写节点，而已经关闭的192.168.10.13服务器已经进入离线组。

MysqL>   from runtime_MysqL_servers;+--------------+---------------+------+-----------+---------+--------+-------------+-----------------+---------------------+---------+----------------+---------+| hostgroup_ID | hostname      | port | gtID_port | status  | weight | compression | max_connections | max_replication_lag | use_ssl | max_latency_ms | comment |+--------------+---------------+------+-----------+---------+--------+-------------+-----------------+---------------------+---------+----------------+---------+| 2            | 192.168.10.11 | 3306 | 0         | ONliNE  | 1      | 0           | 1000            | 0                   | 0       | 0              |         || 1            | 10.12 | 4            | 10.13 | 0         | SHUNNED | 0              |         |+--------------+---------------+------+-----------+---------+--------+-------------+-----------------+---------------------+---------+----------------+---------+3 rows in set (0.00 sec)

STEP4：再次使用Proxysql来访问MyQSL集群，发现可以支持读写，业务不会因主节点的改变而受影响。

]# MysqL 通过主机名，额可以看到，我们访问到的是新的写节点MysqL-node2 2,1)">b0.00 sec)

通过上面的测试，可以看到，MGR结合Proxysql已经可以实现业务的自动故障转移。

接下来，我们开始研究Proxysql的读写分离功能。

总结

以上是内存溢出为你收集整理的使用ProxySQL实现MySQL Group Replication的故障转移、读写分离（一）全部内容，希望文章能够帮你解决使用ProxySQL实现MySQL Group Replication的故障转移、读写分离（一）所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。