一、初识MGR
MGR(全称 MySQL Group Replication 【MySQL 组复制】)是Oracle MySQL于2016年12月发布MySQL 5.7.17推出的一个全新高可用(动画演示)和高扩展的解决方案。具备以下特性:
- 高一致性,基于原生复制及Paxos协议的组复制技术,并以插件的方式提供,提供一致数据安全保证;
- 高容错性,只要不是大多数节点坏掉就可以继续工作,有自动检测机制,当不同节点产生资源争用冲突时,不会出现错误,按照先到者优先原则进行处理,并且内置了自动化脑裂防护机制;
- 高扩展性,节点的新增和移除都是自动的,新节点加入后,会自动从其他节点上同步状态,直到新节点和其他节点保持一致,如果某节点被移除了,其他节点自动更新组信息,自动维护新的组信息;
- 高灵活性,有单主模式(图1)和多主模式(图2),单主模式下,会自动选主,所有更新操作都在主上进行;多主模式下,所有server都可以同时处理更新操作。
二、技术演进
2.1 主从复制
传统MySQL复制默认提供了一种简单的主从复制方法,这种架构有一个主,以及一个或者多个从,当主节点执行提交事务,然后异步的方式发送到其他从节点,从库重新执行relay log日志内容达到主副本一致的目的,在默认情况下集群所有节点数据都是一致的。
官方文档:https://dev.mysql.com/doc/refman/8.0/en/replication-howto-slaveinit.html
实践文档:http://smallcode.cn/post/30

2.2 半同步复制
异步复制存在一定的数据丢失风险,MySQL又在5.6版本中推出半同步复制,在同步数据协议中添加了一个同步操作,这样意味主节点在commit操作,需要确认最少一个从节点确认接收到并且返回ACK,只有这样主节点才能正确提交数据。
官方文档:https://dev.mysql.com/doc/refman/5.7/en/replication-semisync.html

2.3 组复制
MySQL MGR 集群最少3个server节点共同组成的分布式集群,一种share-nothing复制方案,每个server节点都有完整的副本。
官方文档:https://dev.mysql.com/doc/refman/8.0/en/group-replication.html

- 单主模式,客户端故障转移
五个服务器实例 S1、S2、S3、S4 和 S5 部署为一个互连组。 服务器 S1 是主服务器。 写客户端正在与服务器 S1 通信,而读客户端正在与服务器 S4 通信。 然后服务器 S1 失败,中断与写入客户端的通信。 然后服务器 S2 接管作为新的主服务器,写入客户端现在与服务器 S2 通信。

- 多主模式,客户端故障转移
五个服务器实例 S1、S2、S3、S4 和 S5 部署为一个互连组。 所有服务器都是主服务器。 写客户端正在与服务器 S1 和 S2 通信,而读客户端正在与服务器 S4 通信。 然后服务器 S1 失败,中断与它的写入客户端的通信。 此客户端重新连接到服务器 S3。

多主模式设计脑裂,问题较多,出错概率也比单主高出很多,此处仅整理文档不试验。
三、特性
3.1 故障检测
组复制自带提供一种故障检测机制,这个机制能报告哪个组成员是无响应的,并且如何判断该成员是否排除集群组。在组复制中故障检测是一种分布式服务。假设服务器A在预定时间段内未收到来自服务器B的消息,如果组内其他成员也同样未收到来自服务器B的消息,那么确认判断B发生故障,这样由其他成员判定将失联组成员从集群中剔除。
此时服务器B与其他服务节点都无法联系。由于无法达成最小仲裁成员数,处于独立状态,无法对外提供服务。
3.2 容错
MySQL组复制构建在Paxos分布式算法基础上实现的,以提供不同server之间的分布式协调。因此,它需要大多数server处于活动状态以达到仲裁成员数,从而做出决定。这对系统可以容忍的不影响其自身及其整体功能的故障数量有直接影响。容忍f个故障所需的server数量(n)n = 2 * f + 1。
实践中,这意味着为了容忍一个故障,组必须有三个server。如果一个服务器故障, 仍然有两个服务器形成大多数(三分之二)来允许系统自动地继续运行。但是,如果第二个server意外地宕掉,则该组锁定(只有一个server),因为没有达到多数可以达成选举(不能自己选举自己)。以下是说明上述公式的小表:
3.3 成员管理
组复制以组视图(Group View,后续简称视图)为基础来进行成员管理,视图一般在Group在一段时间内的成员状态,如果这段时间没有成员变化,也就是说没有成员的加入和退出,一旦有成员加入或者退出组,则视图就发生变化,并且使用视图ID(view id)进行跟踪变化区分先后时间,下面我们来看一张图演示一下:
序号部分,初始化时,第一个视图的序号从1开始,成员只有引导主一个,为进行初始化节点,以后出现的任何成员的加入和退出这个序号都需要增加1,可以通过performance_schema系统库下的replication_group_member_stats表中查询当前视图。
四、手动安装过程
了解任何一个新技术从部署开始,安装比较简单,我们准备如下三个测试节点:
19.80.0.2
19.80.0.3
19.80.0.4
安装版本均为最新版本8.0.24,将安装包解压后进行初始化:
su - mysql
wget http://mirrors.ustc.edu.cn/mysql-ftp/Downloads/MySQL-8.0/mysql-8.0.24-linux-glibc2.12-x86_64.tar
tar -xf mysql-8.0.24-linux-glibc2.12-x86_64.tar
cd mysql-8.0.24-linux-glibc2.12-x86_64
# 创建配置文件和数据目录
mkdir conf data
初始化数据库并且启动
./bin/mysqld --initialize --datadir=/home/mysql/mysql-8.0.24-linux-glibc2.12-x86_64/data --basedir=/home/mysql/mysql-8.0.24-linux-glibc2.12-x86_64
./bin/mysqld_safe --defaults-file=conf/my.cnf &
4.1 通用配置说明
my.cnf文件内容 参考https://dev.mysql.com/doc/refman/8.0/en/group-replication-configuring-instances.html
[mysql]
port = 3306
default-character-set = utf8mb4
[mysqld]
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
datadir = /var/lib/mysql
secure-file-priv= NULL
lower_case_table_names=1
##########################
# character set
##########################
character-set-server = utf8mb4
init_connect='SET collation_connection = utf8mb4_general_ci'
init_connect='SET NAMES utf8mb4'
character-set-server=utf8mb4
collation-server=utf8mb4_general_ci
skip-character-set-client-handshake
#另外两个节点分别是3和4
server_id=2
gtid_mode=ON
enforce_gtid_consistency=ON
log_bin=binlog
log_slave_updates=ON
binlog_format=ROW
transaction_write_set_extraction=XXHASH64
binlog-ignore-db = mysql
binlog_ignore_db = information_schema
binlog_ignore_db = performation_schema
binlog_ignore_db = sys
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
#####################################################
# 注意:此处有坑!!
# 以下配置项在初始化数据库之前先注释,
# 等数据库初始化之后,mysql库表创建好了再放开
# 否则会各种报错无法启动!
#####################################################
# master_info_repository=TABLE
# relay_log_info_repository=TABLE
# plugin_load_add='group_replication.so'
# loose-group_replication_group_name='cf4eeddf-93a3-4fbd-a36c-915234ec1b27'
# loose-group_replication_start_on_boot=off
# #另外两个节点分别是'19.80.0.3:43061'和'19.80.0.4:43061'
# loose-group_replication_local_address='19.80.0.2:43061'
# loose-group_replication_group_seeds='19.80.0.2:33061,19.80.0.3:33061,19.80.0.4:33061'
# loose-group_replication_ip_whitelist='19.80.0.2/24,19.80.0.3/24,19.80.0.4/24,127.0.0.1/8'
# loose-group_replication_bootstrap_group=off
4.2 单主模式部署
4.2.1 引导节点初始化
创建用户和安装插件
mysql> SET SQL_LOG_BIN=0;
Query OK, 0 rows affected (0.00 sec)
mysql> CREATE USER porter@'%' IDENTIFIED BY '123456';
Query OK, 0 rows affected (0.01 sec)
# 新版使用 caching_sha2_password 可能会节点长时间RECOVERING 状态,验证不了身份;
mysql> alter USER porter@'%' IDENTIFIED WITH sha256_password BY '123456';
Query OK, 0 rows affected (0.01 sec)
mysql> GRANT REPLICATION SLAVE ON *.* TO porter@'%';
Query OK, 0 rows affected (0.00 sec)
mysql> GRANT BACKUP_ADMIN ON *.* TO porter@'%';
Query OK, 0 rows affected (0.00 sec)
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)
mysql> SET SQL_LOG_BIN=1;
Query OK, 0 rows affected (0.00 sec)
mysql> CHANGE REPLICATION SOURCE TO SOURCE_USER='porter', SOURCE_PASSWORD='123456' FOR CHANNEL 'group_replication_recovery';
Query OK, 0 rows affected, 2 warnings (0.05 sec)
mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';
mysql> SHOW PLUGINS;
+---------------------------------+----------+--------------------+----------------------+---------+
| Name | Status | Type | Library | License |
+---------------------------------+----------+--------------------+----------------------+---------+
| group_replication | ACTIVE | GROUP REPLICATION | group_replication.so | GPL |
+---------------------------------+----------+--------------------+----------------------+---------+
启动引导节点
mysql> SET GLOBAL group_replication_bootstrap_group=ON;
Query OK, 0 rows affected (0.00 sec)
mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected, 1 warning (2.33 sec)
mysql> SET GLOBAL group_replication_bootstrap_group=OFF;
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 75624320-66a3-4fc7-bfb3-404d4551291f | 19-80-0-2 | 3306 | ONLINE | PRIMARY | 8.0.24 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
4.2.2 加入从节点
mysql> SET SQL_LOG_BIN=0;
Query OK, 0 rows affected (0.00 sec)
mysql> CREATE USER porter@'%' IDENTIFIED BY '123456';
Query OK, 0 rows affected (0.01 sec)
# 新版使用 caching_sha2_password 可能会节点长时间RECOVERING 状态,验证不了身份;
mysql> alter USER porter@'%' IDENTIFIED WITH sha256_password BY '123456';
Query OK, 0 rows affected (0.01 sec)
mysql> GRANT REPLICATION SLAVE ON *.* TO porter@'%';
Query OK, 0 rows affected (0.03 sec)
mysql> GRANT BACKUP_ADMIN ON *.* TO porter@'%';
Query OK, 0 rows affected (0.00 sec)
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)
mysql> SET SQL_LOG_BIN=1;
Query OK, 0 rows affected (0.00 sec)
mysql> CHANGE REPLICATION SOURCE TO SOURCE_USER='porter', SOURCE_PASSWORD='123456' FOR CHANNEL 'group_replication_recovery';
Query OK, 0 rows affected, 2 warnings (0.05 sec)
mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected, 1 warning (3.33 sec)
# 检查状态
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 75624320-66a3-4fc7-bfb3-404d4551291f | 19-80-0-2 | 3306 | ONLINE | PRIMARY | 8.0.24 |
| group_replication_applier | 11ce1e85-2a99-4ab6-bbae-8bdb475228f2 | 19-80-0-3 | 3306 | ONLINE | SECONDARY | 8.0.24 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
2 rows in set (0.00 sec)
其他一个节点执行上述即可,执行完成后检查
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 75624320-66a3-4fc7-bfb3-404d4551291f | 19-80-0-2 | 3306 | ONLINE | PRIMARY | 8.0.24 |
| group_replication_applier | 11ce1e85-2a99-4ab6-bbae-8bdb475228f2 | 19-80-0-3 | 3306 | ONLINE | SECONDARY | 8.0.24 |
| group_replication_applier | d87fadf9-5cdc-45db-8cc9-5ed7d7d90106 | 19-80-0-4 | 3306 | ONLINE | SECONDARY | 8.0.24 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
3 rows in set (0.00 sec)
4.3 多主模式部署
多主模式和单主部署方式差不多,只在加入集群时多执行:
set global group_replication_single_primary_mode=off;
单主的都是ON。
4.3.1 引导节点初始化
mysql> set global group_replication_single_primary_mode=off;
Query OK, 0 rows affected (0.00 sec)
mysql> SET GLOBAL group_replication_bootstrap_group=ON;
Query OK, 0 rows affected (0.00 sec)
mysql> start group_replication;
Query OK, 0 rows affected, 1 warning (2.16 sec)
mysql> SET GLOBAL group_replication_bootstrap_group=OFF;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 75624320-66a3-4fc7-bfb3-404d4551291f | 19-80-0-2 | 3306 | ONLINE | PRIMARY | 8.0.24 |
+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+
1 row in set (0.00 sec)
4.3.2 加入其他节点
mysql> set global group_replication_single_primary_mode=off;
Query OK, 0 rows affected (0.00 sec)
mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected, 1 warning (3.26 sec)
mysql> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 75624320-66a3-4fc7-bfb3-404d4551291f | 19-80-0-2 | 3306 | ONLINE | PRIMARY | 8.0.24 |
| group_replication_applier | 11ce1e85-2a99-4ab6-bbae-8bdb475228f2 | 19-80-0-3 | 3306 | ONLINE | PRIMARY | 8.0.24 |
| group_replication_applier | d87fadf9-5cdc-45db-8cc9-5ed7d7d90106 | 19-80-0-4 | 3306 | ONLINE | PRIMARY | 8.0.24 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
3 rows in set (0.00 sec)
4.4 测试体验
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| sys |
+--------------------+
4 rows in set (0.00 sec)
mysql> create database test;
Query OK, 1 row affected (0.01 sec)
换任意其它节点查询
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| sys |
| test |
+--------------------+
5 rows in set (0.00 sec)
五、Docker安装部署
准备网络环境
docker network create --driver bridge --subnet 19.80.0.0/16 --gateway 19.80.0.1 netcolin
同样也是三台服务器:
19.80.0.2
19.80.0.3
19.80.0.4
准备要挂载的文件和目录
创建三个节点的配置文件分别对应三个容器的mysql配置文件,一定要把配置文件暴漏给宿主机,否则修改起来会比较麻烦,容器内部默认没有vi。
echo '# 配置文件内容请参考 4.1 通用配置说明' > /home/volumes/ds2/my.cnf
echo '# 配置文件内容请参考 4.1 通用配置说明' > /home/volumes/ds3/my.cnf
echo '# 配置文件内容请参考 4.1 通用配置说明' > /home/volumes/ds4/my.cnf
将三个节点的my.cnf分别配置好内容,参考4.1章节的说明,
server_id 分别设置为 2,3,4
group_replication_local_address 中的ip地址必须更换成对应的,端口保持一致。
其它配置项均保持一致,group_replication_group_name 必须一致。
拉镜像
docker pull mysql:latest
# 或者指定版本
docker pull mysql:8.0.27
启动容器
docker run -d -e MYSQL_ROOT_PASSWORD=123456 --net netcolin --ip 19.80.0.2 --name node2 -v /home/volumes/ds2/my.cnf:/etc/mysql/my.cnf mysql:8.0.27
docker run -d -e MYSQL_ROOT_PASSWORD=123456 --net netcolin --ip 19.80.0.3 --name node3 -v /home/volumes/ds3/my.cnf:/etc/mysql/my.cnf mysql:8.0.27
docker run -d -e MYSQL_ROOT_PASSWORD=123456 --net netcolin --ip 19.80.0.4 --name node4 -v /home/volumes/ds4/my.cnf:/etc/mysql/my.cnf mysql:8.0.27
确认三个节点全部已经启动,并且已经初始化,此时停止全部容器。
docker stop node2 node3 node4
停止容器是为了回过头来再次放开my.cnf中关于“天坑”那一段的注释行,原因就是MySQL8不给你破坏原则,初始化时配置文件不能有多余的设置,大家可以直接复制我下面这份也可以用,多余的设置注释掉了。
再次启动容器
docker start node2 node3 node4
引导节点初始化
本章节参考 4.2.1 引导节点初始化 , 创建同步账户,授权...最终执行 START GROUP_REPLICATION ; 启动组。此时如果报错,请确认配置文件中注释的代码是否放开。同时监控docker logs 上的日志, 根据具体log排查错误。
第一次启动组的过程称为引导。使用group_replication_bootstrap_group系统变量来引导一个组。引导程序只能由单个MySQL Server(这里指的是引导组的MySQL Server)执行一次。 这就是为什么group_replication_bootstrap_group系统变量不在my.cnf配置文件中持久化的原因。如果将其保存在配置文件中(group_replication_bootstrap_group=ON),则在重新启动组成员时, 组中的所有成员都将会尝试引导组,而这些组的名称都是相同的,这将导致组产生脑裂。因此,为了安全地引导组,需要在第一个MySQL Server启动完成之后,登录到数据库中, 手工执行如下语句完成组的引导(该参数也可用于重新引导组,先设置为OFF,再设置为ON)。
docker exec -it node2 bash
mysql -uroot -p123456
# 设置由该MySQL Server来引导组
mysql> SET GLOBAL group_replication_bootstrap_group=ON;
# 启动组复制
# 执行这一步的同时,需要在宿主机上执行 docker logs node2 -f 观察是否有错误;
# 先执行: reset master; # 可以解决事务不同步问题;
mysql> START GROUP_REPLICATION;
# 在该MySQL Server中,组复制启动完成之后,引导组的工作也一起完成了,为避免后续一系列意外原因可能发生脑裂,需要将引导组的开关参数及时关闭
mysql> SET GLOBAL group_replication_bootstrap_group=OFF;
一旦START GROUP_REPLICATION语句执行完成,代表着组就已经启动完成了。可以通过performance_schema.replication_group_members表中记录的组成员信息来查看组成员的状态: 从下面的内容中,我们可以看到,当前只有1个成员s1(每个成员有一行单独的记录),处于ONLINE状态,成员唯一标识符为ce9be252-2b71-11e6-b8f4-00212844f856(成员的server_uuid系统变量中获取的值), 正在端口3306上监听客户端连接(注意这里是SQL访问端口,不是组成员之间的通讯端口),SET GLOBAL group_replication_bootstrap_group 只有主节点执行, 而START GROUP_REPLICATION 每个节点都执行;
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 | 8db9d74a-8ec6-11ec-84fd-02421c2c0802 | c2acf827aced | 3306 | ONLINE | PRIMARY | 8.0.27 | XCom |
| group_replication_applier | a82f7896-8ec6-11ec-867a-02421c2c0803 | e47b0388298b | 3306 | RECOVERING | SECONDARY | 8.0.27 | XCom |
| group_replication_applier | b25ad348-8ec6-11ec-ad68-02421c2c0804 | 31ea2525fdae | 3306 | RECOVERING | SECONDARY | 8.0.27 | XCom |
+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+----------------------------+
# 小坑:两个从库的member_state 不是onlinne,而是recovering;
# 是因为mysql新版使用 caching_sha2_password 可能会节点长时间RECOVERING 状态,验证不了身份;
# 提前在各个节点执行以下语句可以避免。
mysql> alter USER porter@'%' IDENTIFIED WITH sha256_password BY '123456';
测试
- 此时在主节点写入数据,其它两个从节点会自动同步主节点数据,注意:不要在从库写数据,否则会导致同步问题,reset master 可以解决。
- 将主库所在容器停止,docker stop node2;从库会主动升级成主库,在任意从库查询:
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 | a82f7896-8ec6-11ec-867a-02421c2c0803 | e47b0388298b | 3306 | ONLINE | PRIMARY | 8.0.27 | XCom |
| group_replication_applier | b25ad348-8ec6-11ec-ad68-02421c2c0804 | 31ea2525fdae | 3306 | ONLINE | SECONDARY | 8.0.27 | XCom |
+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+----------------------------+
2 rows in set (0.00 sec)
# 停掉的主库已经脱离集群组,剩下的两个节点MEMBER_STATE均为:ONLINE 在线状态, a82f7896-8ec6-11ec-867a-02421c2c0803 由 SECONDARY 升级 成为 PRIMARY ;
至此,MGR部署完成。
六、应用场景
MGR采用多副本模式,在2N+1个集群中,集群只要N+1个节点还存活,数据库就能稳定对外提供服务,适用于金融场景,因为这些场景数据必须零丢失,可用性在4个9甚至5个9。 适用于替代当前主从高可用版本,解决单点写入问题。 针对业务需要弹性扩展节点的基础架构环境,例如私有云。
七、总结
尽管MySQL在2016年就推出了MGR该功能,同时我们也知道有很多好处,并且有大胆的公司采用进行测试甚至部署线上环境,据公开资料网易、滴滴都有使用,国内部分商业银行也有使用,但仍然有不少人处于观望状态,主要有以下几点原因导致:
- 需求不是特别强烈
很多业务情况使用MySQL半同步和异步复制足够满足业务要求,配合MHA第三方组件满足了绝大部分场景需求。
- 分布式新事物
本身分布式这个概念已经存在多年,但是由于MGR推出年限较短,且我们搜索官方bug库任然存在较多未解决的bug。用户使用排查问题较为困难,且由于分布式设计导致问题复现难也是一种阻碍。
- 生态不成熟
官方几乎没有完全成熟用来构建整套高可用架构的解决方案,如果想要大规模使用还是需要更加成熟的生态。
任何新鲜事物都有一个被大众接受过程,只是需要时间筛选和磨砺。
注意:本文归作者所有,未经作者允许,不得转载