MySQL · 优化改进· 复制性能改进过程

**前言** 与oracle 不同，mysql 的主库与备库的同步是通过 binlog 实现的，而redo日志只做为mysql 实例的crash recovery使用。mysql在4.x 的时候放弃redo 的同步策略而引入 binlog的同步，一个重要原因是为了兼容其它非事务存储引擎，否则主备同步是没有办法进行的。 redo 日志同步属于物理同步方法，简单直接，将修改的物理部分传送到备库执行，主备共用一致的 LSN，只要保证 LSN 相同即可，同一时刻，只能主库或备库一方接受写请求； binlog的同步方法属于逻辑复制，分为statement 或 row 模式，其中statement记录的是SQL语句，Row 模式记录的是修改之前的记录与修改之后的记录，即前镜像与后镜像；备库通过binlog dump 协议拉取binlog,然后在备库执行。如果拉取的binlog是SQL语句，备库会走和主库相同的逻辑，如果是row 格式，则会调用存储引擎来执行相应的修改。 本文简单说明5.5到5.7的主备复制性能改进过程。 replication improvement (from 5.5 to 5.7) **(1) 5.5 中，binlog的同步是由两个线程执行的** io_thread: 根据binlog dump协议从主库拉取binlog, 并将binlog转存到本地的relaylog； sql_thread: 读取relaylog，根据位点的先后顺序执行binlog event，进而将主库的修改同步到备库，达到主备一致的效果； 由于在主库的更新是由多个客户端执行的，所以当压力达到一定的程度时，备库单线程执行主库的binlog跟不上主库执行的速度，进而会产生延迟造成备库不可用，这也是分库的原因之一，其SQL线程的执行堆栈如下： ~~~ sql_thread: exec_relay_log_event apply_event_and_update_pos apply_event rows_log_event::apply_event storage_engine operation update_pos ~~~ (2) **5.6 中，引入了多线程模式，在多线程模式下，其线程结构如下** io_thread: 同5.5 Coordinator_thread: 负责读取 relay log，将读取的binlog event以事务为单位分发到各个 worker thread 进行执行，并在必要时执行binlog event（Description_format_log_event， Rotate_log_event 等）。 worker_thread: 执行分配到的binlog event，各个线程之间互不影响； **多线程原理** sql_thread 的分发原理是依据当前事务所操作的数据库名称来进行分发，如果事务是跨数据库行为的，则需要等待已分配的该数据库的事务全部执行完毕，才会继续分发，其分配行为的伪码可以简单的描述如下： ~~~ get_slave_worker if (contains_partition_info(log_event)) db_name= get_db_name(log_event); entry {db_name, worker_thread, usage} = map_db_to_worker(db_name); while (entry->usage > 0) wait(); return worker; else if (last_assigned_worker) return last_assigned_worker; else push into buffer_array and deliver them until come across a event that have partition info ~~~ **需要注意的细节** * * 内存的分配与释放。relay thread 每读取一个log_event, 则需要 malloc 一定的内存，在work线程执行完后，则需要free掉； * 数据库名 与 worker 线程的绑定信息在一个hash表中进行维护，hash表以entry为单位，entry中记录当前entry所代表的数据库名，有多少个事务相关的已被分发，执行这些事务的worker thread等信息； * 维护一个绑定信息的array , 在分发事务的时候，更新绑定信息，增加相应 entry->usage, 在执行完一个事务的时候，则需要减少相应的entry->usage； * slave worker 信息的维护，即每个 worker thread执行了哪些事务，执行到的位点是在哪，延迟是如何计算的，如果执行出错，mts_recovery_group 又是如何恢复的； * 分配线程是以数据库名进行分发的，当一个实例中只有一个数据库的时候，不会对性能有提高，相反，由于增加额外的操作，性能还会有一点回退； * 临时表的处理，临时表是和entry绑定在一起的，在执行的时候将entry的临时表挂在执行线程thd下面，但没有固化，如果在临时表操作期间，备库crash，则重启后备库会有错误； **总体上说，5.6 的并行复制打破了5.5 单线程的复制的行为，只是在单库下用处不大，并且5.6的并行复制的改动引入了一些重量级的bug** * * mysql slave sql thread memory leak ([http://bugs.mysql.com/bug.php?id=71197](http://bugs.mysql.com/bug.php?id=71197)) * Relay log without xid_log_event may case parallel replication hang ([http://bugs.mysql.com/bug.php?id=72794](http://bugs.mysql.com/bug.php?id=72794)) * Transaction lost when relay_log_info_repository=FILE and crashed ([http://bugs.mysql.com/bug.php?id=73482](http://bugs.mysql.com/bug.php?id=73482)) (3) 5.7中，并行复制的实现添加了另外一种并行的方式，即主库在 ordered_commit中的第二阶段的时候，将同一批commit的 binlog 打上一个相同的seqno标签，同一时间戳的事务在备库是可以同时执行的，因此大大简化了并行复制的逻辑，并打破了相同 DB 不能并行执行的限制。备库在执行时，具有同一seqno的事务在备库可以并行的执行，互不干扰，也不需要绑定信息，后一批seqno的事务需要等待前一批相同seqno的事务执行完后才可以执行。 详细实现可参考：[http://bazaar.launchpad.net/~mysql/mysql-server/5.7/revision/6256](http://bazaar.launchpad.net/~mysql/mysql-server/5.7/revision/6256) 。 reference：[http://geek.rohitkalhans.com/2013/09/enhancedMTS-deepdive.html](http://geek.rohitkalhans.com/2013/09/enhancedMTS-deepdive.html)