MySQL如何实现并发迁移?
年前看到percona的blog关于mydumper的lockless更新,因此萌发了重写mydumper的想法。这篇文章是我对mydumper的分析,以及对之前重写的产品datapumper的思考与实践。
在MySQL的逻辑备份中,mydumper逻辑备份一直以并发和快速著称。mydumper为什么快 ?我们简单的描述下mydumper的设计实现。这里首先用一张图来介绍下mydumper的设计与实现为简单起见,我们以一张大表的备份为例(以mydumper 0.9.1版本,开启less-locking 为列):
关键点:
1.dump 完No-Innodb 以后,锁就可以解开了,因为所有的事物都在flush tables with read lock 以后打开,所以所有的子线程和主线程看到的都是锁住之后的数据,没有新的数据进来。所有的线程看到了一致的数据。
2.由于dump Innodb 的任务,都是由主线程将表进行分解为多个chunk,所以主线程在分解为chunk的时候看到的数据,和任务被多线程执行产出的数据是一致的。
比如: 主线程产生 select c1,c2,c3 from t1 where id>=1 and id<10001 和子线程执行这个sql所对应的数据是一致的。
问题:
1.全局锁在所有的No-Innodb tables 锁住之后就解开了,相对之前的版本(非less locking),锁持有的时间更短了,但还是持有全局锁。
2.导出需要先导出到文件,然后用myloader到目标库。
改进点:
1.位置信息获取无需全局锁,通过主线程以RR(repeat read)开启事物后,通过Binlog_snapshot_file/Binlog_snapshot_position获取。
2.所有子线程无需全局锁,可以看到一致的数据(percona支持 START TRANSACTION WITH CONSISTENT SNAPSHOT FROM SESSION session_id)。
例如:A连接开启事物,则B可以克隆A的事物,并看到和A相同的内容,C可以克隆B或者A的事物,并看到和A一样的内容。(这里的session_id为连接的id,及processlist 输出的ID)。
3.去掉文件,直接将产生的sql输出的消费队列,队列另一端,consumer 并发的导入即可。
所以我在此基础上开发了datapumper,数据无需落地,不许要全局锁,所有的线程就可以得到coordinate position(所有的线程看到的都是同一份数据)。
因此我设计的datapump 改进如下:
由于只针对了Innodb表的导出,所以无需关心no-innodb tables的一致性。当然,如果需要加入no-innodb tables也很简单,只需要先lock no-innodb tables,然后进行no-innodb tables 的导出,导出完之后,释放锁,然后开始导出innodb tables。
目前项目已经开源,有兴趣的同学欢迎到github上下载:https://github.com/zxszcaijin/datapumper 。如果觉得好,千万别忘记了加星哦。^_^
返回顶部