Mysql数据库管理--高可用集群MGR实战1

执笔画情ora

已于 2024-05-21 21:49:39 修改

阅读量1.3k

点赞数 2

分类专栏： mysql数据库高可用复制管理文章标签： mysql 数据库 java

于 2023-05-11 13:42:20 首次发布

原文链接：https://blog.csdn.net/qq_24432315/article/details/109127618

版权

mysql数据库高可用复制管理专栏收录该内容

17 篇文章 0 订阅

订阅专栏

1 文章概述

MySQL Group Replication(MGR)是MySQL官方于2016年12月推出的一个全新的高可用与高扩展的解决方案，MGR是基于原生复制及paxos协议的组复制技术，并以插件的方式提供，可以采取多主模式和单主模式，单主模式下，会自动选主，所有更新操作都在主上进行，多主模式下，所有server都可以同时处理更新操作。下面我们就来搭建下MGR集群（单主模式）。

处理过案例总结：

MGR环境基于pos复制到MGR环境，可行。

环境清单

2 MGR复制的要求与限制

// 9.1. 组复制要求

基础设施要求

InnoDB存储引擎：必须使用InnoDB存储引擎来存取数据。采用乐观锁方式，事务在提交时检测是否存在冲突，如果存在冲突，则为了保证整个组中数据的一致性，会回滚一些事务（存在冲突的事务中，先提交的事务不会受到影响，继续完成提交，而后提交的事务会被回滚），这意味着需要支持事务的存储引擎。此外，InnoDB还提供了一些附加功能，InnoDB存储引擎与组复制一起工作时能更好地管理和处理事务冲突。如果使用其他存储引擎，则可能会由于不支持这些功能与特性，无法正确处理组中的冲突等而发生错误。可以通过系统变量disabled_storage_engines来关闭其他不适用于组复制的存储引擎，如：

disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"。
主键：复制组中的每个表必须定义一个主键，或者定义一个与主键等效的非空唯一键，因为组复制需要利用唯一键来作为表中的每一行数据的唯一标识符，从而使得组能够准确地确定每个事务修改了哪些行，以便能够判断哪些事务存在冲突。
网络性能：组复制的设计要求一个组中的成员之间的物理距离不能太远（网络传输距离）。长距传输时的网络时延和网络带宽都会影响组的性能和稳定性。因为，组中的所有组成员之间必须始终保持双向通信（默认情况下，每秒都会相互发包探测其他组成员的健康状况）。如果是跨IDC机房的，防火墙策略需要在组复制组成员之间开通它们相互通讯所需的所有端口，否则被阻塞的成员会因为无法正确向组报告其Server的状态而被驱逐出组。从MySQL 8.0.14版本开始，可以使用IPv4或IPv6或两者混合使用来进行组成员之间的TCP通讯，也支持在虚拟专用网(VPN)上运行组复制。另外，在MySQL 8.0.14版本中，当组复制的成员位于同一位置（同一台主机）时，如果可能，则可以共享一个本地的组通信引擎(XCom)实例，这样，使用一个专用的开销更低的输入通道相比于使用TCP套接字进行通讯，能够最大程度地提高组的性能。但对于某些需要在远程XCom实例之间通信的组复制任务（例如：新的Server加入一个组），则仍然会使用TCP网络通讯，但此时网络性能会影响组的性能。

Server的系统变量配置要求

启用二进制日志记录功能：通过系统变量log-bin [= log_file_name]进行配置（例如：log_bin=mysql-bin）。组复制的数据同步机制是基于主从复制的基础架构实现的，需要使用二进制日志来进行数据同步，因此必须启用二进制日志才能进行操作。该系统变量默认启用（MySQL 8.0版本默认启用，在更早的版本中，该系统变量默认关闭）。
从库的任何更新都要记录到二进制日志中（包括通过复制同步的更新）：通过系统变量log-slave-updates进行配置（例如：log_slave_updates=1）。该系统变量默认启用（>= 8.0.3版本默认启用，<= 8.0.2版本默认关闭）。每个组成员都会记录加入组时从donor节点接收并应用的事务日志（二进制日志），也会记录其成功加入组之后从组中接收和应用的所有事务（二进制日志），这样，当有其他Server申请加入组时，组中的任意现有成员才能够为其提供基于二进制日志的状态传输来进行分布式恢复。
使用row（行）格式的二进制日志：通过系统变量binlog-format =row进行配置（例如：binlog_format=row）。组复制基于行的复制格式来实现组成员之间同步数据的一致性。它依赖于基于行的基础结构，以便能够从基于行的二进制日志中提取出必要的信息来检测在组中不同组成员上并发执行的事务之间是否存在冲突。
关闭二进制日志checksum校验：通过系统变量binlog-checksum=NONE进行配置（例如：binlog_checksum=NONE）。由于复制事件校验机制的设计限制，组复制不支持二进制日志事件的checksum校验，所以必须禁用。
启用全局事务标识符(GTID)：通过系统变量gtid-mode=ON进行配置（例如：gtid_mode=ON）。组复制使用全局事务标识符精确地跟踪每个组成员上已提交的事务，从而能够推断哪些组成员执行的事务可能与其他位置中已经提交的事务发生冲突。
复制信息存储到表：通过两个系统变量master_info_repository=TABLE和relay_log_info_repository=TABLE进行配置。复制线程需要将主库的连接信息、同步主库的位置信息息和中继日志元数据信息写入到mysql.slave_master_info和mysql.slave_relay_log_info系统表中存放。这确保了组复制能够通过复制的元数据信息来实现事务管理和一致性恢复。从MySQL 8.0.2版本开始，这两个系统变量默认值为TABLE（>=8.0.2版本默认值为TABLE，<=8.0.1版本默认值为FILE），从MySQL 8.0.3版本开始，不再推荐使用FILE设置值。
事务写集(write set)提取：通过系统变量transaction-write-set-extraction=XXHASH64配置用于生成写集的hash算法。组成员在将row格式的二进制日志记录到二进制文件的同时，也会收集写集。写集是基于row格式的二进制日志中每一行数据变更中可以唯一标识数据行的主键值（或唯一键值）生成的一个简单紧凑的视图标记。通过这个标记就能够进行事务的冲突认证检测。该系统变量默认启用（>=8.0.2版本默认为XXHASH64，<=8.0.1版本默认值为OFF）。
默认表加密：通过系统变量default_table_encryption=ON配置，组中所有的成员需要设置为相同的值，这样，就可以启用（ON）或禁用（OFF，默认值也为OFF）在组中默认对库和表空间的默认加密设置（当启用该系统变量时，如果用户在创建库或表时，没有指定ENCRYPTION选项，则该系统变量的设置对库表生效，即，启用加密）。注意：该系统变量在MySQL 8.0.16版本引入，可以动态修改。仅对用户创建的库表生效。
表名称小写：通过系统变量lower_case_table_names=1设置，组中的所有成员需要设置为相同的值。在组复制中使用InnoDB存储引擎时，需要将该值设置为1（将表名称都转换为小写）。注意，该系统变量的默认值在不同的平台上有不同的默认值（在Windows上，默认值为1，在OS X上，默认值为2，在类UNIX系统上，默认值为0）。
多线程复制：可以为组复制的成员启用多线程复制，从而使事务能够在组中的远端节点执行并行应用（发起事务写入的节点可以称为本地节点，其他通过二进制日志进行数据同步的节点可以称为远端节点）。通过将系统变量slave_parallel_workers设置为一个非0值来启用组成员上的多线程复制（设置为0表示禁用多线程复制，此时，系统变量slave_parallel_type和slave_preserve_commit_order的设置不生效），最多可以指定1024个并行应用线程（worker线程）。设置系统变量slave_preserve_commit_order=1可确保并行应用事务的最终提交顺序（这里指的是远端节点）与复制组所要求的原始事务的提交顺序相同（这里指的是本地节点提交事务之后，在组复制插件中排序的全局顺序），组复制的一致性保证依赖于组中所有的成员按照相同的顺序接收并应用组中已提交的事务。最后，设置系统变量slave_preserve_commit_order=1需要同时设置系统变量slave_parallel_type=LOGICAL_CLOCK，它用于确定哪些事务可以在从库上并行执行的策略。

* PS：通过前面的章节我们可以知道，组复制是基于主从复制的基础架构实现的，但相对于主从复制的IO和SQL线程来讲，组复制中对原来接收主库二进制日志的IO线程改动较大（用了一些后台线程相互协作来代替了主从复制拓扑中的IO线程的功能），对解析二进制日志并进行回放的SQL线程（或者说协调器线程与worker线程）改动较小。每一个组成员中都会创建到组复制的连接（主从复制拓扑中的IO线程被替换为了一些接收、验证写集的一些后台线程，可通过performance_schema.threads表进行查看），每一个组成员对接收到的写集进行冲突认证检测，并将认证通过的写集（二进制日志）写入自身的中继日志中，然后，由SQL线程读取中继日志进行回放（多线程复制中，由协调器线程读取中继日志，然后并行分发给worker线程进行回放）。

PS：组复制中所有组成员的Server 都必须满足以上要求

// 9.2. 组复制限制

组复制存在以下已知的限制。

注意：

* 在故障转移期间，对于多主模式的组所描述的限制和问题同样也适用于单主模式的组（新当选的主要节点从旧的主要节点清空其应用队列时，在这个临界点，可以将其类比组复制中有2个成员可写，所以这个时候单主模式也需要遵循多主复制模式中的限制）。

* 组复制的实现依赖于GTID复制机制，因此，组复制的限制还需要考虑到GTID复制的限制。

--upgrade=minimal：当MySQL Server指定--upgrade=minimal选项启动时，如果发现需要执行更新，则，在执行升级操作完成之后，可能会导致组复制无法启动，因为minimal选项在执行更新时，只会更新数据字典、information_schema、performance_schema，但不会更新组复制内部所依赖的系统表（--upgrade选项在MySQL 8.0.16版本引入，之后，升级操作将不再需要单独使用mysql_upgrade工具，默认情况下--upgrade选项值为AUTO，表示自动判断是否需要执行完整的更新操作）。

间隙锁(gap locks)：冲突认证检测过程不考虑间隙锁，因为有关间隙锁的信息在InnoDB存储引擎之外是不可用的。有关更多信息，请参见"https://dev.mysql.com/doc/refman/8.0/en/innodb-locking.html#innodb-gap-locks"。

注意：除非您的应用程序依赖于RR隔离级别，否则在组复制中建议使用RC隔离级别。因为InnoDB存储引擎在RC隔离级别中没有间隙锁，这就使得InnoDB存储引擎中的本地冲突检测与组复制执行的分布式冲突检测能够对齐（保持一致）。

表锁和命名锁：冲突认证检测过程不考虑表锁（表锁指的是：使用lock...table语句加锁、使用unlock table语句解锁）或命名锁(命名锁指的是：使用GET_LOCK()函数创建、使用RELEASE_LOCK()函数释放的锁)。

复制事件的checksum校验：由于复制事件的checksum校验机制的设计限制（这里指的是binlog中对每个event的checksum校验），组复制目前不支持。因此需要禁用（使用系统变量binlog-checksum=NONE关闭）。

可序列化(SERIALIZABLE)的隔离级别：默认情况下，多主模式的组不支持 SERIALIZABLE 隔离级别。将事务隔离级别设置为SERIALIZABLE时，组复制将拒绝该事务提交。

执行DDL语句期间并行执行DML语句：在多主模式的组中，不支持在不同的组成员上对同一个数据库对象并行执行DDL和DML语句。因为，对于某个对象来说，如果在一个组成员上执行DDL语句期间，同时在另外一个组成员上针对该对象并行执行DML语句，则，在组复制中可能导致DDL冲突无法被检测到的风险。

注意：在同一个组成员中对同一个对象并行执行DDL和DML语句，会由本地Server自行通过锁进行管理，不需要组参与。

具有级联约束的外键：多主模式的组（所有成员都设置了系统变量group_replication_single_primary_mode=OFF）不支持具有多级外键依赖关系的表，尤其是定义了级联外键约束的表。外键约束可能导致组无法检测到某些冲突，进而导致组成员之间的数据不一致。因此，建议在多主模式的组中所有组成员都设置系统变量group_replication_enforce_update_everywhere_checks=ON（启用该系统变量之后，一些可能带来风险的操作将直接被拒绝），以避免一些可能存在的冲突无法被检测到。注：在单主模式下，不存在这个问题，因为单主模式中，只有一个主要节点允许写操作。

14:40: [arcgis]> CREATE TABLE emp1( -- 副表
-> eid INT PRIMARY KEY AUTO_INCREMENT,
-> ename VARCHAR(10),
-> did INT, -- 外键字段
-> CONSTRAINT fk_dept_emp1 FOREIGN KEY(did)REFERENCES dept(did) -- references(依赖)
-> );
ERROR 1215 (HY000): Cannot add foreign key constraint

多主模式死锁：当一个组在多主模式下运行时，SELECT..FOR UPDATE语句会导致死锁。这是因为在组成员之间无法共享锁。

复制过滤器：不能在组复制的成员中对组复制专用的group_replication_applier或group_replication_recovery通道配置使用全局复制过滤器，因为在某些组成员上过滤了事务会破坏组中所有成员之间的数据一致性。但是，如果某个组成员同时作为主从复制拓扑中的从库时，则该主从复制通道允许配置使用全局复制过滤器（这里的主从复制通道，不包括组复制专用的group_replication_applier或group_replication_recovery通道）。

加密连接：从MySQL 8.0.16版本开始，MySQL Server支持TLSv1.3协议（前提是MySQL Server是使用OpenSSL 1.1.1或更高版本编译的）。但，从MySQL 8.0.18版本开始，组复制才支持TLSv1.3协议。所以，在MySQL 8.0.16和MySQL 8.0.17版本中，虽然MySQL Server支持TLSv1.3协议，但由于组通信引擎不支持TLSv1.3版本协议，所以，组复制在这两个Server版本中仍然不能使用TLSv1.3协议。

如果在组复制中使用了TLSv1.3版本协议进行分布式恢复，则组复制的组成员中至少一个成员必须允许使用TLSv1.3版本协议的密码套件。

组成员的数量限制：单个复制组中允许的组成员（MySQL Server实例）最大数量是9个。如果有更多的Server尝试加入该组时，其连接请求将被拒绝。该限制数量是通过已有的测试案例和基准测试中得出的一个安全边界，在这个安全边界中，组能够安全、可靠、稳定地运行在一个局域网中。

事务大小限制：如果单个事务产生的消息内容过大，以至于通过网络无法在5秒的时间内在组成员之间成功复制消息时，则可能会怀疑该成员失败了，进而导致其被驱逐出组，因为事务过大可能导致该成员一直忙于处理事务或者由于事务过大导致内存分配问题，进而导致系统变慢。为避免这些问题，可以采用以下措施进行适当缓解：

如果由于消息过大而导致发生了不必要的驱逐，那么可以使用系统变量group_replication_member_expel_timeout来为被怀疑失败的成员在被驱逐出组之前设置一个额外的等待时间（缓冲时间）。在最初的5秒钟检测期之后，会按照该系统变量设置的时间进行等待而不立即执行驱逐（最多一个小时），但是，当超过该系统变量设置的怀疑等待时间之后成员仍然未恢复组通讯的，则仍然会被驱逐出组。
在可能的情况下，请尝试限制组复制中的事务大小。例如：使用LOAD DATA语句加载一个大文件之前，先将这个大文件拆分为小文件进行逐个加载。
使用系统变量group_replication_transaction_size_limit设置复制组允许接收的最大事务大小。在MySQL 8.0中，该系统变量的默认最大事务大小为150000000字节(大约143 MB)。超过此大小的事务将被回滚，并且不会将该事务发送到组复制的组通信系统(GCS)中进行分发。请根据你的实际情况调整该系统变量的大小（注意：处理事务的时长与事务的大小成正比）。
使用系统变量group_replication_compression_threshold指定一个消息大小，当消息大小超过该系统变量设置的值时将被执行压缩。该系统变量默认为1000000字节(1 MB)，大于该系统变量大小的消息将被组复制的组通信系统(GCS)自动压缩（消息大小大于系统变量group_replication_compression_threshold设置的值但小于系统变量group_replication_transaction_size_limit设置的值时，消息才会被执行压缩）。有关更多信息，请参见"6.3. 消息压缩"。
使用系统变量group_replication_communication_max_message_size指定一个消息大小，当消息大小超过该系统变量设置的值时将被执行分段。该系统变量的默认值是10485760字节(10 MiB)，因此超过该大小的消息将会被自动分段（如果压缩后的消息仍然超过group_replication_communication_max_message_size系统变量设置的限制大小，则GCS在压缩完成之后再执行消息分段，每一个消息段的大小即为该系统变量设置的大小）。如果要使用消息分段，则组中所有的成员必须使用MySQL 8.0.16以上的版本，且组中的组复制通讯协议版本也必须要支持消息分段。有关更多信息，请参见"6.4. 消息分段"。

如果将以上组复制相关的限制性的系统变量值设置为0值，则表示禁用这些限制（事务大小限制、消息大小限制、消息分段限制等）。即，这就意味着关闭了所有这些保障措施。此时，组复制的每个成员可以处理的消息大小上限为每个成员中的系统变量slave_max_allowed_packet的值,，该系统变量的默认值为1073741824字节(1 GB，也是该系统变量的最大值)。超过该系统变量设置的消息大小的事务将失败。另外，单纯针对复制组来说，组成员可以发起并尝试传输给组的最大消息大小限制是4294967295字节(大约4 GB)。这是组复制（Paxos变体，XCom）的组通信引擎所能接收的包大小的硬限制。当有组成员试图广播超过这个硬限制大小的消息时将会广播失败。

2 MGR参数要求

gtid_mode=on #开启全局事务
enforce_gtid_consistency=on #强制GTID的一致性
master_info_repository = TABLE #将master_info元数据保存在系统表
relay_log_info_repository = TABLE #将relay_info元数据保存在系统表中
binlog_checksum = NONE #禁用二进制日志校验
log_slave_updates = ON #从库记录二进制日志
binlog-format=row #以行格式记录
transaction_write_set_extraction = XXHASH64 #以便在server收集写集合的同时将其记录到二进制日志。写集合基于每行的主键，并且是行更改后的唯一标识此标识将用于检测冲突。
loose-group_replication_group_name = '3773a86e-0def-11eb-a478-000c29a841a1' #组名字
loose-group_replication_start_on_boot = off #为了避免每次启动自动引导具有相同名称的第二个组,所以设置为OFF。

loose-group_replication_bootstrap_group = off #同上
loose-group_replication_local_address = "192.168.150.134:33061" #写自己主机所在IP
loose-group_replication_group_seeds = "192.168.150.134:33061,192.168.150.133:33061,192.168.150.135:33061"
loose-group_replication_single_primary_mode = true #开启单主模式的参数
loose-group_replication_enforce_update_everywhere_checks = false #开启多主模式的参数report_host=192.168.150.134

3 初始化mysql实例

4 创建复制用户

每个节点执行，执行前建议先关闭binlog

mysql> set sql_log_bin=0;
mysql> grant replication slave on *.* to repl@'%' identified by 'repl';
mysql> set sql_log_bin=1;

4 安装组复制插件

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 | PROPRIETARY
|+----------------------------+----------+--------------------+----------------------+-------------+

5 启动mgr集群

5.1 构建组复制集群

配置通道的恢复凭据，当节点需要从其他成员恢复状态时，使用group_replication_recovery'复制通道的凭据。分布式恢复是加入组的server执行的第一步，如果未正确设置这些凭据，server将无法执行恢复过程并获得与其他组成员同步，因此会最终将无法加入组。

在每个节点上执行：

CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='repl' FOR CHANNEL 'group_replication_recovery';

在主机上（node2）执行：

当第一个节点启动组复制功能之前(不是启动mysql实例，而是启动组复制插件的功能)，一般会将这个节点设置为组的引导节点，这不是必须的，但除非特殊调试环境，没人会吃撑了用第二、第三个节点去引导组。

所谓引导组，就是创建组。组创建之后，其他节点才能加入到组中。

将某节点设置为引导节点的方式是在该节点上设置以下变量为ON：

set @@global.group_replication_bootstrap_group=on;

开启引导功能后，一般会立即开启该节点的组复制功能来创建组，然后立即关闭组引导功能。所以，在第一个节点上，这3个语句常放在一起执行：

set @@global.group_replication_bootstrap_group=on;start group_replication;
set @@global.group_replication_bootstrap_group=off;

mysql> SET GLOBAL group_replication_bootstrap_group = ON;
mysql> START GROUP_REPLICATION;
mysql> SET GLOBAL group_replication_bootstrap_group = OFF;

查看集群状态

select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE
|+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | a7828aa6-b5c3-11ea-8308-000c29a841a1 | node2 | 3306 | ONLINE
|+---------------------------+--------------------------------------+-------------+-------------+--------------+

当第一个节点成功加入到组中后，这个节点会被标记为ONLINE，只有标记为ONLINE的节点，才是组中有效节点，可以向外提供服务、可以进行组内通信和投票。

如果配置的是单主模型(single-primary mode)的组复制，第一个加入组的节点会自动选为primary节点。如果配置为多主模型(multi-primary mode)的组复制，则没有master节点的概念。

6 加入节点新节点如何加入组

加入node1,在node1上执行

mysql> START GROUP_REPLICATION;

加入node3,在node3上执行

mysql> START GROUP_REPLICATION;

查看集群状态

新节点要加组，在配置好配置文件后，只需执行以下3个过程等待成功返回就可以了。


change master to 
        master_user='XXXX',
        master_password='YYYY'
        for channle 'group_replication_recovery';

install plugin group_replication soname 'group_replication.so';
start group_replication;

虽然操作很少，但这里涉及到一个很重要的过程：恢复过程。

如果一个新的节点要加入组，它首先要将自己的数据和组内的数据保持同步，同步的过程实际上是从组中获取某个节点的Binlog，然后应用到自己身上，填补自己缺失的那部分数据，这是通过异步复制完成的。而新节点和组中数据保持同步的过程称为恢复过程(或者称为分布式恢复过程)，它由组复制插件架构图中的"Recovery"组件来完成。

当新节点启动了它自己的组复制功能时，它将根据自己配置文件中 group_replication_group_seeds 选项的值来选一个节点作为同步时的数据供应节点，这个节点称为"donor"(中文意思就是"供应者")。例如：
loose-group_replication_group_seeds="192.168.100.21:20001,192.168.100.22:20002"
上面的配置中，两个节点都可以成为donor，它们称为"种子节点(seed)"。新节点从前向后逐一选择，当和第一个donor交互失败，就会选择第二个donor，直到选完最后一个donor，如果还失败，将超时等待一段时间后再从头开始选择。建议每个节点的配置文件中，都将组中所有节点写入种子节点列表中。

当选择好一个donor后，新节点会和这个donor建立一个数据恢复的通道group_replication_recovery。Recovery组件会从donor上复制所有新节点缺失的数据对应的binlog，然后应用在自身。当新节点数据和组中已经保持一致，则新节点成功加入到组，它将标记为ONLINE。（引入view概念，不能一直从doner同步啊对不对）

实际上，这只是恢复的一个阶段，还有第二阶段，有了上面的基础，下面的解释就容易理解了。

在新节点准备开始加入组的时候，Recovery组件有两个功能：(1).选择donor，并从donor处复制缺失的数据；(2).监控组中新产生的事务并放进自己的事务缓存队列中。

例如，在填补缺失的数据时，客户端向组中的可写节点插入了一条数据，这个数据不会被新节点的异步复制抓走，新节点会监控到这个事务。如下图：

所以将恢复过程概括一下：新节点的recovery组件通过异步复制通道从donor处获取p1之前的所有数据，并监控组中新生成的事务放入自己的事务缓存队列中。当新节点将p1之前的数据恢复完成后，将执行缓存队列中的事务，直到缓存中的事务数量减为0后，才表示新节点已经完全赶上了组中的数据，这是它才可以标识为ONLINE，并真正成为组中的一员。

这里有个问题需要考虑：事务数量相同，为什么新节点能赶上组？第一个原因是事务不会源源不断地生成，它总有停顿的时候；第二个原因归功于基于行格式的binlog(row-based binlog)，除了发起事务的那个节点，只要事务被大多数节点同意了，所有节点都根据binlog行中设置的值直接修改数据，而不会完整地执行事务逻辑。换句话说，事务发起节点修改数据的速度没有其他节点快，尽管它们是同时提交的。

7 节点状态分析

7 验证

在主库node2执行下面的命令进行验证

mysql> create database test;
Query OK, 1 row affected (0.33 sec)
mysql> use testDatabase changed
mysql> create table t(id int primary key auto_increment,name varchar(30),addr varchar(30));
Query OK, 0 rows affected (0.07 sec)
检查其他两个节点的数据。

模拟主库宕机

关闭主库

service mysqld stop

查看组成员

查看哪台服务器成为新主库，在MySQL8.0中通过replication_group_members表就能看出哪个节点是主库。

mysql> select * from performance_schema.global_status where variable_name='group_replication_primary_member' ;
+----------------------------------+--------------------------------------+
| VARIABLE_NAME | VARIABLE_VALUE |
+----------------------------------+--------------------------------------+
| group_replication_primary_member | 3118d7cb-67ca-11e9-9baa-000c29d7c489 |
+----------------------------------+--------------------------------------+

8 问题分析

1. node3加入组时报错：[ERROR] Slave I/O for channel '': error connecting to master 'repl@192.168.3.117:3306' - retry-time: 60 retries: 16, Error_code: 2003

原因：该节点之前曾作为另外一个集群的从节点。

解决方案：stop slave;reset slave;清空之前的集群信息。

2. 从节点之前已经存在数据了，搭建集群时节点之间数据不一致

解决方案：首先清空从节点的数据，从主库备份数据，在从库恢复。可以采用mysqldump或者Xtrabackup的方式备份恢复。
————————————————
版权声明：本文为CSDN博主「MySQL数据库技术栈」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_24432315/article/details/109127618

执笔画情ora

关注

2
点赞
踩
8

收藏

觉得还不错? 一键收藏
0
评论
Mysql数据库管理--高可用集群MGR实战1

MySQL Group Replication(MGR)是MySQL官方于2016年12月推出的一个全新的高可用与高扩展的解决方案，MGR是基于原生复制及paxos协议的组复制技术，并以插件的方式提供，可以采取多主模式和单主模式，单主模式下，会自动选主，所有更新操作都在主上进行，多主模式下，所有server都可以同时处理更新操作。下面我们就来搭建下MGR集群（单主模式）。环境清单gtid_mode=on #开启全局事务。
复制链接

扫一扫