mgr test1

介绍

MGR 即 MySQL Group Replication 基于原生复制和paxos协议的组复制技术, 以插件方式提供 , 可动态新增和移除节点, 分为单主和多主模式。

• 文档地址
  https://dev.mysql.com/doc/refman/8.0/en/group-replication.html

18.1 Group Replication Background

• MGR通讯协议 Group Communication System (GCS) ,基于Paxos 算法实现

18.1.1 复制技术

• 异步复制

  
  
  image.png

• 半同步复制

  
  
  image.png

• 组复制
  分为单主模式(单点写)和多主模式(多点可写)
  组复制shared-nothing复制方案,每个server有完整数据副本
  写事务需要组内冲突检测,通过才能提交,只读事务不需要
  性能瓶颈更大几率在冲突检测(内存/网络)而非IO

  
  
  image.png

18.1.2 组复制用例

MGR尽可能保证集群可用,但当一个节点奔溃时,连接到db的客户端需要重定向到其他节点,MGR不负责重定向, 可以用其他负载均衡、路由等中间件,也可用用 MySQL Router。

18.1.3 多主和单主模式

设置单主or多主group_replication_single_primary_mode ，所有server配置需相同，默认ON表示单主,OFF多主。
8.0.13开始可以通过函数在线切换单主与多主模式:
group_replication_switch_to_single_primary_mode()
group_replication_switch_to_multi_primary_mode()

18.1.3.1 单主模式

单主模式group_replication_single_primary_mode=ON 只有M节点可写,其他只读。
group_replication_enforce_update_everywhere_checks单主模式下必须OFF，多主设置为ON(严格检测)

• 主选举场景:
  1.当前M离开(主动or被动)
  2.SELECT group_replication_set_as_primary(member_uuid);
  3.SELECT group_replication_switch_to_single_primary_mode(member_uuid);

• 选举算法
  如果集群中MySQL版本不同,选举将用最低版本server对应的选举算法
  1.如果所有组成员>=MySQL 8.0.17，则按小版本排序。如果任何成员 2.group_replication_member_weight 权重(0-100，默认50),大值优先选为M, 如果有5.7则忽略(应该是5.7和8.0混部情况,需测试)
  3.权限相同情况下,根据server_uuid排序

• 查看当前主
  1.SELECT MEMBER_HOST, MEMBER_ROLE FROM performance_schema.replication_group_members;
  2.SHOW STATUS LIKE 'group_replication_primary_member' # 将来此变量会被移除

18.1.3.2 多主模式

MySQL 8.0.14 开始新增参数group_replication_consistency控制事务一致性,动态可更改, 更改后不需要重启MGR集群, 支持session级别。
group_replication_enforce_update_everywhere_checks多主模式下一定要设置成ON（虽然可为OFF，但不建议）

• 事务检查
  1.不允许SERIALIZABLE 隔离级别。
  2.不支持外键。

18.1.4 Group Replication Services

18.1.4.1 Group Membership

• group_replication_member_expel_timeout=5
  (8.0.13引入≥8.0.21默认5)成员从被怀疑到被踢出集群的等待时间,不包含前期常监测异时间,如果网络环境不好,可适当调高; 0表示不等待,可动态修改立即生效,不同节点可设置不同值(但建议相同值);最大3600s,但需要足够大XCom缓存(group_replication_message_cache_size )

• group_replication_unreachable_majority_timeout=5
  默认0,可动态修改立即生效,指成员因网络分区无法连接到其他大部分成员而离开集群前等待的秒数。
  5个server(S1,S2,S3,S4,S5)组成一个集群,如果(S1,S2)和(S3,S4,S5)之间断开,则表示存在了网络分区,(S1,S2)属于少数,将等待指定秒数后脱离集群,(S3,S4,S5)继续运行。
  默认0，意味着由于网络分区而处于少数状态的成员将永远等待脱离集群(会一直等待,不会因为网络分区而导致成员脱离组)。>0 则当指定时间过期时,少数分区处理的所有挂起事务都将回滚,少数分区中的服务器状态变成ERROR
  如果设置了group_replication_autorejoin_tries>0则成员会以超级只读模式尝试,尝试完后执行group_replication_exit_state_action指定动作。
  注意,如果分区对等4个server(S1,S2,S3,S4)分区成(S1,S2)和(S3,S4)则不存在大部分成员,则所有成员变成ERROR状态

• group_replication_autorejoin_tries=3
  (8.0.16引入≥8.0.21默认3)组成员被驱逐出组或失联达到超时时间后,尝试自动重新加入组的次数。可动态修改立即生效, >0时每次尝试后会等待5分钟再进行下一一次尝试直到达到设置尝试值。

• group_replication_exit_state_action=READ_ONLY
  (≥8.0.16 默认READ_ONLYM,可选ABORT_SERVER,OFFLINE_MODE,READ_ONLY),可动态修改立即生效,表示成员意外离开组时的动作行为
  READ_ONLY 成员变成只读模式super_read_only=1
  ABORT_SERVER 成员会变成离线模式offline_mode=1 , 此模式下,已连接客户端在下一个请求时会断开连接,并拒绝再连接,但CONNECTION_ADMIN权限(和将废除的SUPER权限)的客户端用户除外。
  组复制线程还会将系统变量super_read_only设置为ON,因此客户端无法进行任何更新,即使有CONNECTION_ADMIN或super权限连接。MySQL 8.0.18起支持OFFLINE_MODE。
  OFFLINE_MODE 成员会关闭mysql服务

• group_replication_message_cache_size=1073741824
  默认1G,所有成员配置最好相同,可动态设置但是需要重启MGR进程; 通信引擎XCom中可用于消息缓存的最大内存,
  XCom包含成员间通讯信息及元数据,另外可用于与其他组成员无法通信一段时间后重连到组的成员恢复丢失的消息。
  从8.0.21开始,最小可设置128M用于低配机器,但要注意缓存结构还需要额外50M内存(一句话,配置不高就别上MGR)

18.1.4.2 Failure Detection

18.1.4.3 Fault-tolerance

Group Size	Majority	Instant Failures Tolerated
1	1	0
2	2	0
3	2	1
4	3	1
5	3	2
6	4	2
7	4	3

18.1.4.4 Observability

18.1.5 Group Replication Plugin Architecture

image.png

18.2 Getting Started

18.3 Requirements and Limitations

18.3.1 Group Replication Requirements

Infrastructure

• InnoDB Storage Engine
  配置中文件增加disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
• Primary Keys
  每个表必须有PK或者非null的unique key
  可以设置sql_require_primary_key=ON(默认OFF), 和CHANGE REPLICATION SOURCE TO时设置REQUIRE_TABLE_PRIMARY_KEY_CHECK=ON
• Network Performance
  不用说了

Server Instance Configuration

• Unique Server Identifier
  server-id 不用说了

• Binary Log Active
  log-bin 启用binlog,这也不用说了

• Replica Updates Logged
  log_replica_updates=ON (from MySQL 8.0.26) or log_slave_updates=ON (before MySQL 8.0.26)

• Binary Log Row Format
  binlog_format=row 必须是row格式

• Binary Log Checksums Off (to MySQL 8.0.20)
  <=8.0.20, binlog_checksum=NONE , >=8.0.21 MGR支持binlog_checksum=CRC32

• Global Transaction Identifiers On
  gtid_mode=ON and enforce_gtid_consistency=ON 必须启用GTID模式

• Replication Information Repositories
  master_info_repository=TABLE and relay_log_info_repository=TABLE 从MySQL 8.0开始放弃FILE吧

• Transaction Write Set Extraction
  transaction_write_set_extraction=XXHASH64 从MySQL 8.0.26开始此变量将成为默认值,后期此变量可能被移除

• Default Table Encryption
  default_table_encryption 所有成员设置需相同,默认OFF

• Lower Case Table Names
  lower_case_table_names 所有成员设置需相同,默认0

• Binary Log Dependency Tracking
  binlog_transaction_dependency_tracking 所有成员保持一致, WRITESET_SESSION可以提高性能,默认COMMIT_ORDER,还可选WRITESET,数据安全严格要求下用默认值。
  如果 transaction_write_set_extraction=OFF 那只能为COMMIT_ORDER

• Multithreaded Appliers
  slave_parallel_type = LOGICAL_CLOCK # replica_parallel_type=LOGICAL_CLOCK (from MySQL 8.0.26)
  slave_parallel_workers = 16 # replica_parallel_workers=16 (from MySQL 8.0.26)
  slave_preserve_commit_order = 1 # replica_preserve_commit_order=ON (from MySQL 8.0.26)

18.3.2 Group Replication Limitations

• --upgrade=MINIMAL
• Gap Locks
• Table Locks and Named Locks
• Binary Log Checksums
  从8.0.21支持binlog_checksum=CRC32
• SERIALIZABLE Isolation Level
  多主模式不支持
• Concurrent DDL versus DML Operations.
  多主模式下不能不同server并发对一个对象ddl dml操作。
• Foreign Keys with Cascading Constraints.
• Multi-primary Mode Deadlock.
  多主模式下SELECT .. FOR UPDATE可能导致死锁
• Replication Filters
  千万别配置filter,特别是配置文件(防止意外重启启用),8.0可以查询performance_schema.replication_applier_global_filters,5.7无系统视图
• Encrypted Connections
• Cloning Operations

18.4 Monitoring Group Replication

18.5 Group Replication Operations

18.6 Group Replication Security

18.7 Group Replication Performance

18.8 Upgrading Group Replication

18.9 Group Replication System Variables

18.10 Frequently Asked Questions