## 业务背景 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 的领先策略进行调整。