## 前期回顾 这期的专题我们来介绍MySQL组复制相关的内容 | 主机名 |业务IP|私有IP |复制用户|角色 | --- | --- | --- | --- | ---| | rac1 | 11.12.14.29| 10.10.10.11 |rpl|主| | rac2| 11.12.14.30| 10.10.10.12|rpl|从| | rac3 | 11.12.14.39 | 10.10.10.13|rpl|从| 上节我们说了MGR环境的监控,这节的内容介绍MGR单主和多主的一些知识 ## 1.两种模式简介 MGR可以工作在两种模式下 - 单主模式(single-primary mode) - 多主模式(multi-primary mode) 默认的模式为单主模式,一个组内不能同时有多种模式存在 如果需要切换,我们需要以不同的配置来重启组而不是数据库 MGR不处理客户端的fail over 当我们需要部署成多主模式,会需要强制检查一些语句防止冲突的发生 通过设置group_replication_enforce_update_everywhere_checks 参数来设置 - 数据库不能处于SERIALIZABLE 隔离级别,否则提交会出错 - 如果事务对foreign keys with cascading constraints的表进行修改,则提交也会失败 ## 2.单主模式 单主模式中只有第一台是读写模式的,其他的都会是只读模式(super-read-only=ON ) 主库一般是引导组的那个,后续加入的组会通主库进行通信然后设置为只读 [image:725 size:orig] 当组处于单主模式时,一些在多主模式下不允许的操作是可以进行的,如修改带有级联约束的外键的表 当主库故障时,选举进程(election process) 根据group_replication_member_weight的值来选择新的主库 [image:726 size:orig] 我们假设组中所有成员的数据库版本是一致的,则group_replication_member_weight的值最高的被选举为新的主库,如果该值一致则按照uuid的词典排序,选择最先的那个,这时该数据库被设置为读写。 新的主库只会在同步完旧的主库的事务后才会设置为读写 如果组中的成员数据库版本不一致的情况下,比如不支持group_replication_member_weight参数,则此时只会根据uuid来选择,如果所有的数据库都支持该参数,则和上面版本都一致的选举方式一致 ## 3. 多主模式 多主模式下所有数据库都是读写模式 [image:727 size:orig] ## 4. 参考资料 [https://dev.mysql.com/doc/refman/5.7/en/group-replication-operations.html](https://dev.mysql.com/doc/refman/5.7/en/group-replication-operations.html)