目标
掌握mysql在备份和高可用方面提供的解决方案和实现原理。
复制
简介
mysql复制是什么？
一个mysql源服务的数据可以备份到其他的多个mysql副本服务中。
mysql复制是异步还是同步？
默认情况下，复制是异步进行的。副本不需要一直与源保持连接。
mysql复制的对象是什么？
可以对所有数据库、选定的数据库、数据库中某些表进行复制。
mysql复制的价值是什么？
通过备份可以解决性能、备份问题，减轻系统故障影响。副本专门处理读请求，分摊读负载，横向扩展读性能。源服务专注写，提升了写性能。副本可作为备份，当源服务不可用时，可以手动将副本作为源，减轻了故障造成的数据影响。副本还可以用于数据分析。
mysql复制中服务器角色与职责是什么？
mysql服务可以分为两个角色，源数据库与副本。源负责执行事务、提交事务、发送数据给副本。副本负责主动的与源建立连接并发起复制请求。副本请求同步之后，由源向副本发送binlog内容，所以可以理解mysql复制使用的是推的方式。
实现
目前有两种方式可实现复制：基于binlog和基于GTID。
传统方式，基于来自源数据库binary log的复制事件和同步位置。
新方式，使用全局事务标识符GTIDs实现基于事务的复制。只要源数据库的所有已提交的事务被应用到副本，则源和副本间一定是数据一致的。
接下来，我主要从3个部分讲述基于binlog实现的复制。
如何实现异步复制？
每一个源/副本连接都具有3个主要线程。源数据库中，每个连接的副本分别对应一个dump线程。副本中，每个连接的源具有一个接收器线程和一个填充器线程。
| 源数据库端Binary log dump thread | 负责将源数据库的binlog内容发送给保持连接的副本。线程在binlog上加锁，然后读取binlog内容，然后释放锁，发送给副本。SHOW PROCESSLIST指令查看。 |
| 副本端Replication I/O receiver thread | 在副本上执行START REPLICA时，副本会创建一个IO线程。其职责为：与源建立连接，请求源将binlog发送过来，读取binlog dump线程发送的变更内容，拷贝到relaylog中。SHOW SLAVE STATUS指令查看。 |
| 副本端Replication SQL applier thread | 读取副本中的relaylog内容并应用。 |
副本如何存放接收的事件呢？
副本的relayLog，由一批顺序编号的文件和一个索引文件构成。编号文件包含描述数据库变更的事件。索引文件包含所有使用的relayLog文件。relayLog文件保持与binlog文件使用同样的格式。relaylog默认文件名为host_name-relay-bin.nnnnnn，host_name即副本的主机名，nnnn即从000001开始的有序序号。副本使用一个索引文件跟踪当前使用的relaylogs，默认名称为host_name-relay-bin.index。为避免以后因为主机名变更引起错误，建议自定义relaylog名和索引文件名，即使用relay_log and relay_log_index配置。
何时创建一个新的relaylog？
每次启动复制IO线程、当前relay log大小到了上限。
接收器和填充器的上下文存在哪里？
这些上下文数据存放在副本的复制元数据仓库。
| connection metadata repository 连接元数据仓库 | 元数据包括连接配置、复制账户信息、SSL连接配置、正在读取的binlog文件名和位置。用于复制IO线程(接收器)与源数据库建立连接、从源数据库的binlog检索事务。 |
| applier metadata repository 填充器元数据仓库 | 元数据包括填充器已经执行的事务对应的relayLog文件名和位置以及事务在源binlog的位置、填充器工作线程数量等。用于复制sql线程(填充器)读取和应用来自副本relayLog的事务。 |
图示
异步复制
半同步复制，在源数据库上执行事务，在'至少一个副本确认已经收到和记录本次事务'之后，源进行提交事务，返回会话。
?
组复制?
简介
组复制，作为mysql的插件，提供了一种松散的、高可用的、容错的复制解决方案。组复制是innodb集群的重要组件。组复制有两种模式，单主模式和多主模式。单主模式，自动选举主实例且只有主实例接受更新操作。多主模式，所有实例是平等，可并发接受更新操作。组复制保证了数据库服务是持续可用的，但是组复制没有提供连接器、负载均衡器、路由器等，所以需要依赖其他中间件，如mysql router。这样，当客户端连接的组成员不可用时，客户端可被重定向到其他可用的组成员。
实现?
多个实例如何支持事务呢？
组复制协议，支持多源随时更新。一个复制组包含多个server，且每个server随时可以独立执行读写事务，但是只有该读写事务被组承认后才可以被提交。换言之，读写事务是否可以提交是由组判断的，而不是由执行该事务的原始server决定。只读事务不需要这种协作，而是直接提交。
如何告知有待提交的事务？
当一个读写事务已经准备好提交了，原始server向组内其他server发送原子性广播，包括被修改的行(write value)和对应的主键(write set)。因为使用原子广播，所以保证组内所有server都收到广播信息或都收不到信息。保证组内所有server接收到顺序相同的事务集合。
事务会不会产生冲突？
当多个server并发执行事务时，由证明流程(certification)负责对事务进行判定，它会检查比较write set，如果多个事务变更同一行数据，则认为产生冲突。
如何解决冲突？
冲突解决方案：允许多个冲突事务中顺序第一的事务进行提交，并且终止其他冲突事务。
举例说明
不同server上执行的事务t1和t2产生冲突，t1的顺序为10，t2的顺序为11，则允许t1提交，回滚t2。单主组复制不会发生冲突，多主组复制可能出现冲突。
组复制协议图示
关于运行模式， 可通过group_replication_single_primary_mode进行配置，默认ON使用单主模式。OFF表示多主模式。必须在组内所有server上进行同样的配置。
接下来讲述单主模式。
在单主模式中，主实例是引导组启动的第一个服务，加入到组的其他实例需要学习主实例并自动设置为只读模式，只有主实例是读写模式。当主实例不可用后，组内自动投票选举出新的主实例。
如何自动选举主实例？
在自动选举主实例过程中，每个成员在本地查看新的组视图，对所有成员进行排序，选出最合适的成员作为主实例。选举规则概述为mysql版本最低且server_uuid最小的成员获胜。
?接下来讲述多主模式。
多主模式中所有成员是平等，没有特殊角色，都负责读写，不需要进行选举。当某个成员退出组后，则连接它的客户端需要被重定向另一个可用成员，这个流程需要依赖其他中间件，如mysql router。
接下来描述组复制插件的架构。
插件和mysql server如何解耦？
插件与mysql server之间通过事件实现了解耦。
| 第一层：APIs层负责与mysql server进行交互，接收事件； |
| 第二层：负责处理事件，capture复制跟踪事务上下文，applier负责执行其他实例执行的事务、recovery负责分布式恢复； |
| 第三层：组复制协议，负责冲突判定、在组内接收和传播事务； |
| 第四层：更高层的API，抽象了用于构建一个复制状态机的多种特性，对上三层和通信层进行解耦。 |
| 第五层：组通信引擎，负责组内成员分布式交互的通信。 |
总结
mysql复制提供了备份解决方案，可做读写分离，提升性能；但是复制存在单点问题，无法自动切换源数据库。?mysql组复制提供了高可用解决方案，作为innodb集群重要组件，支持单主和多主两种模式，但是需要使用第三方的中间件作为连接器、路由器、负载均衡器。