这期的专题我们来介绍MySQL组复制相关的内容
传统的MySQL复制采用主从的方式进行,可以一主一从也可以一主多从
主库执行一个事务,提交后稍后异步的传送到从库中
如果是基于语句的复制则会重新执行
如果是基于行的负责则会应用日志
同时是shared-nothing的架构,即所有服务器拥有同样的数据复制
MySQL也提供了一个半同步复制,即同步复制,其要求主库在commit时等待从库接受 完事务并返回确认信息后才能提交
组复制是一种可以用来部署容错系统的技术,复制组中的服务器通过massage passing来进行交互
通信层通过atomic message 和 total order message delivery来保证组内成员数据的一致性
所有的读-写(RW)操作需要组内所有成员都通过才可提交
只读(RO)事务不需要这个过程
组复制的过程
当事务在原始服务器上要求提交后,服务器会自动广播写值(row changed)以及相应的写集(unique identifiers of the rows)
然后一个全局的总的顺序(global total order )为该事务建立了,这意味着所有的服务器按照顺序接受到了该事务,然后所有服务器按照相同的顺序应用该事务
MGR提供一种叫做certification的步骤来解决冲突的问题
当不同服务器同时更新一行,此时则会发生冲突,这时MGR会承认第一个提交的事务,剩下的会被回滚
这也叫做distributed first commit wins 规则
MGR可以让你在组内不是全部或者大多数服务器失效时都可以保证数据库服务的可用
MGR利用一个依赖分布式失败检测器(distributed failure detector)的组成员关系服务(group membership service)来跟踪组内成员的离开(资源的离开或者是意外的离开)
MGR有个分布式恢复程序(distributed recovery procedure)来确保每当有服务器加入组后数据库保持最新
从而使得我们不需要做fail-over,多主架构还可以保证主库宕机时不会阻塞更新,MGR保证数据库服务持续可用
最后需要理解的是虽然MGR可以保证数据库服务器的可用性,但是客户端的连接还是需要重新定向到另外的服务器的。想要达到这个目的,可以考虑MySQL Router,这里就不多作介绍了
如下为一些可能需要MGR的场景,这些名称我也不知道咋翻译,大家
https://dev.mysql.com/doc/refman/5.7/en/group-replication-primary-secondary-replication.html
https://dev.mysql.com/doc/refman/5.7/en/group-replication-summary.html
https://dev.mysql.com/doc/refman/5.7/en/group-replication-examples-of-use-case-scenarios.html
觉得文章不错的欢迎关注,转发,收藏~