异步复制
Semi-Synchronous Replication（半同步复制）
Multi-threaded Slave（并行复制）
相关资料
- MySQL 5.7新特性：并行复制原理（MTS）
- MySQL下xtrabackup与MTS造成的死锁
- Centos7.5部署MySQL5.7基于GTID主从复制+并行复制+半同步复制+读写分离(ProxySQL) 环境- 运维笔记 (完整版)
MySQL Group Replication(MGR)
组复制是一种可用于实现容错系统的技术。 复制组是一个通过消息传递相互交互的 server 集群。通信层提供了原子消息(atomic message)和完全有序信息交互等保障机制实现了基于复制协议的多主更新 复制组由多个 server成员构成,并且组中的每个 server 成员可以独立地执行事务。但所有读写(RW)事务只有在冲突检测成功后才会提交。只读(RO)事务不需要在冲突检测,可以立即提交。句话说,对于任何 RW 事务,提交操作并不是由始发 server 单向决定的,而是由组来决定是否提交。准确地说,在始发 server 上,当事务准备好提交时,该 server 会广播写入值(已改变的行)和对应的写入集(已更新的行的唯一标识符)。然后会为该事务建立一个全局的顺序。最终,这意味着所有 server 成员以相同的顺序接收同一组事务。因此,所有 server 成员以相同的顺序应用相同的更改,以确保组内一致。
特点
- 高一致性：基于分布式paxos协议实现组复制，保证数据一致性；
- 高容错性：自动检测机制，只要不是大多数节点都宕机就可以继续工作，内置防脑裂保护机制；
- 高扩展性：节点的增加与移除会自动更新组成员信息，新节点加入后，自动从其他节点同步增量数据，直到与其他节点数据一致；
- 高灵活性：提供单主模式和多主模式，单主模式在主库宕机后能够自动选主，所有写入都在主节点进行，多主模式支持多节点写入。
单主模式
组复制具有自动选主功能，每次只有一个 server成员接受更新。单写模式group内只有一台节点可写可读，其他节点只可以读。对于group的部署，需要先跑起primary节点（即那个可写可读的节点，read_only = 0）然后再跑起其他的节点，并把这些节点一一加进group。其他的节点就会自动同步primary节点上面的变化，然后将自己设置为只读模式（read_only = 1）。当primary节点意外宕机或者下线，在满足大多数节点存活的情况下，group内部发起选举，选出下一个可用的读节点，提升为primary节点。primary选举根据group内剩下存活节点的UUID按字典序升序来选择，即剩余存活的节点按UUID字典序排列，然后选择排在最前的节点作为新的primary节点。
多主模式
所有的 server 成员都可以同时接受更新。group内的所有机器都是primary节点，同时可以进行读写操作，并且数据是最终一致的。
限制
- 必须使用innodb引擎，冲突时要回滚，使用其他引擎可能会数据不一致。
- 每个表都要求显示定义主键，用于冲突检测识别。
- 开启GTID，通过GTID来追踪各事务在各机器上的情况 。
- binlog使用row模式，确保各机器数据的一致性。
- 使用READ COMMITTED的隔离级别来规避Gap Locks
- 多主模式不支持在不同节点上对同一个数据库对象并发执行DDL(在不同节点上对同一行并发进行RW事务，后发起的事务会失败);
MMM架构
MMM（Master-Master replication manager for MySQL）是一套支持双主故障切换和双主日常管理的脚本程序。MMM使用Perl语言开发，主要用来监控和管理MySQL Master-Master（双主）复制，虽然叫做双主复制，但是业务上同一时刻只允许对一个主进行写入，另一台备选主上提供部分读服务，以加速在主主切换时刻备选主的预热，可以说MMM这套脚本程序一方面实现了故障切换的功能，另一方面其内部附加的工具脚本也可以实现多个slave的read负载均衡。
优点
高可用性，扩展性好，出现故障自动切换，对于主主同步，在同一时间只提供一台数据库写操作，保证的数据的一致性。
缺点
Monitor节点是单点，可以结合Keepalived实现高可用。
MHA架构
MHA，全称为MasterHigh Availability Manager and Toolsfor MySQL，是日本的一位MySQL专家采用Perl语言编写的一个脚本管理工具，该工具仅适用于MySQL Replication 环境，目的在于维持Master主库的高可用性。
MHA是基于标准的MySQL复制(异步/半同步)。
MHA是由管理节点(MHA Manager)和数据节点(MHA Node)两部分组成。
MHA Manager可以单独部署在一台独立机器,也可以部署在一台slave上。
MySQL Cluster
Percona XtraDB Cluster(PXC)
事务型应用下的通用的多主同步复制插件，主要用于解决强一致性问题，使得各个节点之间的数据保持实时同步以及实现多节点同时读写。
限制
1、存储引擎：
基于PXC的复制仅适用于InnoDB存储引擎。
对其他存储引擎的表，包括mysql.表之类的系统表，任何写入都不会被复制。
那问题来了，如此这般创建用户那岂不是无法同步了？关于这个问题。对于基于DDL方式的语句还是被支持的。
DDL语句使用基于语句级别的方式来实现(即不使用row模式)。
对mysql.表的所有已DDL方式的更改都将以语句级别式进行复制。
如：CREATE USER… DDL被复制(语句级)
INSERT INTO mysql.user… myisam存储引擎，不会被复制，因为非DDL语句
当然也可以配置wsrep_replicate_myisam参数实现(不建议使用)
2、不支持的查询：
LOCK TABLES在多主模式中不支持UNLOCK TABLES以及LOCK TABLES
锁定功能，如GET_LOCK()，RELEASE_LOCK()等也不被支持
3、查询日志不能定向到表：
如果启用查询日志记录，则必须将日志转发到文件
使用general_log和general_log_file选择查询日志记录和日志文件名称
log_output = file # Author : Leshami # Blog : https://blog.csdn.net/leshami
4、最大事务大小：
允许的最大事务大小由wsrep_max_ws_rows和wsrep_max_ws_size变量定义
LOAD DATA INFILE方式处理每10000行提交一次。对于大的事务将被分解众多小型事务
5、集群乐观并发控制：
PXC集群使用乐观并发控制，事务发出COMMIT可能仍会在该阶段中止
可以有两个事务写入相同的行并在单独的Percona XtraDB集群节点中提交，并且只有其中一个可以成功提交。
失败的将被中止。对于集群级中止，Percona XtraDB集群返回死锁错误代码：
(Error: 1213 SQLSTATE: 40001 (ER_LOCK_DEADLOCK)).
6、由于可能的提交回滚，XA事务不受支持：
7、硬件配置短板限制：
整个群集的写吞吐量受最弱节点的限制。如果一个节点变慢，整个集群变慢。
如果您对稳定的高性能有要求，那么它应该由相应的硬件支持。
8、建议的最小群集大小是3个节点。第三个节点可以是仲裁者。
9、InnoDB虚假更改功能不受支持。
10、enforce_storage_engine=InnoDB与wsrep_replicate_myisam=OFF（默认）不兼容 。
11、binlog_rows_query_log_events变量不受支持。
12、高负载时避免ALTER TABLE … IMPORT / EXPORT
在集群模式下运行Percona XtraDB集群时，请避免ALTER TABLE … IMPORT / EXPORT工作负载。
如果未在所有节点上同步执行，则可能导致节点不一致。
参考链接：https://www.percona.com/doc/percona-xtradb-cluster/LATEST/limitation.html
若有收获，就点个赞吧
0 人点赞
