本文介绍了MGR最佳实践参考以及使用MGR的约束和限制。1.参数选项设置以下是MGR相关参数选项设置的一些建议：#建议只使用singleprimary模式loose-group_replication_single_primary_mode=ON#不要开启bootstrap模式loose-group_replication_bootstrap_group=OFF#默认值为150MB，但建议降低到20MB以内，不要使用大事务loose-group_replication_transaction_size_limit=10M#大消息分片处理，每个分片10M，避免网络延迟太大group_replication_exit_state_action=READ_ONLY#如果节点没有收到广播消息时间长，会被认为是可疑节点。如果网络环境不好，可以适当增加。loose-group_replication_member_expel_timeout=5#建议关闭mysql流控机制这种模式下，只要多数方达成共识即可，不需要所有节点一致100ms记录日志，确认性能是否正常MGR层的瓶颈是loose-group_replication_request_time_threshold=100#记录更多的日志信息，方便跟踪问题log_error_verbosity=32。MGR相关的约束以下是使用MGR的一些限制：所有表必须是InnoDB引擎。可以创建非InnoDB引擎的表，但是不能写入数据，使用Clone新建节点也会报错（在GreatSQL中可以设置optionenforce_storage_engine=InnoDB只允许使用InnoDB引擎，而禁用其他引擎）。所有表都必须有一个主键。如上，可以创建没有主键的表，但是无法写入数据，使用Clone新建节点时会报错。尽量不要使用大交易。默认情况下事务超过150MB会报错，最大可以支持2GB的事务（GreatSQL以后的版本会增加对大事务的支持，提高大事务的上限，但是仍然不建议运行大事务）。如果您是从旧版本升级，则不能选择MINIMAL模式进行升级。建议选择AUTO模式，即upgrade=AUTO。由于MGR的事务认证线程不支持间隙锁，建议将所有节点的事务隔离级别改为READCOMMITTED。同理，不要在MGR集群中使用表锁和名字锁（即GET_LOCK()函数）。多主模式不支持SERIALIZABLE隔离级别。不支持在不同的MGR节点对同一张表分别执行DML和DDL，可能会导致数据丢失或节点报错退出。多主模式不支持多级级联外键表。另外，为了避免使用外键导致MGR错误，建议设置group_replication_enforce_update_everywhere_checks=ON。在多主模式下，如果多个节点执行SELECT...FORUPDATE，然后提交事务，会造成死锁。不支持复制过滤器设置。看似限制不少，但大部分时候不影响正常的业务使用。另外，启用MGR还有几个要求：必须在每个节点上启用binlog。每个节点都必须dumpbinlog，即设置log_slave_updates=1。binlog格式必须是row模式，即binlog_format=ROW。每个节点的server_id和server_uuid不能相同。8.0.20之前需要binlog_checksum=NONE，8.0.20之后可以设置binlog_checksum=CRC32。需要启用GTID，即设置gtid_mode=ON。master_info_repository=TABLE和relay_log_info_repository=TABLE是必须的，但是从MySQL8.0.23开始，这两个选项已经默认设置为TABLE，不需要单独设置。所有节点上的表名大小写参数lower_case_table_names必须一致。MGR最好部署在局域网内，不要跨越公网。如果网络延迟太大，MGR的性能会很差或容易出错。建议开启writeset模式，即设置如下参数slave_parallel_type=LOGICAL_CLOCKslave_parallel_workers=N，N>0，可以设置为逻辑CPU个数的两倍binlog_transaction_dependency_tracking=WRITESETslave_preserve_commit_order=1slave_checkpoint_period=23MGR使用建议When使用MGR，有以下建议：不要混用不同版本，尤其是不同大版本，尽快完成升级。同一张表的DDL和DML只能在同一个节点上，否则可能会导致节点意外退出MGR。不要运行大事务，尽量将每个事务控制在10MB以内。参考资料、文档MySQL8.0参考手册()数据库内核开发-文正虎()组复制原理-宋立兵()
