前期回顾
这期的专题我们来介绍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 )
主库一般是引导组的那个，后续加入的组会通主库进行通信然后设置为只读
当组处于单主模式时，一些在多主模式下不允许的操作是可以进行的，如修改带有级联约束的外键的表
当主库故障时，选举进程(election process) 根据group_replication_member_weight的值来选择新的主库
我们假设组中所有成员的数据库版本是一致的，则group_replication_member_weight的值最高的被选举为新的主库，如果该值一致则按照uuid的词典排序，选择最先的那个，这时该数据库被设置为读写。
新的主库只会在同步完旧的主库的事务后才会设置为读写
如果组中的成员数据库版本不一致的情况下，比如不支持group_replication_member_weight参数，则此时只会根据uuid来选择，如果所有的数据库都支持该参数，则和上面版本都一致的选举方式一致
3. 多主模式
多主模式下所有数据库都是读写模式
4. 参考资料
https://dev.mysql.com/doc/refman/5.7/en/group-replication-operations.html