数据库开发者社区 > 正文

数据库内核月报 - 2015 / 09-MySQL · 备库优化 · relay fetch 备库优化

简介:
+关注继续查看

业务背景

MySQL 主备通过 binlog 实现数据同步的功能,主库将生成的 binlog 通过 binlog send 线程发送到备库,备库通过应用这些 binlog 来更新数据,实现主备数据一致,其应用 binlog 的读取操作与更新操作的堆栈分别如下。

读取操作:

#0  row_search_for_mysql
#1  0x0000000000c200c2 in ha_innobase::index_read
#2  0x0000000000c21c57 in ha_innobase::rnd_pos
#3  0x000000000090c5d3 in handler::rnd_pos_by_record
#4  0x0000000000a574c3 in Rows_log_event::find_row
#5  0x0000000000a589da in Delete_rows_log_event::do_exec_row
#6  0x0000000000a50dcc in Rows_log_event::do_apply_event
#7  0x00000000005d0bb8 in Log_event::apply_event
#8  0x00000000005b9782 in apply_event_and_update_pos
...

更新操作:

#0  row_update_for_mysql
#1  0x0000000000c1f466 in ha_innobase::delete_row
#2  0x000000000090b64a in handler::ha_delete_row
#3  0x0000000000a58a4b in Delete_rows_log_event::do_exec_row
#4  0x0000000000a50dcc in Rows_log_event::do_apply_event
#5  0x00000000005d0bb8 in Log_event::apply_event
#6  0x00000000005b9782 in apply_event_and_update_pos
...
  • 由堆栈可以看出,sql 线程首先将数据从磁盘加载到内存,然后调用引擎层的接口执行相应的操作,当iops 及 buffer pool 较小时,读磁盘需要较多的时间,容易造成主备延迟问题;
  • 当系统重启后,需要对系统进行预热,提高 buffer pool 的命中率,因此需要提供有效的方法来对系统进行预热;

综上,我们需要一种可以在 DML 操作之前将数据从磁盘加载到内存的功能,以实现数据库的快速操作。

解决方法

我们需要找到一种将数据加载到内存的方法,但又不对数据进行修改,需要满足以下的条件:

  • 在库上更新的数据应该在备库操作之前被加载到内存中;
  • 对于重启的mysqld实例,应该将启动之前所用的数据页加载到内存中;
  • 加载操作对数据本身不进行修改,类似于select 语句。

因此,我们可以在mysqld启动时启动额外的线程对 relay log 进行特殊处理,以达到数据加载的目的。

设计思路 & 使用方法

RDS MySQL 利用 relay log 来解决上述两个问题,当系统启动后,可以在后台开启一个独立于SQL thread之外的线程将 relay log 相关的数据从磁盘加载到内存中,从而使备库在查找数据的时候直接利用buffer pool,而不需要从磁盘中进行加载,同理,使用这种方法也可以解决系统预热的问题。

当启动后,如果发现延迟且 buffer pool 命中率较低时,可以启用 relay fetch thread, 具体语法为:

启动 relay_fetch_thread: start slave relay_fetch_thread;
停止 relay_fetch_thread: stop slave relay_fetch_thread;

relay fetch thread 读取relay log, 并将要执行的数据从磁盘上加载到内存中,所以只能对包含数据部分的 log_event 进行操作,对 Query_log_event,Write_rows_log_event 是无法进行预读的,前者是因为Query_log_event 只是SQL语句,不包含具体的数据信息;后者则是event中没有的数据,所以不需要进行加载,另外为了防止 buffer pool 中读取的 page 被 evict 出去,我们需要对两种情况进行分别处理:

  1. relay fetch thread 不能领先 sql thread 过多,如果领先过多的 relay log files,当 buffer pool 较小时,新加载进来的数据页会将老的数据页从内存中 evict 出去,对 sql thread 的命中率会有直接的影响;
  2. 当 sql thread 领先 relay fetch thread 时,此时 relay fetch thread 不需要将已执行完的 relay log 加载到内存,继续加载不仅会有命中率的问题,同时会造成 CPU 不必要的资源浪费。

因此,relay fetch thread 与 sql thread 应该相差的距离不太远,我们的策略是 relay fetch thread 与 sql thread 应该在同一个 relay log 上,具体策略如下:

  1. 如果 relay fetch thread 领先, 则当 relay fetch thread 读完一个文件后要等待 sql thread,直到 sql thread 应用完此relay log 再继续加载;
  2. 如果 sql thread 领先,则会通知 relay fetch thread 跳过当前执行的文件并用 sql thread 的位点来初始化自己将要执行的起点;

relay fetch thread 执行过程的伪码如下:

handle_slave_relay_fetch
{
   init_thd_and_rli();
   while (!relay_fetch_killed(eli))
   {
       ev= Log_event::read_log_event(&rli->relay_log_buf, 0, rli->relay_log.description_event_for_relay_fetch);
       if (ev == NULL) 
       { 
          deal with situations like hot_log, relay log purged, eof of relay log etc.
       }
       else
       {
             switch(ev->get_type_code())
             {
                case QUERY_EVENT:
                   deal with begin, commit 
                   break;

                case XID_EVENT:
                   deal with xid(commit)
                   break;

               case TABLE_MAP_EVENT:
                   init table info for rows log event
                   break;

               case UPDATE_ROWS_EVENT:
               case DELETE_ROWS_EVENT:
                  find_row();
                  break;

               case FORMAT_DESCRIPTION_EVENT:
                  init description_event_for_relay_fetch for reading binlog event;
               default:
                  break;
             }
             delete ev;
       }
   }
}

实现过程中注意的细节

  • 由于 relay fetch thread 在加载数据的过程中会对记录进行加锁,所以在遇到begin, commit 的事件时,需要释放在读取过程中获取的所有锁资源,否则有可能会引起 sql 线程锁超时错误;
  • 由于 relay fetch thread 的位点是使用 sql thread 的位点进行初始化的,所以需要处理 relay log 不是完整事务的情况;
  • 释放 relay fetch thread 在执行过程中使用到的内存,否则会有内存问题;
  • 在 relay fetch thread 执行的过程中需要特别注意 log_lock、run_lock 等锁问题,以避免备库的死锁;
  • 需要对 relay log 的purge进行特殊处理;
  • 如果是系统预热的功能,则需要对 relay fetch thread 与 sql thread 的领先策略进行调整。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
PolarDB-X内核新版本:将MySQL进行到底
在PolarDB-X最新的内核版本5.4.15中,提供诸多新功能:存储过程,读写分离优化,表级分区管理,密码、审计优化等。
158 0
TDSQL中修复的mysql内核bug
在TDSQL这两年多的开发工作中,我感觉很自豪的一件事是我修复了不少mysql-5.7.17和mariadb-10.1.9的内核bug,这些bug大多已经报告给了MySQL/MariaDB官方开发团队,在每个bug描述中我会贴出来bug报告的连接。本文将大略介绍这些bug的概况,我在将来会写更多文章详细介绍每个bug的具体问题分析以及解决思路。本文列出的所有bug都已经修复,经过验证可以正确工作并解决相关问题。 这里先说一下为什么我要提交代码给mysql/mariadb官方开发团队,主要有一下几个好处: 1. 官方开发者可以review我提交的patch,帮助完善patch,发现和解决之前
192 0
MySQL · 内核特性 · 统计信息的现状和发展
简介我们知道查询优化问题其实是一个搜索问题。基于代价的优化器 ( CBO ) 由三个模块构成:计划空间、搜索算法和代价估计 [1] ,分别负责“看到”最优执行计划和“看准”最优执行计划。如果不能“看准”最优执行计划,那么优化器基本上就是瞎忙活,甚至会产生严重的影响,出现运算量特别大的 SQL ,造成在线业务的抖动甚至崩溃。在上图中,代价估计用一个多项式表示,其系数 c 反应了硬件环境和算子特性,而
190 0
关于MySQL内核,一定要知道的!
近一个多月,写了一些MySQL内核的文字,稍作总结,希望对大家有帮助。1.《InnoDB,为何并发如此之高?》 文章介绍了: (1)什么是并发控制; (2)并发控制的常见方法:锁,数据多版本; (3)redo,undo,回滚段的实践; (4)InnoDB如何利用回滚段实现MVCC,实现快照读。
2043 0
MySQL · 引擎特性 · MySQL内核对读写分离的支持
读写分离的场景应用 随着业务增长,数据越来越大,用户对数据的读取需求也随之越来越多,比如各种AP操作,都需要把数据从数据库中读取出来,用户可以通过开通多个只读实例,将读请求业务直接连接到只读实例上。使用RDS云数据库的读写分离功能,用户只需要一个请求地址,业务不需要做任何修改,由RDS自带的读写分离中间件服务来完成读写请求的路由及根据不同的只读实例规格进行不同的负载均衡,同时当只读实例出现故障时能够主动摘除,减少对用户的影响。
1521 0
MySQL · 引擎特性 · Group Replication内核解析之二
背景 前文已经介绍了MySQL的Group Replication的实现机制和原理,本文就Group Replication的具体实现进行详细的阐述,以更深入的理解Group Replication的机制,在实践中更好的应用Group Replication,提升应用系统的可用性,优化其性能。
1557 0
MySQL · 引擎特性 · Group Replication内核解析
背景 为了创建高可用数据库系统,传统的实现方式是创建一个或多个备用的数据库实例,原有的数据库实例通常称为主库master,其它备用的数据库实例称为备库或从库slave。当master故障无法正常工作后,slave就会接替其工作,保证整个数据库系统不会对外中断服务。master与slaver的切换不管是主动的还是被动的都需要外部干预才能进行,这与数据库内核本身是按照单机来设计的理念悉悉相关,并且数
4797 0
数据库领域前沿技术分享与交流
热门文章
热门讨论
+关注
db匠
rds内核团队秘密研发的全自动卖萌机. 追加特效: 发数据库内核月报. 月报传送: http://mysql.taobao.org/monthly/
文章
问答
视频
相关电子书
更多
高效MySQL的N个习惯
立即下载
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
相关镜像