码迷,mamicode.com
首页 > 数据库 > 详细

MySQL 高可用之 MGR

时间:2019-08-15 17:12:23      阅读:513      评论:0      收藏:0      [点我收藏+]

标签:网络   tran   for   必须   proxy   res   orm   问题:   lz4   

 

 

MGR整体架构及特点

  single-master

    只有一个节点写入,都可以读取

  multi-master

    每个节点都可以写入和读取

  涉及到的概念:

    group communication system (GCS)

    writeset

    membership

    cerification info

    flow control stats

    paxos

  MGR一致性读增强

  group_replication_consistency (8.0.14引入)

    EVENTUAL: 默认

    BEFORE: 等待队列中的事务全部执行完

    BEFORE_ON_PRIMARY_FAILOVER: 等待新primary执行完队列中事务

    AFTER: 等待数据变更在其他所有节点全部被应用

    BEFORE_AND_AFTER: 

  MGR限制

    仅支持InnoDB,必须有主健

    Binlog 格式: Row,关闭binlog checksum  

    必须开启GTID

    事务隔离级别: READ COMMITTED (没有 gap lock)  

    大事务限制: group_replication_transaction_size_limit

    Multi master模式:避免相同表上不同节点并发执行DDL/DML

    集群最大节点; 9 (奇数个数)

 

MGR数据如何实现数据同步

  MGR的数据复制 -> 事务认证

    事务认证

    冲突检测

      certification_info key: xxhash64(索引名称+db名+db名长度+表名+表名长度+构成索引唯一性的每个列的值+值长度) Value 是事务的 gtid_executed

      事务分配 gtid

      group_replication_gtid_assignment_block_size

    事务组提交 (group commit)

 

MGR数据复制冲突解决

  问题:

    对于告诉写入的系统 centification_info 会越来愈大,性能会越来越差?

  处理办法:

    centification_info 引入清理机制

 

MGR数据复制流控

Flow Control

  流控目的

    保证集群延迟可控 (对于只读事务不在流控范围之内)

  出现流控原因

    各节点性能不一致

    木桶短板效应

  参数

    group_replication_flow_control_mode 默认为: quota 开启流控

    group_replication_flow_control_period 多久进行一次流控统计,单位:秒

    group_replication_flow_control_applier_threshold & group_replication_flow_control_certifier_threshold 事务认证队列中积累超过多少个待认证的事务才触发节点流控

 

 

MGR监控点

  当前节点是不是在线

    select member_state from performance_schema.replication_group_members;  

  是不是存在延迟

    获取到的: select received_transaction_set from performance_schema.replication_connection_status;

    已经执行的: select @@gtid_executed

  当前队列是不是有积压

    select count_transaction_in_queue from performanct_schema.replication_group_member_stats where member_id=@@server_uuid;

  当前节点是不是可写

    select * from performance_shcema.global_variables where variable_name in (‘read_only‘,‘super_read_only‘);

  

MGR优化方向

  运维上

    运维基本复制结构,所有的数据复制,还是逻辑的重放,所以优化也是复制优化点。

    更改:

      slave_parallel_type -> LOGICAL_CLOCK

    增强 SQL_THREAD 个数:

      slave_parallel_workers -> 2-8

    如果CPU瓶颈,网络没问题,减少CPU压缩:

      group_replication_compression_threshold = 1000000 ->  2000000

      由原来的1M变成2M,再进行压缩(主要针对大事务传输优化)

  对于写量毕竟大环境

    使用single-master

    表结构设计上:减少索引数量,多使用联合索引

  内核上

    已经尝试: static const int BROADCASE_GTID_EXECUTED_PERIOD = 60>30; //seconds

  重要参数:

    group_replication_member_expel_timeout (8.0.13+) 

      (5+X) 秒后,节点从group中移除失恋成员

      网络异常 -> 5秒 -> 失联猜测 -> X秒 / UNREACHABLE -> 移除 

      X 秒内,group无法增加节点,删除节点,选举Primary

    group_replication_unreachable_majority_timeout

      发生网络分区后,minorty成员X秒内未能恢复连接到majority,进入ERROR

    group_replication_exit_state_action (8.0.12+, 5.7.24+)

      ABORT_SERVER / READ_ONLY

      aplier执行错误 / 与 majority失联 / 网络波动被移除group

    group_replication_recovery_complete_at

      TRANSACTIONS_CERTIFIED / TRANSACTIONS_APPLIED

    group_replication_member_weight

      single primary 下, 节点角色不对等情况下有用

      相同group_replication_member_weight, 取决于 server_uuid

    group_replication_transaction_size_limit (5.7.19+)

      限制单个事务最大字节数,可控制网络开销,内存分配,冲突概率

    group_replication_compression_threshold

      超过X字节后,开启LZ4压缩事务传输,默认1MB 

 

MGR部署架构建议

  MySQLrouter + MGR  

    router: 两个接口 (read, insert)

    需要关注一下MySQL的X协议,js相关的相关操作

    建议使用ProxySQL替代

  如果为了性能 : Single-master

  使用方便: Multi-master (单点写入,多点读取)

 

 

 

MySQL 高可用之 MGR

标签:网络   tran   for   必须   proxy   res   orm   问题:   lz4   

原文地址:https://www.cnblogs.com/yujiaershao/p/11357932.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!