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