首页 > 代码库 > [转载]阿里云MySQL优化主从同步,降低数据延迟
[转载]阿里云MySQL优化主从同步,降低数据延迟
1. 背景
为了提高系统的可用性和数据保护,MySQL通常采用master-slave的部署结构,简单高效,master和slave之间使用binlog来复制数据。
binlog支持statement和row格式,为了保证数据的一致性,通常采用row格式的event。master-slave的结构图如下:
当主库或者主库所在的主机,机房出现异常情况的时候, 进行master和slave主备切换,让slave来提供不间断的服务。主备进行切换最重要的前提就是:slave节点已经apply完毕master节点所生成的binlog,也就是slave和master处在一致的状态。
如上master-slave的结构图所示,
1. slave端的IO thread首先接收master端生成的binlog
2. slave端的SQL thread开始应用所接收的binlog
由于步骤1的瓶颈在于网络,通常情况下,binlog都能够很快传输到备库。
步骤2需要把row event变更到引擎中,由于是逻辑行的处理,需要索引的查找过程。
所以,大部分的瓶颈点都出在步骤2上,其决定了备库何时能够切换到主库,MySQL也一直在致力于加速binlog的apply。
接下来我们看下RDS MySQL做的一些优化。
2. 二级索引
InnoDB Row event apply的过程, 需要根据before image进行BTree查找, 例如update row, delete row。早期只能根据pk或者uk进行索引查找,如果用户在建表的过程中,只建了普通的二级索引,在备库binlog apply的时候,需要进行全表扫描,这样,每一个row event都需要进行全表扫描,效率非常低,严重影响备库的恢复进度。
RDS在备库apply row event的时候,进行了优化,其优化原则是:
1. 如果有pk或者uk,就直接使用
2. 如果没有pk或者uk,就选择一个二级索引
3. 如果没有二级索引,就选择全表扫描
这样优化后,如果二级索引的选择性比较高,apply的速度也会有很大的提升。
3. 隐含主键
前面我们假设用户如果没有pk或者uk,而创建了普通的二级索引的情况, 如果用户没有创建任何的索引,RDS会帮助用户创建一个隐含主键,如下图所示:
这个隐含的column是auto_increment的,对用户是隐藏的,并且使用也是透明的,这样每一张表没有pk或者uk的表, 就会默认有一个隐含主键,加速备库的apply速度。
4. 只读实例隐式提交
在只读实例上, 一方面用户进行只读查询, 另一方面sql thread进行row event apply,如果用户的查询没有自动提交来释放MDL锁,随后sql thread进行的ddl变更,就会被阻塞,导致整个apply进程被阻塞。
RDS MySQL增加了一个隐式提交的功能,针对只读实例上,用户read-committed隔离级别的sql,进行隐式提交,即在sql结束后,默认进行一个提交动作,以释放MDL锁,减少阻塞的可能性。
5. 表级并行复制
MySQL 5.6之前, 备库的apply线程, 即SQL thread线程都是串行的在执行row event,严重影响了apply速度,在MySQL5.6之后, 官方支持了以db为维度的并行复制,也就是一个Coordinator thread,即分发线程,和一组worker thread,即工作线程。
其工作如下图:
但DB维度的并行复制,粒度太粗,所以RDS在此基础上,实现了表级别的并行复制,以加速备库恢复的并行度。
[转载]阿里云MySQL优化主从同步,降低数据延迟