MGR架构~高可用架构细节的梳理

一 简介:今天咱们来聊聊mgr的细节原理相关

二 选择新主机制
   1 当主节点宕掉，自动会根据服务器的server_uuid变量和group_replication_member_weight变量值，选择下一个slave谁作为主节点，group_replication_member_weight的值最高的成员被选为新的主节点，
   2 在group_replication_member_weight值相同的情况下，group根据数据字典中 server_uuid排序，排序在最前的被选择为主节点
  3 调整权重后不能像mongo一样自动识别进行切换.只能主动触发故障。
三  新主成员构成
  1 一旦集群故障的节点超过阈值,整个集群变会被挂起,成为只读的状态,比如 3个节点,一旦挂掉2个 就会导致集群只读  
    计算方式 2n+1=total, n为故障节点的阈值
  2 单个节点的状态只有到ERROR时才会被认为是不可用,踢出集群,视图发生变更
四 视图成员状态说明
  ONLINE 表示该节点可正常提供服务
  RECOVERING 表示当前节点正在从其他节点恢复数据
  OFFLINE 表示GR插件已经加载，但是该节点不属于任何一个GR组
  ERROR 表示节点在recovery阶段或者从其他节点同步状态中出现错误
  UNREACHABLE表示节点处于不可达状态，无法与之发生网络通讯
五 写集合
 1 主键在MGR中主键是有着极其重要的地位，是判断是否冲突的重要依据,所以规定表必须有主键 
 2 写集合信息会封装进Transaction_context_log_event，同其他binlog event信息一起发送给其他节点
六 本身限制
 1 仅支持InnoDB表，并且每张表一定要有一个主键，用于做write set的冲突检测；
 2 目前一个MGR集群最多支持9个节点
 3 不支持外键于save point特性，无法做全局间的约束检测与部分部分回滚
 4 二进制日志不支持binlog event checksum

5 对大事务的限制

七 总结

本文章只代表个人观点,有问题及时联系我,此文章会持续进行补充