MySQL 支持多种存储引擎（Storage Engine），不同引擎适用于不同的业务场景。下面是常见及重要的 MySQL 存储引擎汇总说明：

存储引擎	是否默认	事务支持	锁机制	特点与适用场景
InnoDB​	✅ 默认（MySQL 5.5+）	✅ 支持	行级锁	高并发、事务安全，最常用
MyISAM​	❌	❌ 不支持	表级锁	读多写少，全文索引（老版本）
MEMORY​	❌	❌	表级锁	数据存内存，速度快，重启丢失
CSV​	❌	❌	表级锁	CSV 文件存储，适合数据交换
ARCHIVE​	❌	❌	行级锁	只支持 INSERT/SELECT，高压缩
BLACKHOLE​	❌	❌	表级锁	写入即丢弃，用于复制测试
FEDERATED​	❌	❌	—	访问远程 MySQL 表
NDB (Cluster)​	❌	✅	行级锁	MySQL Cluster，分布式高可用

ACID​ 是关系型数据库事务（Transaction）必须满足的四个特性，用来保证数据正确、可靠。

特性	含义	关键作用
A Atomicity 原子性	事务要么全做，要么全不做	防止“做一半”
C Consistency 一致性	数据从一个合法状态到另一个合法状态	业务规则不被破坏
I Isolation 隔离性	并发事务互不干扰	防止脏读、不可重复读等
D Durability 持久性	提交后数据永久保存	宕机也不丢

Mysql的mgr：

MySQL Group Replication（简称 MGR）​ 是 MySQL 官方推出的一种基于 Paxos 协议的分布式复制插件，旨在提供原生的数据强一致性与高可用能力。它让多个 MySQL 实例组成一个“复制组”，组内每个节点都拥有完整的数据副本，通过原子广播和多数派共识机制来保证数据一致性

核心工作原理

• Paxos 共识（XCom 引擎）：事务提交前，必须广播到组内，并获得超过半数（N/2+1）节点的确认（多数派原则）。这确保了只要多数节点存活，数据就不会丢失（RPO=0），且能有效防止脑裂。

• 冲突检测：基于行级的 Write Set（依赖主键哈希）进行认证。如果不同节点修改同一行数据，先到达的事务提交，后者回滚（多主模式下）。

• 故障自愈：组内成员自动心跳检测，主节点故障时，剩余节点会自动选举新主（单主模式）或继续服务，节点恢复后可自动重新加入并同步数据。

两种部署模式

1. 单主模式（Single-Primary，默认推荐）：只有一位 Primary 节点可读写，其余为只读 Secondary。主节点宕机后会自动选主，适合绝大多数业务，官方及生产环境强烈建议使用该模式。

2. 多主模式（Multi-Primary）：所有节点均可读写，通过冲突检测解决写入竞争。但因行级冲突和特定实现限制（如轮询发送机制下某节点故障可能导致集群短时不可用），风险较高，一般不建议生产使用

MySQL Group Replication（简称 MGR）​ 是 MySQL 官方推出的一种基于 Paxos 协议的分布式复制插件，旨在提供原生的数据强一致性与高可用能力。它让多个 MySQL 实例组成一个“复制组”，组内每个节点都拥有完整的数据副本，通过原子广播和多数派共识机制来保证数据一致性。

核心工作原理

• Paxos 共识（XCom 引擎）：事务提交前，必须广播到组内，并获得超过半数（N/2+1）节点的确认（多数派原则）。这确保了只要多数节点存活，数据就不会丢失（RPO=0），且能有效防止脑裂。

• 冲突检测：基于行级的 Write Set（依赖主键哈希）进行认证。如果不同节点修改同一行数据，先到达的事务提交，后者回滚（多主模式下）。

• 故障自愈：组内成员自动心跳检测，主节点故障时，剩余节点会自动选举新主（单主模式）或继续服务，节点恢复后可自动重新加入并同步数据。

两种部署模式

1. 单主模式（Single-Primary，默认推荐）：只有一位 Primary 节点可读写，其余为只读 Secondary。主节点宕机后会自动选主，适合绝大多数业务，官方及生产环境强烈建议使用该模式。

2. 多主模式（Multi-Primary）：所有节点均可读写，通过冲突检测解决写入竞争。但因行级冲突和特定实现限制（如轮询发送机制下某节点故障可能导致集群短时不可用），风险较高，一般不建议生产使用。

关键限制与要求

• 引擎与表：仅支持 InnoDB​ 引擎，且所有表必须有显式主键（用于冲突检测）。

• 配置：必须开启 GTID，Binlog 格式必须为 ROW。

• 集群规模：官方建议 3、5、7 个节点（奇数），最多 9 个。节点过多会导致投票延迟，影响写性能。

• 网络：对延迟极敏感，节点间建议同机房部署，延迟 < 1ms，且需可靠低延迟网络（如万兆内网），不建议跨公网或高延迟网络。

适用场景

适合金融、交易、电商订单等对数据一致性要求极高的场景，以及读多写少、核心数据量适中（未过亿）、可容忍一定写性能损耗（较异步复制低 15%-30%）的业务。

MGR单主部署案例：

节点：3台服务器（如 192.168.1.101~103），建议关闭防火墙或开放 3306/33061 端口。

# 基础复制与GTID
server_id=1  # 102填2, 103填3
gtid_mode=ON
enforce_gtid_consistency=ON
log_bin=binlog
binlog_format=ROW
log_slave_updates=ON
master_info_repository=TABLE
relay_log_info_repository=TABLE
transaction_write_set_extraction=XXHASH64
binlog_checksum=NONE  # 8.0.21之前需要，之后可省略

# MGR 配置
plugin_load_add='group_replication.so'
group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa" # 用 SELECT UUID() 生成
group_replication_start_on_boot=OFF
group_replication_local_address= "192.168.1.101:33061" # 各节点填自己的IP
group_replication_group_seeds= "192.168.1.101:33061,192.168.1.102:33061,192.168.1.103:33061"
group_replication_bootstrap_group=OFF
group_replication_single_primary_mode=ON  # 开启单主模式

创建复制用户（所有节点）：

SET SQL_LOG_BIN=0;
CREATE USER 'rpl_user'@'%' IDENTIFIED BY 'YourPassword123';
GRANT REPLICATION SLAVE ON *.* TO 'rpl_user'@'%';
FLUSH PRIVILEGES;
SET SQL_LOG_BIN=1;

-- MySQL 8.0 执行（5.7用 CHANGE MASTER TO）
CHANGE REPLICATION SOURCE TO SOURCE_USER='rpl_user', SOURCE_PASSWORD='YourPassword123' FOR CHANNEL 'group_replication_recovery';

启动集群：

主节点：

SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION USER='rpl_user', PASSWORD='YourPassword123';
SET GLOBAL group_replication_bootstrap_group=OFF;

另外两个节点：

START GROUP_REPLICATION USER='rpl_user', PASSWORD='YourPassword123';

注意：如果是虚拟机克隆的 MySQL，务必删除 datadir下的 auto.cnf重启生成新 UUID，否则会冲突无法加入集群

注意：插件group_replication.so的避坑：

安装方式：生产环境推荐在 my.cnf中配置 plugin_load_add='group_replication.so'随实例自启加载；若未配置，则需手动执行 INSTALL PLUGIN group_replication SONAME 'group_replication.so'

确认插件是否安装，active

-- 登录 MySQL
mysql -uroot -p

-- 查看插件是否存在
SELECT * FROM information_schema.PLUGINS 
WHERE PLUGIN_NAME LIKE '%group%';

查看插件目录的命令：

SHOW VARIABLES LIKE 'plugin_dir';

ls /usr/lib64/mysql/plugin/ | grep group_replication

安装插件：

INSTALL PLUGIN group_replication SONAME 'group_replication.so';

要注意要创建复制用户：

创建 MGR 专用复制用户（所有节点都执行）：

-- 临时关闭 binlog，防止传播
SET SQL_LOG_BIN=0;

-- 创建复制用户（推荐命名）
CREATE USER 'rpl_mgr'@'%' 
IDENTIFIED BY 'Mgr@Secure123!';

-- 授权（只需这一项）
GRANT REPLICATION SLAVE ON *.* 
TO 'rpl_mgr'@'%';

FLUSH PRIVILEGES;

-- 恢复 binlog
SET SQL_LOG_BIN=1;

通道名	作用
group_replication_recovery	节点加入 / 故障恢复（必须配置）
group_replication_applier	应用事务（通常自动创建）

配置recovery通道：

CHANGE REPLICATION SOURCE TO
SOURCE_USER='rpl_mgr',
SOURCE_PASSWORD='Mgr@Secure123!'
FOR CHANNEL 'group_replication_recovery';

applier 通道（通常不用手动建）

如集群异常需手动确认或重建：

CHANGE REPLICATION SOURCE TO
SOURCE_USER='rpl_mgr',
SOURCE_PASSWORD='Mgr@Secure123!'
FOR CHANNEL 'group_replication_applier';

验证复制通道：

SELECT CHANNEL_NAME, USERNAME
FROM mysql.slave_master_info;

查看recovery通道状态：

SHOW REPLICA STATUS FOR CHANNEL 'group_replication_recovery'\G

验证MGR:

SELECT
MEMBER_HOST,
MEMBER_PORT,
MEMBER_STATE,
MEMBER_ROLE
FROM performance_schema.replication_group_members;

5.7的版本：

查看成员（通用）：

SELECT * 
FROM performance_schema.replication_group_members;

确认当前节点角色：

SHOW STATUS LIKE 'group_replication_primary_member';

功能	5.7	8.0
查看同步状态	SHOW SLAVE STATUS	SHOW REPLICA STATUS
Recovery 通道	group_replication_recovery	相同
插件状态	SHOW PLUGINS	相同
主节点查询	SHOW STATUS LIKE 'group_replication_primary_member'	SELECT primary_uuid ...