今天的记录内容是mysql的组复制
首先是搭建组复制，三台服务器教程：https://blog.csdn.net/hello_xiaozhuang/article/details/81570516
https://www.docs4dev.com/docs/zh/mysql/5.7/reference/group-replication-configuring-instances.html（官方例子）
当然仍然可以采用方便的docker: https://www.jianshu.com/p/43c80b5e8764
组复制还有额外多一个router节点的搭建方式：https://www.cnblogs.com/williamzheng/p/11347362.html
主次复制默认是异步复制，一个事务在主节点成功提交后，该事务就代码成功，从节点中事务的回放是异步进行的。
半同步复制:主库在执行完客户端提交事务后不是立刻返回给客户端，而是等待–(至少一个)–从库接受到并写到relay log 中才返回给客户端(通过配置rpl_semi_sync_master_enabled = 1，开启)
全同步也叫组复制：复制组由多个 server成员构成，并且组中的每个 server 成员可以独立地执行事务
但所有读写（RW）事务只有在冲突检测成功后才会提交。只读（RO）事务不需要在冲突检测，可以立即提交。（全同步也不是等所有节点都执行事务成功后才代表事务完成，半数以上的节点同意并且达成共识即可）
MySQL 组复制提供了高可用性，高弹性，可靠的 MySQL 服务
MGR具备以下技术特点：
MGR是基于Paxos协议和原生复制的分布式集群，多数节点同意即可以通过事务提议（Proposed），实现数据一致性。
具备高可用、自动故障检测功能，可自动切换。
可弹性扩展，集群自动的新增和移除节点，集群最多接入9个节点。
有单主和多主模式。支持多节点写入，具备冲突检测机制，可以适应多种应用场景需求
基于组复制(MGR)的机制，当主节点宕机离开集群，剩余的其他节点会基于paxos协议选举一个新的主节点。这里有一个问题，应用程序端如果连接到了主节点，这时主节点宕机离开集群，可用的数据库IP地址发生变化，客户端应用程序这个时候还是会向失败的节点尝试连接，虽然可以修改客户端应用程序的连接配置，但是这种情况基本是不现实的。
MySQL Router在InnoDB集群里面的角色，主要作用是为数据库集群提供一个虚拟IP作为应用程序单一连接点，通过这个单一的连接点实现负载均衡，读写分离，故障转移等数据库高可用方案。
MySQL Router抽离出集群的信息，有点像微服务的注册中心中心作用，提高集群可扩展性
具体可参考：
https://blog.csdn.net/n88Lpo/article/details/115910974
https://omg-by.github.io/2020/06/27/new/MySQL/MySQL%E4%B9%8BMGR%E5%88%9D%E6%B6%89/
