概要信息：

@tb丁原 
2012-04-10 
我的经历：Taobao 数据库这5年 
DTCC2012
感谢 
感谢it168，itpub 
感谢Taobao dba team 
感谢在场的所有同学 
 
DTCC2012
索引 
 Taobao数据库这5年  
MySQL化面临的问题及应对 
DTCC2012
weibo上的讨论 
DTCC2012
为什么选择开源（MySQL） 
• 成本驱动 
• 公司自身技术积累，商业软件在淘
宝优势逐步弱化 
• 其他客观条件 
 
 
上面3点，哪点是决定性的？ 
 
 
DTCC2012
成本高，到底有多高 
刚开始买服务器（拿个袋子就去了）                                 后来的成本（得用大卡车运钱去） 
DTCC2012
成本高，到底有多高 
某业务真实的数据： 
2010年DB+硬件的投入在1100万左右。 
2011年DB+硬件的投入在2200万左右。 
2012年DB+硬件的投入在4400万左右。 
 
 
备注： 
没有不差钱的公司 
这单单只是某个业务的压力，可想整体成本的压力有多大 
既然这么贵，我们为什么不尝试免费的呢 
 
 
DTCC2012
选择开源初期面临的挑战 
团队内部(dba)： 
     1.团队人员非常，非常擅长商业db 
     2.对开源db的理解一穷二白，需要快速积累，放弃你最熟悉的，选择重新开始 
     3. 原有思维方式固化，改变需要时间 
     4.其他 
团队外部(除dba之外的)： 
      1.为什么要拥抱开源，好处在哪儿 
      2.用了开源软件，dba还是最专业的吗？ 
      3.打破原有集中式的思维，换一种方式，同时还要考虑更多的东西 
       4.其他 
 
--拥抱变化 
http://media.ifeng.com/news/newmedia/web/201002/0206_4266_1539529.shtml 
 
 
DTCC2012
推进过程 
 强推，阻力大？ 
 一蹴而就还是按部就班，几年几年必须要完成？ 
 
 
 
 
1. 尝试阶段（小业务，小范围开始） 
2. 积累阶段（使用过程中开发，dba面临的问题，解决问题） 
3. 继续积累，验证（解决新的问题，逐步推广到更多的业务线） 
4. 大规模可用阶段 
 
DTCC2012
关键点 
开发易用性： 
成熟的中间层，尽量减少开发的难度 
 
DBA易运维： 
强大的MySQL底层运维平台 
 
其他： 
思想统一，协作，配合 
DTCC2012
关于现在，未来 
1.关于成本 
开源&&商业解决方案，那个成本更加昂贵，现在我们很难知
道，各有各的说法，但是未来一定是开源软件的（爱是做出
来的，做了就一定有机会看到）。 
 
2.定制化开源软件的趋势（hbase，mysql，hadoop，linux内
核。。。） 
 
3. 
DTCC2012
MySQL的淘宝历史 
年份 阶段 重要项目（里程碑） 
 
2008年 
 
尝试阶段 
 
始于画报（poster）项目 
 
 
 
 
-2010年 
 
 
 
发展阶段 
 
Tddl中间层 
zdatasource 数据源 
MySQL 监控逐步成熟 
核心业务有计划的开始往MySQL上迁移 
 
 
-现在 
 
继续发展阶
段 
 
MySQL秒级别故障切换 
MySQL semi sync，online ddl，myawr 
定制自己的MySQL，彻底拥抱开源 
核心业务全部迁移到MySQL db上 
NoSQL尤其hbase成为db的有力补充 
DTCC2012
MySQL线上服务器统计 
DTCC2012
这5年，数据存储产品比例 
0
10
20
30
40
50
60
70
80
90
100
2007 2008 2009 2010 2011
商业db 
开源db 
NoSQL
存储趋势上：集中式，分布式，云？ 
DTCC2012
索引 
 Taobao数据库的这5年  
MySQL化面临的问题以及应对 
DTCC2012
商业DB vs MySQL 
商业db，MySQL各自的优缺点，适用场景？ 
DTCC2012
商业DB vs MySQL 
 商业软件  
  稳定，功能非常强大，代码非常严谨，不会出现低级的bug 
  license贵，软件黑盒子 
 确实非常非常好用 
 
 
开源软件 
 轻量级数据库（连接线程级别） 
 扩展性好，可以针对具体业务场景进行定制 
 地雷多（比如ddl出现丢表的情况） 
 
商业软件可能适合传统业务类型，对数据库稳定性要求非常高的业务。 
MySQL可能适合于变化非常快的互联网，数据量急剧膨胀，但数据的重要性相对不那么care。 
 
那，那，那我们属于哪一类？ DTCC2012
使用MySQL,你有什么顾虑 
使用MySQL会有很多顾虑，开发的顾虑，dba的疑虑，没有关系，我们来
一起解决。  
• MySQL会丢数据吗 
• MySQL容灾快速切换方案 
• MySQL的性能怎么样 
• MySQL开源软件自身的稳定性怎么样 
• MySQL ddl锁表（阻塞写）怎么解决 
• MySQL备库同步延迟，备库跟不上主库 
• MySQL主备库数据的一致性校验 
• 相比商业软件成熟的解决方案，MySQL+PC架构其高可用如何保证 
 
 
DTCC2012
MySQL会丢数据吗 
丢数据场景： 
1. MySQL数据库down掉 会丢吗？ 
2. Mysql 服务器异常down掉（比如CPU，RAM
损坏，淘宝这几年发生的几率不到5/1000） 
3. 硬盘坏掉会不会丢数据？   
 
--innodb_flush_log_at_trx_commit参数 
设置为1（每个事务日志都flush到磁盘）,设置为
2（每个事务刷到log file中，每秒flush 到磁盘
中）。 
 
-- Slave 远程binlog： 
通过slave来保证数据不丢失，binlog实时传送到
远程slave，基本上在毫秒之内。 
http://www.orczhou.com/index.php/2011/11/ho
w-mysql-send-the-binary-log/ 
 
 
 
DTCC2012
MySQL会丢数据吗 
MySQL丢数据： 
更多指MySQL采用pc服务器，pc服务器存在
硬件损坏的可能性（比如内存，cpu坏掉），
导致丢数据。 
 
 
怎么来避免这种情况？ 
DTCC2012
MySQL高可靠方案（Semi sync） 
 
 
 
 
 
 
 
 
 
 
 
淘宝MySQL对semisync做了一些改动  
http://code.google.com/p/google-MySQL-tools/wiki/SemiSyncReplication 
http://code.google.com/p/google-MySQL-tools/wiki/SemiSyncReplicationDesign 
 
DTCC2012
我们在用的不丢数据方案 
--线上情况 
1.应用双写（写两份） 
2. 应用通过记录log来实现（比如通过notify消息） 
3.Semi sync方案 
 
 
 
 DTCC2012
MySQL高可用方案 
硬件故障是很难避免的。 
我们要做的是，挂掉的情况下如何快速恢复，减少对业务的影响？ 
MySQL MM（和MS的区别？）机制，双向复制，数据库秒级别切换 
 
 
 
 
 
切换步骤上： 
1.Db主备库切换   
2.App数据源切换，通过zdatasource来做 
两者打包，做到db和数据源一键切换，尽量缩短切换时间 
db1 
db2 
db1 
db2 
M M 
APP 
DTCC2012
MySQL的性能表现 
线上业务机器： 
基本配置：2*4cpu 2.3G，12*SAS,  32G RAM ,MySQL 5.1.48 
单台机器的dml达到了4000/s，qps超过了15000/s（性能主要看场景和数据量，仅供参
考）。 
 
 
DTCC2012
MySQL性能之_软件架构 
线上MySQL版本：5.1.48 ，Percona Server 5.5.20 
MM架构：线上主要架构 
MS架构：多Slave可以提供更多的读服务，比如论坛帖子应用 
DTCC2012
MySQL性能之_硬件架构 
业务模型决定硬件选型，业务模型是什么？ 
• 数据量大小  
• 读写比例，读多写少还是写多读少 
 
基本硬件配置： 
• 内存基本配置24G，48G，96G，根据业务来决定内存选型，内存cache
依然为王 
• 磁盘：Fusion io，ssd，sas，sata，fio+flashcache ，oltp应用最关注的是
Iops，磁盘是否给力直接决定了性能 
 
备注： 
这几年硬件更新换代很快，单条pc服务器的性能越来越好 
DTCC2012
MySQL性能之_flashcache 
源于facebook，初始用于加速MySQL innodb引擎IO 
现在是通用的软件方案块加速设备（土点可以理解为二级缓存） 
 
 
 
 
 
 
 
 
 
 
 
url： 
https://github.com/facebook/flashcache 
 
DTCC2012
MySQL主备库延迟解决方案（relay-fetch预热） 
基本思路： 
在备库sql线程执行更新之前，预先将相应的数据加载到内存中  
http://relay-fetch.googlecode.com/svn/trunk/ 
 
 
 
 
 
 
 
 
 
--业界  
http://code.google.com/p/maatkit/issues/list?q=Label:Tool-mk_slave_prefetch&sort=type 
http://dom.as/2011/12/03/replication-prefetching/ DTCC2012
MySQL主备库延迟解决方案（transfer） 
 
 
 
 
 
 
 
 
    
 
      原有方案：单线程 
 
 
 
--相关资料 
http://vdisk.weibo.com/s/2IBnN/1329966761（淘宝丁奇） 
改
进
方
案
：
多
线
程 
DTCC2012
MySQL online ddl 
online ddl工具：  
业界online ddl工具基本实现原理都是一致的，原理基本差不多的。  
 http://www.facebook.com/notes/mysql-at-facebook/online-schema-change-for-
mysql/430801045932 
 
能做到的是：在ddl table的过程中，app依然可以进行读写操作。 
 
--工具链接 
oak-online-alter-table： 
http://openarkkit.googlecode.com/svn/trunk/openarkkit/doc/html/oak-online-alter-table.html  
pt-online-schema-change： 
http://www.percona.com/doc/percona-toolkit/2.0/pt-online-schema-change.html (pecona出品)  
myddl ：http://www.ningoo.net（nigoo开发，已经在用） DTCC2012
MySQL主备库逻辑复制的风险 
主备库： 
MySQL 通过逻辑（statement or row模式）复制来实现主备库数据同步。 
逻辑复制理论上是有风险的，极端情况下可能存在主备库数据不一致。 
 
应对方案： 
1.尽量采用row模式 
2.主备库定期数据一致性校验 
3.数据生命周期的binlog尽量保存下来 
 
DTCC2012
MySQL其他问题应对 
• MySQL高可用解决方案 
               MM，MS机制 
               动态数据源机制实现异常快速切换（秒级别） 
               通过改造后的semi sync来保障数据不丢失，或是应用设计上高可用考虑 
               应用数据补偿方案 
• 应用设计往前一步，任何设计都假设MySQL挂掉的应对方案 
• 开源软件带来更多灵活性，遇到BUG，及时去修复bug，也可以定制我们
自己的MySQL 
 
 
采用MySQL： 
App一定要站在db的角度来考虑问题，db站在app的角度来思考。 
 
DTCC2012
使用MySQL,你还有什么顾虑 
DTCC2012
不断假设，不断去验证 
--测试（假设了很多场景，寻找解决方案，不断的打消我们自己的疑虑） 
） 
 
 
 
 
 
--异常测试 
 
DTCC2012
MySQL之技术储备 
怎么让开源软件好用，怎么让普通pc服务器健壮起来，这需要所有人的参
与。 
 
--现有情况 
1. MySQL 源码debug团队 
2. 中间层（比如taobao的tddl），尽量降低分布式MySQL下的开发成本 
3. MySQL异常快速容灾切换，尽量做到对开发完全透明 
4. Os(linux)问题定位非常熟练 
5. MySQL online ddl解决方案 
6. 团队的支持，易用性稳定性努力（tddl团队，核心研发MySQL团队等） 
7. 工具化，能工具的尽量不人肉 
8. 非常完善的监控体系 
 
 
 
 
DTCC2012
MySQL定位 
MySQL定位： 
就是个开源软件。 
轻量级数据库，蛮好用的。 
不要去比较，有优势，也有劣势。 
 
分库分表，你是否厌倦了？ 
 
 DTCC2012
MySQL化的意义 
MySQL化的意义。 
对于我们来说，真的只是把db改成MySQL了吗？ 
 
DTCC2012
MySQL化的意义 
思想 
思想 
打破思想 
打破集中式的思维  
把db看成只是软件 
Dba+app，开发和dba一起来实现高可用 
 
DTCC2012
谢谢大家 
 
 
 
DTCC2012