https://dev.mysql.com/doc/refman/8.0/en/group-replication-frequently-asked-questions.html
最大9个
他们直接是通过peer-to-peer TCP连接,主要用作内部交流和信息传递
通过group_replication_local_address 可以设置相关的地址
bootstrap flag,主要用作创建一个group,然后扮演一个初始化server的角色
第二个成员加入到组,需要问bootstrap server来动态调整配置,以便自己能够顺利加入该组
一个成员bootstrap一个组的场景大概2个:
提前配置一个GR的恢复通道credentials,使用CHANGE MASTER TO 语句
a)并不是直接的扩展方式,因为MGR的每一个成员都有完整的数据copy
b)但是,其他server并不是做完全一样的写动作,因为MGR通过ROW模式复制,其他server只需要apply row即可,并不是re-executed事务了,因此会快且压力小很多
c)更进一步讲,row-based应用都是经过压缩过的,可以减少很多IO动作,相比master上的执行压力会小很多的
d)总结,你可以scale-out写,在没有写冲突事务的时候在多台服务器上执行事务是可以做到scale-out的。
是会有一些额外的压力产生,因为MGR需要不断的沟通协作来保证同步的目的,但是很难计算出高出多少资源
可以,但是要保证他们的可靠和合适的网络性能
低延迟、高吞吐是MGR的基本配备条件
如果网络带宽是问题,可以使用 Section 18.10.7.2, “Message Compression” 方法来降低带宽的所需
但是如果网络丢包,导致的数据重传会严重影响性能
这取决于是什么网络问题
如果网络问题是短暂的,瞬间的,那么MGR的错误检测机制根本还没来得及探测到此问题,那么该成员是不会被移除出组的
如果是长时间的问题,那么错误检测机制最终会认为它除了问题,会将此server移除出组
一旦移除出组,你就需要让他重新加入一次,换句话说,你需要手工来处理,或用脚本来自动处理
如果一个server变成了孤岛,其他成员会从组配置中将其移除出组
一般这种情况发生在 server挂了,或网络disconnect了
在指定的timeout后,这个错误被检测出来,然后一个新的没有该成员的配置会重新生成
没有一个很好的策略来自动判断什么时候去驱逐一个成员
你需要找到为什么它会延迟,并解决它,或移除它
否则,当一个server慢到触发流控,然后整个group都会变的慢下来
流控可以根据你喜好来配置
没有。
每个member都是一样的,你无法控制和设置
无法对MRG成员进行sharding,但是你可以设计,以MGR作为sharding的一个分片,即: MGR1 是一个分片,MGR2是另外一个分片
可以,需要额外配置和过滤
STOP GROUP_REPLICATION, START GROUP_REPLICATION,这样MGR会再次创建一个group_replication_applier 通道
MGR使用两个绑定地址,主要是为了区分 SQL地址(业务应用ip来连接server) 和 group_replication_local_address (成员内部通信)
主要是为了隔离和安全
如果是single-primary,你可以使用Section 18.4.1.3, “Finding the Primary”的方法,轻松找到primary
sql> SELECT MEMBER_HOST, MEMBER_ROLE FROM performance_schema.replication_group_members;
+-------------------------+-------------+
| MEMBER_HOST | MEMBER_ROLE |
+-------------------------+-------------+
| remote1.example.com | PRIMARY |
| remote2.example.com | SECONDARY |
| remote3.example.com | SECONDARY |
+-------------------------+-------------+
mysql> SHOW STATUS LIKE 'group_replication_primary_member'