
回复
本文介绍MGR最佳实践参考以及使用MGR的约束限制。
下面是几个MGR相关参数选项设置建议:
#建议只用单主模式
loose-group_replication_single_primary_mode=ON
#不要启用引导模式
loose-group_replication_bootstrap_group=OFF
#默认值150MB,但建议调低在20MB以内,不要使用大事务
loose-group_replication_transaction_size_limit = 10M
#大消息分片处理,每个分片10M,避免网络延迟太大
loose-group_replication_communication_max_message_size = 10M
#节点退出后的默认行为,将本节点设置为RO模式
loose-group_replication_exit_state_action = READ_ONLY
#超过多长时间收不到广播消息就认定为可疑节点,如果网络环境不好,可以适当调高
loose-group_replication_member_expel_timeout = 5
#建议关闭MySQL流控机制
loose-group_replication_flow_control_mode = "DISABLED"
#AFTER模式下,只要多数派达成一致就可以,不需要全部节点一致
loose-group_replication_majority_after_mode = ON
#是否设置为仲裁节点
loose-group_replication_arbitrator = 0
#启用快速单主模式
loose-group_replication_single_primary_fast_mode = 1
#当MGR层耗时超过100ms就记录日志,确认是否MGR层的性能瓶颈问题
loose-group_replication_request_time_threshold = 100
#记录更多日志信息,便于跟踪问题
log_error_verbosity=3
下面是关于MGR使用的一些限制:
enforce_storage_engine = InnoDB
只允许使用InnoDB引擎,而禁用其他引擎)。upgrade=AUTO
。gap lock
,因此建议把所有节点的事务隔离级别都改成READ COMMITTED
。基于相同的原因,MGR集群中也不要使用table lock
及name lock
(即GET_LOCK()
函数 )。multi-primary
)模式下不支持串行(SERIALIZABLE
)隔离级别。multi-primary
)模式下不支持多层级联外键表。另外,为了避免因为使用外键造成MGR报错,建议设置group_replication_enforce_update_everywhere_checks=ON
。multi-primary
)模式下,如果多个节点都执行SELECT ... FOR UPDATE
后提交事务会造成死锁。看起来限制有点多,但绝大多数时候并不影响正常的业务使用。
此外,想要启用MGR还有几个要求:
log_slave_updates=1
。binlog_format=ROW
。server_id
及server_uuid
不能相同。binlog_checksum=NONE
,但是从8.0.20后,可以设置binlog_checksum=CRC32
。gtid_mode=ON
。master_info_repository=TABLE
及relay_log_info_repository=TABLE
,不过从MySQL 8.0.23开始,这两个选项已经默认设置TABLE,因此无需再单独设置。lower_case_table_names
设置要求一致。slave_parallel_type = LOGICAL_CLOCK
slave_parallel_workers = N
,N>0,可以设置为逻辑CPU数的2倍binlog_transaction_dependency_tracking = WRITESET
slave_preserve_commit_order = 1
slave_checkpoint_period = 2
在使用MGR时,有以下几个建议:
本文转载自公众号:GreatSQL社区