day13-01-MGR高可用架构

MGR介绍

基于传统异步复制和半同步复制的缺陷——数据的一致性问题无法保证，MySQL官方在5.7.17版本正式推出组复制（MySQL Group Replication，简称MGR）。

由若干个节点共同组成一个复制组，一个事务的提交，必须经过组内大多数节点（N / 2 + 1）决议并通过，才能得以提交。如上图所示，由3个节点组成一个复制组，Consensus层为一致性协议层，在事务提交过程中，发生组间通讯，由2个节点决议(certify)通过这个事务，事务才能够最终得以提交并响应。

引入组复制，主要是为了解决传统异步复制和半同步复制可能产生数据不一致的问题。组复制依靠分布式一致性协议(Paxos协议的变体)，实现了分布式下数据的最终一致性，提供了真正的数据高可用方案(是否真正高可用还有待商榷)。其提供的多写方案，给我们实现多活方案带来了希望

背景

主从复制，一主多从，主库提供读写功能，从库提供只读功能。当一个事务在master 提交成功时，会把binlog文件同步到从库服务器上落地为relay log给slave端执行，这个过程主库是不考虑从库是否有接收到binlog文件，有可能出现这种情况，当主库commit一个事务后，数据库发生宕机，刚好它的binlog还没来得及传送到slave端，这个时候选任何一个slave端都会丢失这个事务，造成数据不一致情况。 为了避免出现主从数据不一致的情况，MySQL引入了半同步复制，添加多了一个从库反馈机制，即半同步复制。这个有两种方式设置：

• 主库执行完事务后，同步binlog给从库，从库ack反馈接收到binlog，主库提交commit，反馈给客户端，释放会话；
• 主库执行完事务后，主库提交commit ，同步binlog给从库，从库ack反馈接收到binlog，反馈给客户端，释放会话；


但是，虽然满足了一主多从，读写分析，数据一致，但是，依旧有两个弊端：

• 写操作只能在master上；
• 如果master宕机，需要人为选择新主并重新给其他的slave端执行change master；


为了解决一系列问题，官方推出了MySQL Group Replication，从group replication发布以后，就有3种方法来实现MySQL的高可用集群：

• 异步复制
• 半同步复制
• Group Replication

Group Replication原理

MySQL Group Replication有两种模式，单主模式single-primary mode和多主模式multi-primary mode，在同一个group内，不允许两种模式同时存在，并且若要切换到不同模式，必须修改配置后重新启动集群

单主模式

在单主模式下，只有一个节点可以读写，其他节点提供只读服务。单主模式下，该参数 _ 必须被设置为 FALSE ，当主节点宕掉，自动会根据服务器的server_uuid变量和group_replication_member_weight变量值，选择下一个slave谁作为主节点，group_replication_member_weight最高值对应的成员会被选为新的主节点，该参数默认为50，建议可以在节点上设置不同值；在group_replication_member_weight值相同的情况下，group根据数据字典中 server_uuid排序，排序在最前的被选择为主节点。

单主模式中发现当前的主服务器，该值VARIABLE_VALUE为实例节点的server_uuid：

select * from performance_schema.global_status WHERE VARIABLE_NAME like '%group_replication%';

多主模式

在mysql多主模式下,在组复制中通过Group Replication Protocol协议及Paxos协议，形成的整体高可用解决方案 同时增加了certify的概念，负责检查事务是否允许提交，是否与其它事务存在冲突,Group Replication是由多个节点共同组成一个数据库集群，每个节点都可以单独执行事务，但是read-write（rw）的操作只有在组内验证后才可以commit，Read-only (RO)事务是不需要验证可以立即执行，当一个事务在一个节点上提交之前，会在组内自动进行原子性的广播，告知其他节点变更了什么内容/执行了什么事务，然后为该事物建立一个全局的排序，最终，这意味着所有的服务器都以相同的顺序接收相同的事务集。因此，所有服务器都按照相同的顺序应用相同的变更集，因此它们在组中保持一致。 在多主模式下，该组的所有成员都设置为读写模式，在多主模式下，不支持SERIALIZABLE事务隔离级别，且不能完全支持级联外键约束


https://www.cnblogs.com/sallyluo/p/11760304.html

配置要求和限制

• 使用inndb存储引擎；InnoDB提供了一些附加功能，可以在与组复制一起操作时更好地管理和处理冲突，使用其他存储引擎，包括临时 MEMORY存储引擎，可能会导致组复制中的错误

  建议：

  disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"

• 每个表需要定义显式主键；或者至少一列非空唯一列（等效主键），组复制具有其自己的内置的主键或主键等效项检查集，并且不使用sql_require_primary_key 系统变量执行的检查

• 隔离级别：官网建议READ COMMITTED级别，不支持SERIALIZABLE隔离级别；

• 不建议使用级联外键；

• IPv4网络；

• auto_increment_increment和auto_increment_offset的配置；

• --log-bin = ROW；binlog必须打开并且binlog_format必须设置为ROW模式

• --log_slave_updates = ON；组成员需要记录加入时从主库接收并通过复制应用程序应用的事务，并记录他们从组中接收并应用的所有事务

  这使组复制能够通过从现有组成员的二进制日志进行状态来执行恢复

• 开启GTID；

  gtid_mode=ON全局事务标识符打开

  master_info_repository=TABLE

  relay_log_info_repository=TABLE

  复制应用程序需要将复制元数据写入 mysql.slave_master_info和 mysql.slave_relay_log_info表,

  不建议使用File

• --lower-case-table-names小写表格名称。在所有组成员上 设置 为相同的值

• slave_parallel_workers=16 在成员上启用多线程应用程序，并且最多可以指定1024个并行应用程序线

• slave_parallel_type=LOGICAL_CLOCK

• slave_preserve_commit_order=1 确保并行事务的最终提交与组复制所要求的顺序与原始事务的顺序相同

• 安装引擎：group_replication.so；

• --binlog-checksum=NONE 关闭二进制日志校验和（适用于MySQL 8.0.20）组复制无法使用校验和，并且不支持二进制日志中的校验和

  从MySQL 8.0.21开始，组复制支持校验和，因此组成员可以使用默认设置binlog_checksum=CRC32

限制

MGR在GTID模式基础上，GTID模式限制，MGR同样也限制

GTID限制：

CREATE TABLE ... SELECT语句限制，不能使用这种sql sql_slave_skip_counter使用GTID时不支持。如果需要跳过事务，请改用源gtid_executed变量的值

一个复制组成员的MySQL服务器的最大数量为9

交易规模限制

group_replication_transaction_size_limit 来指定组将接受的最大事务大小。

在MySQL 8.0中，此系统变量默认为最大事务大小为150000000字节（约143 MB），单个事务超过143M集群断开

集群节点等待时间

group_replication_member_expel_timeout 增加了从产生怀疑（在最初的5秒检测周期之后发生）到成员被驱逐之间的时间。可以设置最长1小时的等待时间。从MySQL 8.0.21开始，默认设置等待时间为5秒

group_replication_autorejoin_tries 让成员在被驱逐或多数派超时后尝试重新加入该组。从MySQL 8.0.21开始，默认了3次自动重新加入尝试

防火墙iptables

如果启用了iptables，则需要打开组复制端口以在计算机之间进行通信。

假设配置的端口为33061，要配置规则来启用必要端口上的通信

iptables -A INPUT -p tcp --dport 33061 -j ACCEPT

单主模式

对于单主模式的组，只有主系统接受写操作，因此READ COMMITTED隔离级别对组复制并不重要

总结：建议目前还是使用MGR单主模式，多主模式限制也比较多。问题Bug也比较多

多主模式

当组以多主模式运行时， SELECT .. FOR UPDATE语句可能导致死锁

事务隔离级别

设置事务隔离级别以 SERIALIZABLE将组复制配置为拒绝提交事务。

对于处于多主模式的组，除非您依赖REPEATABLE READ应用程序中的语义

多主模式下建议事务

隔离级别设置为：READ COMMITTED

并行DDL与DML操作

多主模式下，不支持针对同一对象在不同服务器上并发的执行DDL，会导致数据不一致

具有级联约束的外键

多主模式组（所有成员都配置有group_replication_single_primary_mode=OFF）不支持具有多级外键依赖性的表，特别是定义了 CASCADING 外键约束的表

建议：group_replication_enforce_update_everywhere_checks=ON 在多主要模式组中使用的服务器实例上进行设置 ，以避免未检测到的冲突