一、三节点MGR集群的安装部署
1. 安装准备
准备好下面三台服务器:
IP | 端口 | 角色 |
---|---|---|
192.168.150.21 | 3306 | mgr1 |
192.168.150.22 | 3306 | mgr2 |
192.168.150.23 | 3306 | mgr3 |
配置hosts解析
bash
# cat >> /etc/hosts << EOF
192.168.150.21 mgr1
192.168.150.22 mgr2
192.168.150.23 mgr3
EOF
2. 启动MySQL Server
首先修改 /etc/my.cnf.d/mysql-server.cnf 配置文件,增加:
bash
#/etc/my.cnf*.d/mysql-server.cnf
[mysqld]
...
#开启GTID,必须开启
gtid_mode = ON
#强制GTID的一致性
enforce_gtid_consistency = ON
#binlog格式,MGR要求必须是ROW,不过就算不是MGR,也最好用
binlog_format = row
#server-id必须是唯一的
server-id = 1
#MGR使用乐观锁,所以官网建议隔离级别是RC,减少锁粒度
transaction_isolation = READ-COMMITTED
#因为集群会在故障恢复时互相检查binlog的数据,
#所以需要记录下集群内其他服务器发过来已经执行过的binlog,按GTID来区分是否执行过.
log-slave-updates = 1
#binlog校验规则,5.6之后的高版本是CRC32,低版本都是NONE,但是MGR要求使用NONE
binlog_checksum = NONE
#基于安全的考虑,MGR集群要求复制模式要改成slave记录记录到表中,不然就报错
master_info_repository = TABLE
#同上配套
relay_log_info_repository = TABLE
#组复制设置#记录事务的算法,官网建议设置该参数使用 XXHASH64 算法
transaction_write_set_extraction = XXHASH64
#相当于此GROUP的名字,是UUID值,不能和集群内其他GTID值的UUID混用,可用uuidgen来生成一个新的,
#主要是用来区分整个内网里边的各个不同的GROUP,而且也是这个group内的GTID值的UUID
loose-group_replication_group_name = '5dbabbe6-8050-49a0-9131-1de449167446'
#IP地址白名单,默认只添加127.0.0.1,不会允许来自外部主机的连接,按需安全设置
loose-group_replication_ip_whitelist = '127.0.0.1/8,192.168.0.0/16'
#是否随服务器启动而自动启动组复制,不建议直接启动,怕故障恢复时有扰乱数据准确性的特殊情况
loose-group_replication_start_on_boot = OFF
#本地MGR的IP地址和端口,host:port,是MGR的端口,不是数据库的端口
loose-group_replication_local_address = '192.168.150.21:33081'
#需要接受本MGR实例控制的服务器IP地址和端口,是MGR的端口,不是数据库的端口
loose-group_replication_group_seeds = '192.168.150.21:33081,192.168.150.22:33081,192.168.150.23:33081'
#开启引导模式,添加组成员,用于第一次搭建MGR或重建MGR的时候使用,只需要在集群内的其中一台开启,
loose-group_replication_bootstrap_group = OFF
#是否启动单主模式,如果启动,则本实例是主库,提供读写,其他实例仅提供读,如果为off就是多主模式了
loose-group_replication_single_primary_mode = ON
#多主模式下,强制检查每一个实例是否允许该操作,如果不是多主,可以关闭
loose-group_replication_enforce_update_everywhere_checks = on
将mgr1的文件发送到mgr2和mgr3, 修改server-id和loose-group_replication_local_address的相关值
bash
# scp /etc/my.cnf.d/mysql-server.cnf mgr2:/etc/my.cnf.d/
# scp /etc/my.cnf.d/mysql-server.cnf mgr2:/etc/my.cnf.d/
3.安装插件(三台机器都要安装)
利用这份配置文件,重启MySQL Server,之后就应该能看到已经成功加载 group_replicaiton
插件了:
bash
[root@mgr1 ~]# mysql -e "show plugins;" | grep "group_replication"
如果没正确加载,也可以登入MySQL Server自行手动加载这个plugin:
bash
[root@mgr1 ~]# mysql -e "install plugin group_replication soname 'group_replication.so'"
[root@mgr1 ~]# mysql -e "show plugins;" | grep "group_replication"
group_replication ACTIVE GROUP REPLICATION group_replication.so GPL
4.配置账号(三台机器都要配置)
接下来,创建MGR服务专用账户,并准备配置MGR服务通道:
bash
#每个节点都要单独创建用户,因此这个操作没必要记录binlog并复制到其他节点
mysql> set session sql_log_bin=0;
mysql> create user repl@'%' identified with mysql_native_password by 'repl';
mysql> GRANT BACKUP_ADMIN, REPLICATION SLAVE ON *.* TO `repl`@`%`;
#创建完用户后继续启用binlog记录
mysql> set session sql_log_bin=1;
#配置MGR服务通道
#通道名字 group_replication_recovery 是固定的,不能修改
mysql> CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='repl' FOR CHANNEL 'group_replication_recovery';
5.启动MGR单主模式
在mgr1节点,启动引导,进入mysql服务端
bash
mysql> SET GLOBAL group_replication_bootstrap_group = ON;
mysql> START GROUP_REPLICATION;
mysql> SET GLOBAL group_replication_bootstrap_group = OFF;
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 | 3460f111-9314-11ee-a532-000c295df6cf | mgr1 | 3306 | ONLINE | PRIMARY | 8.0.30 | XCom |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
1 row in set (0.01 sec)
在mgr2\mgr3节点,进入mysql服务端
bash
mysql> START GROUP_REPLICATION;
mysql> SELECT * FROM performance_schema.replication_group_members;
再次查看MGR节点状态:
bash
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 | 3460f111-9314-11ee-a532-000c295df6cf | mgr1 | 3306 | ONLINE | PRIMARY | 8.0.30 | XCom |
| group_replication_applier | 52854f96-9314-11ee-8821-000c29ced34f | mgr2 | 3306 | ONLINE | SECONDARY | 8.0.30 | XCom |
| group_replication_applier | 70fa199f-9314-11ee-a8eb-000c29f957d2 | mgr3 | 3306 | ONLINE | SECONDARY | 8.0.30 | XCom |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
3 rows in set (0.00 sec)
看到上面这个集群共有3个节点处于ONLINE状态,其中 192.168.150.21 是 PRIMARY 节点,其余两个都是 SECONDARY 节点,也就是说当前这个集群采用 单主 模式。如果采用多主模式,则所有节点的角色都是 PRIMARY。
6. 向MGR集群中写入数据
接下来我们连接到 PRIMARY 节点,创建测试库表并写入数据:
bash
mysql> create database mgr;
mysql> use mgr;
mysql> create table t1(c1 int unsigned not null primary key);
mysql> insert into t1 select rand()*10240;
mysql> select * from t1;
+------+
| c1 |
+------+
| 442 |
+------+
再连接到其中一个 SECONDARY 节点,查看刚刚在 PRIMARY 写入的数据是否可以看到:
bash
mysql> select @@hostname;
+------------+
| @@hostname |
+------------+
| mgr2 |
+------------+
1 row in set (0.00 sec)
mysql> select * from mgr.t1;
+-----+
| c1 |
+-----+
| 442 |
+-----+
1 row in set (0.01 sec)
确认可以读取到该数据。
到这里,就完成了三节点MGR集群的安装部署
二、 MGR管理维护
现在有个三节点的MGR集群:
bash
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 | 3460f111-9314-11ee-a532-000c295df6cf | mgr1 | 3306 | ONLINE | PRIMARY | 8.0.30 | XCom |
| group_replication_applier | 52854f96-9314-11ee-8821-000c29ced34f | mgr2 | 3306 | ONLINE | SECONDARY | 8.0.30 | XCom |
| group_replication_applier | 70fa199f-9314-11ee-a8eb-000c29f957d2 | mgr3 | 3306 | ONLINE | SECONDARY | 8.0.30 | XCom |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
3 rows in set (0.00 sec)
1. 切换主节点
当主节点需要进行维护时,或者执行滚动升级时,就可以对其进行切换,将主节点切换到其他节点。
在命令行模式下,可以使用 group_replication_set_as_primary() 这个udf实现切换,例如:
-- 将Primary角色切换到第二个节点
在mgr1上做
bash
mysql> select group_replication_set_as_primary('52854f96-9314-11ee-8821-000c29ced34f');
+--------------------------------------------------------------------------+
| group_replication_set_as_primary('52854f96-9314-11ee-8821-000c29ced34f') |
+--------------------------------------------------------------------------+
| Primary server switched to: 52854f96-9314-11ee-8821-000c29ced34f |
+--------------------------------------------------------------------------+
1 row in set (0.02 sec)
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 | 3460f111-9314-11ee-a532-000c295df6cf | mgr1 | 3306 | ONLINE | SECONDARY | 8.0.30 | XCom |
| group_replication_applier | 52854f96-9314-11ee-8821-000c29ced34f | mgr2 | 3306 | ONLINE | PRIMARY | 8.0.30 | XCom |
| group_replication_applier | 70fa199f-9314-11ee-a8eb-000c29f957d2 | mgr3 | 3306 | ONLINE | SECONDARY | 8.0.30 | XCom |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
3 rows in set (0.00 sec)
顺便提一下,在MySQL 5.7版本中,只能通过重启以实现主节点的自动切换,不能手动切换。从这个角度来说,如果想要使用MGR,最好是选择MySQL 8.0版本,而不要使用5.7版本。
2. 切换单主/多主模式
在命令行模式下,可以调用 group_replication_switch_to_single_primary_mode()
和 group_replication_switch_to_multi_primary_mode()
来切换单主/多主模式。
bash
#直接调用函数即可
mysql> select group_replication_switch_to_multi_primary_mode();
+--------------------------------------------------+
| group_replication_switch_to_multi_primary_mode() |
+--------------------------------------------------+
| Mode switched to multi-primary successfully. |
+--------------------------------------------------+
1 row in set (1.01 sec)
#查看各节点状态
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 | 3460f111-9314-11ee-a532-000c295df6cf | mgr1 | 3306 | ONLINE | PRIMARY | 8.0.30 | XCom |
| group_replication_applier | 52854f96-9314-11ee-8821-000c29ced34f | mgr2 | 3306 | ONLINE | PRIMARY | 8.0.30 | XCom |
| group_replication_applier | 70fa199f-9314-11ee-a8eb-000c29f957d2 | mgr3 | 3306 | ONLINE | PRIMARY | 8.0.30 | XCom |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
3 rows in set (0.00 sec)
#切换成单主模式时可以指定某个节点的 server_uuid,如果不指定则会根据规则自动选择一个新的主节点
#在这里,我选择了指定mgr3节点作为新主
mysql> select group_replication_switch_to_single_primary_mode('70fa199f-9314-11ee-a8eb-000c29f957d2');
+-----------------------------------------------------------------------------------------+
| group_replication_switch_to_single_primary_mode('70fa199f-9314-11ee-a8eb-000c29f957d2') |
+-----------------------------------------------------------------------------------------+
| Mode switched to single-primary successfully. |
+-----------------------------------------------------------------------------------------+
1 row in set (0.02 sec)
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 | 3460f111-9314-11ee-a532-000c295df6cf | mgr1 | 3306 | ONLINE | SECONDARY | 8.0.30 | XCom |
| group_replication_applier | 52854f96-9314-11ee-8821-000c29ced34f | mgr2 | 3306 | ONLINE | SECONDARY | 8.0.30 | XCom |
| group_replication_applier | 70fa199f-9314-11ee-a8eb-000c29f957d2 | mgr3 | 3306 | ONLINE | PRIMARY | 8.0.30 | XCom |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
3 rows in set (0.00 sec)
3. 添加新节点
接下来我们演示如何向MGR集群中添加一个新节点。
首先,要先完成MySQL Server初始化,创建好MGR专用账户、设置好MGR服务通道等前置工作。
接下来,直接执行命令 start group_replication
启动MGR服务即可,新增的节点会进入分布式恢复这个步骤,它会从已有节点中自动选择一个作为捐献者(donor),并自行决定是直接读取binlog进行恢复,还是利用Clone进行全量恢复。
如果是已经在线运行一段时间的MGR集群,有一定存量数据,这时候新节点加入可能会比较慢,建议手动利用Clone进行一次全量复制。还记得前面创建MGR专用账户时,给加上了 BACKUP_ADMIN 授权吗,这时候就派上用场了,Clone需要用到这个权限。
下面演示如何利用Clone进行一次全量数据恢复,假定要新增的节点是 192.168.150.24 (给它命名为 mgr4)。
bash
#在mgr4上设置捐献者
#为了降低对Primary节点的影响,建议选择其他Secondary节点
mysql> set global clone_valid_donor_list='192.168.150.24:3306';
#停掉mgr服务(如果有的话),关闭super_read_only模式,然后开始复制数据
#注意这里要填写的端口是3306(MySQL正常服务端口),而不是33061这个MGR服务专用端口
mysql> stop group_replication; set global super_read_only=0; clone INSTANCE FROM repl@192.168.150.21:3306 IDENTIFIED BY 'repl';
全量复制完数据后,该节点会进行一次自动重启。重启完毕后,再次确认 group_replication_group_name
、group_replication_local_address
、group_replication_group_seeds
这些选项值是否正确,如果没问题,执行 start group_replication
后,该节点应该就可以正常加入集群了。
4. 删除节点
在命令行模式下,一个节点想退出MGR集群,直接执行 stop group_replication
即可,如果这个节点只是临时退出集群,后面还想加回集群,则执行 start group_replication
即可自动再加入。而如果是想彻底退出集群,则停止MGR服务后,执行 reset master; reset slave all;
重置所有复制(包含MGR)相关的信息就可以了。
5. 异常退出的节点重新加回
当节点因为网络断开、实例crash等异常情况与MGR集群断开连接后,这个节点的状态会变成 UNREACHABLE ,待到超过 group_replication_member_expel_timeout
+ 5 秒后,集群会踢掉该节点。等到这个节点再次启动并执行 start group_replication
,正常情况下,该节点应能自动重新加回集群。
6. 重启MGR集群
正常情况下,MGR集群中的Primary节点退出时,剩下的节点会自动选出新的Primary节点。当最后一个节点也退出时,相当于整个MGR集群都关闭了。这时候任何一个节点启动MGR服务后,都不会自动成为Primary节点,需要在启动MGR服务前,先设置 group_replication_bootstrap_group=ON
,使其成为引导节点,再启动MGR服务,它才会成为Primary节点,后续启动的其他节点也才能正常加入集群。可自行测试,这里不再做演示。
P.S,第一个节点启动完毕后,记得重置选项 group_replication_bootstrap_group=OFF
,避免在后续的操作中导致MGR集群分裂。
三、 MGR状态监控
MGR和传统主从复制类似,在运行过程中主要关注各节点的运行状态,以及Secondary节点的事务是否有延迟。本文介绍如何监控MGR节点状态、事务状态等。
1. 节点状态监控
通过查询 performance_schema.replication_group_members
表即可知道MGR各节点的状态:
bash
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 | 3460f111-9314-11ee-a532-000c295df6cf | mgr1 | 3306 | ONLINE | SECONDARY | 8.0.30 | XCom |
| group_replication_applier | 52854f96-9314-11ee-8821-000c29ced34f | mgr2 | 3306 | ONLINE | SECONDARY | 8.0.30 | XCom |
| group_replication_applier | 70fa199f-9314-11ee-a8eb-000c29f957d2 | mgr3 | 3306 | ONLINE | PRIMARY | 8.0.30 | XCom |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
3 rows in set (0.01 sec)
输出结果中主要几个列的解读如下:
-
MEMBER_ID 列值就是各节点的 server_uuid,用于唯一标识每个节点,在命令行模式下,调用 udf 时传入 MEMBER_ID 以指定各节点。
-
MEMBER_ROLE 表示各节点的角色,如果是 PRIMARY 则表示该节点可接受读写事务,如果是 SECONDARY 则表示该节点只能接受只读事务。如果只有一个节点是 PRIMARY,其余都是 SECONDARY,则表示当前处于 单主模式 ;如果所有节点都是 PRIMARY,则表示当前处于 多主模式。
-
MEMBER_STATE
表示各节点的状态,共有几种状态:ONLINE、RECOVERING、OFFLINE、ERROR、UNREACHABLE 等,下面分别介绍几种状态。
-
ONLINE,表示节点处于正常状态,可提供服务。
-
RECOVERING,表示节点正在进行分布式恢复,等待加入集群,这时候有可能正在从donor节点利用clone复制数据,或者传输binlog中。
-
OFFLINE,表示该节点当前处于离线状态。提醒,在正要加入或重加入集群时,可能也会有很短瞬间的状态显示为 OFFLINE。
-
ERROR,表示该节点当前处于错误状态,无法成为集群的一员。当节点正在进行分布式恢复或应用事务时,也是有可能处于这个状态的。当节点处于ERROR状态时,是无法参与集群事务裁决的。节点正在加入或重加入集群时,在完成兼容性检查成为正式MGR节点前,可能也会显示为ERROR状态。
-
UNREACHABLE,当组通信消息收发超时时,故障检测机制会将本节点标记为怀疑状态,怀疑其可能无法和其他节点连接,例如当某个节点意外断开连接时。当在某个节点上看到其他节点处于 UNREACHABLE 状态时,有可能意味着此时部分节点发生了网络分区,也就是多个节点分裂成两个或多个子集,子集内的节点可以互通,但子集间无法互通。
-
当节点的状态不是 ONLINE 时,就应当立即发出告警并检查发生了什么。
在节点状态发生变化时,或者有节点加入、退出时,表 performance_schema.replication_group_members
的数据都会更新,各节点间会交换和共享这些状态信息,因此可以在任意节点查看。
2. MGR事务状态监控
另一个需要重点关注的是Secondary节点的事务状态,更确切的说是关注待认证事务及待应用事务队列大小。
可以执行下面的命令查看当前除了 PRIMARY 节点外,其他节点的 trx_tobe_certified
或 relaylog_tobe_applied
值是否较大:
bash
mysql> SELECT MEMBER_ID AS id, COUNT_TRANSACTIONS_IN_QUEUE AS trx_tobe_certified, COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE AS relaylog_tobe_applied, COUNT_TRANSACTIONS_CHECKED AS trx_chkd, COUNT_TRANSACTIONS_REMOTE_APPLIED AS trx_done, COUNT_TRANSACTIONS_LOCAL_PROPOSED AS proposed FROM performance_schema.replication_group_member_stats;
+--------------------------------------+--------------------+-----------------------+----------+----------+----------+
| id | trx_tobe_certified | relaylog_tobe_applied | trx_chkd | trx_done | proposed |
+--------------------------------------+--------------------+-----------------------+----------+----------+----------+
| 3460f111-9314-11ee-a532-000c295df6cf | 0 | 0 | 3 | 3 | 3 |
| 52854f96-9314-11ee-8821-000c29ced34f | 0 | 0 | 3 | 4 | 0 |
| 70fa199f-9314-11ee-a8eb-000c29f957d2 | 0 | 0 | 3 | 3 | 0 |
+--------------------------------------+--------------------+-----------------------+----------+----------+----------+
3 rows in set (0.01 sec)
其中,relaylog_tobe_applied
的值表示远程事务写到relay log后,等待回放的事务队列,trx_tobe_certified
表示等待被认证的事务队列大小,这二者任何一个值大于0,都表示当前有一定程度的延迟。
还可以通过关注上述两个数值的变化,看看两个队列是在逐步加大还是缩小,据此判断Primary节点是否"跑得太快"了,或者Secondary节点是否"跑得太慢"。
多提一下,在启用流控(flow control)时,上述两个值超过相应的阈值时(group_replication_flow_control_applier_threshold 和 group_replication_flow_control_certifier_threshold 默认阈值都是 25000),就会触发流控机制
3. 其他监控
另外,也可以查看接收到的事务和已执行完的事务之间的差距来判断:
bash
mysql> SELECT RECEIVED_TRANSACTION_SET FROM performance_schema.replication_connection_status WHERE channel_name = 'group_replication_applier' UNION ALL SELECT variable_value FROM performance_schema.global_variables WHERE variable_name = 'gtid_executed'\G
*************************** 1. row ***************************
RECEIVED_TRANSACTION_SET: 5dbabbe6-8050-49a0-9131-1de449167446:1-6
*************************** 2. row ***************************
RECEIVED_TRANSACTION_SET: 5dbabbe6-8050-49a0-9131-1de449167446:1-6
2 rows in set (0.01 sec)
四、利用MySQL Router构建读写分离MGR集群
本文介绍如何在MGR集群前端部署MySQL Router以实现读写分离、读负载均衡,以及故障自动转移。
MySQL Router是一个轻量级的中间件,它采用多端口的方案实现读写分离以及读负载均衡,而且同时支持mysql和mysql x协议。
建议把MySQL Router部署在应用服务器上,每个应用服务器都部署一套,这样应用程序可以直接连接本机IP,连接的效率更高,而且后端数据库发生变化时,程序端也无需修改IP配置。
1. 部署MySQL Router
MySQL Router第一次启动时要先初始化:
bash
[root@proxy ~]# yum install mysql-router-community-8.0.35-1.el7.x86_64.rpm
2. 启动mysqlrouter服务
这就初始化完毕了,按照上面的提示,直接启动 mysqlrouter 服务即可
bash
[root@proxy ~]# systemctl enable --now mysqlrouter.service
Created symlink from /etc/systemd/system/multi-user.target.wants/mysqlrouter.service to /usr/lib/systemd/system/mysqlrouter.service.
[root@proxy ~]# ps -ef | grep -v grep | grep mysqlrouter
mysqlro+ 1461 1 0 11:38 ? 00:00:00 /usr/bin/mysqlrouter
可以看到 mysqlrouter 服务正常启动了。
mysqlrouter 初始化时自动生成的配置文件是 /etc/mysqlrouter/mysqlrouter.conf
,主要是关于R/W、RO不同端口的配置,例如:
bash
cat >> /etc/mysqlrouter/mysqlrouter.conf << EOF
[routing:write]
bind_address = 192.168.150.24
bind_port = 8001
mode = read-write
destinations = 192.168.150.21:3306
[routing:blanace]
bind_address = 192.168.150.24
bind_port = 8002
mode = read-only
destinations = 192.168.150.22:3306,192.168.150.23:3306
EOF
[root@proxy ~]# systemctl restart mysqlrouter.service
3. 确认读写分离效果
创建用户
bash
mysql> create user admin@'192.168.150.%' identified with mysql_native_password by '123456';
Query OK, 0 rows affected (0.00 sec)
mysql> grant all on *.* to admin@'192.168.150.%';
Query OK, 0 rows affected (0.01 sec)
现在,用客户端连接到6446(读写)端口,确认连接的是PRIMARY节点:
bash
[root@mgr1 ~]# mysql -uadmin -p123456 -h192.168.150.24 -P8001
Enter password:
...
#记住下面几个 MEMBER_ID
mysql> select MEMBER_ID,MEMBER_ROLE from performance_schema.replication_group_members;
+--------------------------------------+-------------+
| MEMBER_ID | MEMBER_ROLE |
+--------------------------------------+-------------+
| 3460f111-9314-11ee-a532-000c295df6cf | SECONDARY |
| 52854f96-9314-11ee-8821-000c29ced34f | SECONDARY |
| 70fa199f-9314-11ee-a8eb-000c29f957d2 | PRIMARY |
+--------------------------------------+-------------+
3 rows in set (0.00 sec)
mysql> select @@server_uuid;
+--------------------------------------+
| @@server_uuid |
+--------------------------------------+
| 3460f111-9314-11ee-a532-000c295df6cf |
+--------------------------------------+
1 row in set (0.00 sec)
# 确实是连接的PRIMARY节点
同样地,连接8002(只读)端口,确认连接的是SECONDARY节点:
bash
[root@mgr2 ~]# mysql -uadmin -p123456 -h192.168.150.24 -P8002
Enter password:
...
mysql> select @@server_uuid;
+--------------------------------------+
| @@server_uuid |
+--------------------------------------+
| 52854f96-9314-11ee-8821-000c29ced34f |
+--------------------------------------+
1 row in set (0.00 sec)
# 确实是连接的SECONDARY节点
4. 确认只读负载均衡效果
MySQL Router连接读写节点(Primary节点)默认的策略是 first-available ,即只连接第一个可用的节点。Router连接只读节点(Secondary节点)默认的策略是 round-robin-with-fallback,会在各个只读节点间轮询。
保持8002端口原有的连接不退出,继续新建到8002端口的连接,查看 server_uuid ,这时应该会发现读取到的是其他只读节点的值,因为 mysqlrouter 的读负载均衡机制是在几个只读节点间自动轮询。在默认的 round-robin-with-fallback 策略下,只有当所有只读节点都不可用时,只读请求才会打到PRIMARY节点上。
bash
[root@mgr3 ~]# mysql -uadmin -p123456 -h192.168.150.24 -P8002
mysql> select @@server_uuid;
+--------------------------------------+
| @@server_uuid |
+--------------------------------------+
| 70fa199f-9314-11ee-a8eb-000c29f957d2 |
+--------------------------------------+
1 row in set (0.00 sec)