Chinaunix首页 | 论坛 | 认证专区 | 博客 登录 | 注册

每个人都是设计师

微信公众号“自己的设计师”

  • 博客访问: 362630
  • 博文数量: 73
  • 博客积分: 15
  • 博客等级: 民兵
  • 技术积分: 2202
  • 用 户 组: 普通用户
  • 注册时间: 2010-10-26 21:43
  • 认证徽章:
个人简介

曾就职于阿里巴巴担任Oracle DBA,MySQL DBA,目前在新美大担任SRE。[是普罗米修斯还是一块石头,你自己选择!] 欢迎关注微信公众号 “自己的设计师”,不定期有原创运维文章推送。

文章分类

全部博文(73)

文章存档

2017年(2)

2016年(3)

2015年(7)

2014年(14)

2013年(47)

微信关注

IT168企业级官微



微信号:IT168qiye



系统架构师大会



微信号:SACC2013

订阅
热词专题

分类: Mysql/postgreSQL

      年前看到percona的blog关于mydumper的lockless更新,因此萌发了重写mydumper的想法。这篇文章是我对mydumper的分析,以及对之前重写的产品datapumper的思考与实践。在MySQL的逻辑备份中,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(所有的线程看到的都是同一份数据)。

因此我设计的data pumper 改进如下:

由于只针对了Innodb表的导出,所以无需关心no-innodb tables的一致性。当然,如果需要加入no-innodb tables也很简单,只需要先lock no-innodb tables,然后进行no-innodb tables 的导出,导出完之后,释放锁。

目前项目已经开源,有兴趣阅读代码的同学可以在github上下载:datapump。如果觉得好,别忘记了加星哦。^_^

阅读(694) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册