MGR要求及限制

接着上次问题,MGR有哪些要求及限制。现在来理一理


一、要求:

1.InnoDB存储引擎

 InnoDB提供了一些附加功能,可以在与组复制一起操作时更好地管理和处理冲突。

使用其他存储引擎,包括临时 MEMORY存储引擎,可能会导致组复制中的错误。

建议:

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


2.主键

组复制必须有主键,或者至少一列非空唯一列(等效主键),组复制具有其自己的内置的主键或主键等效项检查集,并且不使用sql_require_primary_key 系统变量执行的检查 。


3.网络性能

组复制服务器实例位于同一位置并共享本地组通信引擎(XCom)实例,所有组成员之间必须始终保持双向通信。

如果针对服务器实例阻止了入站或出站通信(例如,通过防火墙或由于连接问题),则该成员无法在该组中运行,并且该组成员(包括有问题的成员)可能无法报告受影响的服务器实例的正确成员状态。


4.数据库配置

--log-bin[=log_file_name] binlog必须打开并且binlog_format必须设置为ROW模式

--log-slave-updates=ON 组成员需要记录加入时从主库接收并通过复制应用程序应用的事务,并记录他们从组中接收并应用的所有事务。

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


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

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


 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 确保并行事务的最终提交与组复制所要求的顺序与原始事务的顺序相同


二、限制

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


GTID限制:

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



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


2.交易规模限制

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

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


3.集群节点等待时间

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

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


4.防火墙iptables

如果启用了iptables,则需要打开组复制端口以在计算机之间进行通信。假设配置的端口为33061,则通过发出iptables -A INPUT -p tcp --dport 33061 -j ACCEPT来启用必要端口上的通信



多主模式

1.事务隔离级别

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

对于处于多主模式的组,除非您依赖REPEATABLE READ应用程序中的语义,多主模式下建议事务

隔离级别设置为:READ COMMITTED

InnoDB不使用中的间隙锁READ COMMITTED,它使InnoDB中的本地冲突检测与由组复制执行的分布式冲突检测对齐。


2.并行DDL与DML操作

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


3.具有级联约束的外键

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


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


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



单主模式

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




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


思考:MGR如何升级?


猜你喜欢

转载自blog.51cto.com/15060546/2650689
MGR