oradbm的博客

写本篇文章的主要是希望给想用MGR的朋友提供一个参数配置参考，本次内容整理参考了3306π社区广州站《MGR Best Practice》万里DB CTO娄帅分享和一些个人的理解认识。MySQL InnoDB Cluster架构上图引用于官方手册。该架构中包含：MySQL Shell、MySQL router、MySQL Servers。MySQL Shell：用于搭建和管理MGR集群的一个客户端工具集。该工具基本是整合了原来官方的mysql utilis工具集。

全局事务标识符GTID的全称为Global Transaction Identifier，是在整个复制环境中对一个事务的唯一标识。它是MySQL 5.6加入的一个强大特性，目的在于能够实现主从自动定位和切换，而不像以前需要指定文件和位置。使用GTID复制时，主库上提交事务时创建事务对应的GTID，从库在应用中继日志时用GTID识别和跟踪每个事务。在启动新从库或因故障转移到新主库时可以使用GTID来标识复制的位置，极大地简化了这些任务。

测试环境为master-master双主模式，配置的双向复制。在ORACLE数据库逻辑复制OGG环境中，对于trigger 外键以及JOB需要，目标端需要临时禁用。那么MYSQL主从复制逻辑复制是否也需要在数据1 根据binlog_format有关系。statement 还有mixed格式。

MGR集群故障，大多数处于offline状态，如三个节点中2个或3个节点处于offline状态，集群不可用故障修复：1 三个MySQL节点依次执行如下命令，停止组复制 stop group_replication;2 然后依次启动每个节点的组复制# 第一个节点执行如下：# 后面两个节点再依次启动组复制# 查看组复制状态。

MGR切换模式需要重新启动组复制，因些需要在所有节点上先关闭组复制，设置 group_replication_single_primary_mode=OFF 等参数，再启动组复制。CHANGE MASTER... // 如果原来就已经建立好组复制，只是多主且单主，也可能不需要此步骤。# 重启之前记得修改配置文件，改为多主模式，因为之前是已单主模式部署的，现在是多主模式，要记得修改配置文件。# 查看数据，发现故障期间复制组新增数据也已经同步过来。# 启动MySQL实例，并重新加入复制。

MySQL 8.0 clone插件提供从一个实例克隆数据的功能，克隆功能提供了更有效的方式来快速创建MySQL实例，搭建主从复制和组复制。本文介绍使用 MySQL 8.0 clone 插件快速添加组复制（MGR）节点的方法。

PXC（Percona XtraDB Cluster）是一个开源的MySQL高可用解决方案。它将Percona server和XtraBackup与galera库集成，以实现同步多主复制。基于galera的高可用方案主要有MariaDB galeracluster和Percona XtraDB cluster，目前PXC架构在生产线上用的很多而且更加成熟。PXC相比那些传统的基于主从模式的集群架构MHA和双主，galera cluster最突出的特点是解决了诟病已久的复制延迟问题，基本上可以达到实时同步。

如果group_replication_autorejoin_tries为 0 或重试失败，则会执行 group_replication_exit_state_action 指定的操作。本文主要从测试的角度来阐明group_replication_unreachable_majority_timeout和group_replication_member_expel_timeout参数对集群网络分区的影响，首先这里放一张大图，为多年前学习MGR的时候留下的，也就是这两个参数对集群的影响，也是本文测试重点。

MGR 集群简介MySQL Group Replication（简称 MGR）是 MySQL 官方于 2016 年 12 月推出的一个全新的高可用与高扩展的解决方案。MySQL 组复制提供了高可用、高扩展、高可靠的 MySQL 集群服务MGR 的特点1、高一致性，基于原生复制及 paxos 协议的 组复制技术 ，并以插件的方式提供，提供一致数据安全 保证；

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

Percona XtraDB Cluster（简称PXC）—— 是基于Galera的MySQL高可用集群解决方案—— Galera Cluster是Codership公司开发的一套免费开源的高可用方案—— PXC集群主要由两部分组成：Percona Server with XtraDB（数据存储插件）和 Write Set Replication patches（同步、多主复制插件）—— 官网：http://galeracluster.com。

3. 当autocommit为开启状态时，即使没有手动start transaction开启事务，mysql默认也会将用户的操作当做事务即时提交。例如，你执行了insert into test values(2)语句，mysql默认会帮你开启事务，并且在这条插入语句执行完成之后，默认帮你提交事务。从上述的操作中我们可以明白，当autocommit为ON的情况下，并且又手动开启了事务，那么mysql会把start transaction 与 commit之间的语句当做一次事务来处理，

当主库发生故障宕机后，binlog其实已经都复制到从库并写入成relay log了。当然了，为避免误操作，建议先备份relay log。之后，从库就会继续应用relay log，待到全部应用完毕后，完成必要的数据校验，即可提成成为新的主库，对外提供服务了。TA想问：在这样的场景下，还有办法让B库尽快跑完这7200秒延迟数据吗，或者正确的办法是什么呢？# 关闭SLAVE服务，修改MASTER_DELAY，再启动SLAVE服务。事实上，只要正确理解，一键命令就搞定了。# 主库宕机后，查看SLAVE状态。

Binlog日志的三种模式介绍。

mysql数据库中二进制日志文件用来记录所有用户对数据库操作，当数据库发生意外，可以通过查询此文件，查询在一定时间内用户的所做操作，结合数据库备份可再现用户操作，使数据库恢复。

show slave status\GLast_IO_Errno: 2061Last_IO_Error: error connecting to master ‘root@192.168.0.10:3306’ - retry-time: 60 retries: 1 message: Authentication plugin ‘caching_sha2_password’ reported error: Authentication requires secure connection.1.问题现

1 正常来说，一个数据库的绝大部分时间应该是用于SQL的执行，所以这个是占用最多时间的：sql execute elapsedtime等。