mgr test1

介绍

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

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,则按小版本排序。如果任何成员<MySQL 8.0.16,则按主要版本排序,忽略小版本。
    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

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 213,047评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,807评论 3 386
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 158,501评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,839评论 1 285
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,951评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,117评论 1 291
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,188评论 3 412
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,929评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,372评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,679评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,837评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,536评论 4 335
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,168评论 3 317
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,886评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,129评论 1 267
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,665评论 2 362
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,739评论 2 351

推荐阅读更多精彩内容