一介IT

InnoDB Cluster 主要由和MySQL服务器集群组成，三者协同工作，共同为 MySQL 提供完整的高可用性解决方案。InnoDB Cluster 以组复制为基础，集群中的每个 MySQL 服务器实例都是组复制的成员，提供了在 InnoDB Cluster 内复制数据的机制，并且具有内置的故障转移功能。MySQL Shell 在 InnoDB Cluster 中充当控制台角色，使用它包含的AdminAPI，可以使安装、配置、管理、维护多个MySQL组复制实例的工作更加轻松。通过AdminAPI。

欢迎关注公众号：一介IT本文 8.4万 字。建议收藏。文章目录1. 组复制 (MGR) 介绍1.1 回顾传统复制1.2 组复制原理1.3 组复制与传统复制对比1.4 组复制模式1.4.1 单主模式1.4.2 多主模式1.5 组复制特点1.6 组复制的要求与限制1.7 组复制相关服务1.8 组复制技术细节1.8.1 组复制插件体系结构1.8.2 复制组1.8.3 DML1.8.4 DDL1.8.5 分布式恢复1.8.5.1 分布式恢复基础1.8.5.2 基于时间点的恢复1.8.5.3 视图更

MySQL 从 5.6 版本开始追加了并行复制功能，目的就是为了改善复制延迟问题，并行复制称为 enhanced multi-threaded slave（简称 MTS ）。

欢迎关注公众号：一介IT本站博文抢先发布在公众号。

欢迎关注公众号：一介IT本站文章先发布在公众号。

背景MySQL 任何复制方式都是基于 binlog 方式进行的。从 MySQL5.6 开始增加了特性，作为方式的延伸，用来强化数据库的主备一致性，故障恢复，以及容错能力。以取代过去传统的主从复制 (即：基于和的异步复制)。借助，在发生主备切换的情况下，MySQL 的其他 slave 可以自动在新主上找到正确的复制位置，这大大简化了复杂复制拓扑下集群的维护，也减少了人为设置复制发生误操作的风险。另外，基于的复制可以忽略已经执行过的事务，减少了数据发生不一致的风险。MySQL复制中使用的事务类型有以下两种：GT

即使通常 MySQL 复制很快，但 MySQL 缺省的复制存在延迟，并且用户无法缩短延迟时间。另一方面，有时却需要特意增加复制的延迟。设想这样一种场景，用户在主库上误删除了一个表，并且该操作很快被复制到从库。当用户发现这个错误时，从库早就完成了该事件重放。此时主库、从库都没有那个被误删的表了，如何恢复？如果有备份，可以幸运地从备份恢复，丢失的数据量取决于备份的新旧和从备份时间点到表被删除时间点之间该表上数据的变化量。如果没有备份呢？这种情况下，延迟复制或许可以帮上忙，作为一种恢复数据的备选方案。

传统的异步复制MySQL 缺省使用异步复制策略。简单说所谓异步复制，指的是主库写二进制日志、从库的 I/O 线程读主库的二进制日志写本地中继日志、从库的 SQL 线程重放中继日志，这三步操作都是异步进行的。如此选择的主要理由是出于性能考虑，与同步复制相比，异步复制显然更快，同时能承载更高的吞吐量。但异步复制的缺点同样明显，不能保证主从数据实时一致，也无法控制从库的延迟时间，因此它不适于要求主从数据实时同步的场景。

欢迎关注公众号：一介IT本站博文抢先发布在公众号。本文通过 yum 方式部署 Mysql 数据库的复制环境，其他方式参考【

欢迎关注公众号：一介IT本站博文抢先发布在公众号。1. MySQL 的卸载为什么先卸载？从零开始嘛。1.1 Windows 下 Mysql 的卸载1.1.1 步骤1：停止 MySQL 服务在卸载之前，先停止 MySQL8.0 的服务。按键盘上的 Ctrl + Alt + Delete 组合键，打开“任务管理器”对话框，可以在“服务”列表找到 MySQL8.0 的服务，如果现在“正在运行”状态，可以右键单击服务，选择“停止”选项停止 MySQL8.0 的服务，如图所示。1.1.2

简单说，复制就是将来自一个 MySQL 数据库服务器 (主库) 的数据复制到一个或多个 MySQL 数据库服务器 (从库)。传统的 MySQL 复制提供了一种简单的 Primary-Secondary 复制方法，默认情况下，复制是单向异步的。MySQL 支持两种复制方式：基于行的复制和基于语句的复制。这两种方式都是通过在主库上记录二进制日志 (binlog)、在从库重放中继日志 (Rely log) 的方式来实现异步的数据复制。二进制日志或中继日志中的记录被称为事件。所谓异步。