这是一篇淘宝丁原的演讲PPT，我觉得挺好，转摘于此
原文链接：http://www.docin.com/p-456657187.html
使用MySQL,你有什么顾虑
使用MySQL会有很多顾虑，开发的顾虑，dba的疑虑，没有关系，我们来一起解决。
•MySQL会丢数据吗
•MySQL容灾快速切换方案
•MySQL的性能怎么样
•MySQL开源软件自身的稳定性怎么样
•MySQL ddl锁表（阻塞写）怎么解决
•MySQL备库同步延迟，备库跟不上主库
•MySQL主备库数据的一致性校验
•相比商业软件成熟的解决方案，MySQL+PC架构其高可用如何保证
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/how-mysql-send-the-binary-log/
MySQL丢数据：
更多指MySQL采用pc服务器，pc服务器存在硬件损坏的可能性（比如内存，cpu坏掉），导致丢数据。
怎么来避免这种情况？
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
我们在用的不丢数据方案
--线上情况
1.应用双写（写两份）
2. 应用通过记录log来实现（比如通过notify消息）
3.Semi sync方案
MySQL高可用方案
硬件故障是很难避免的。
我们要做的是，挂掉的情况下如何快速恢复，减少对业务的影响？
MySQL MM（和MS的区别？）机制，双向复制，数据库秒级别切换
切换步骤上：
1.Db主备库切换
2.App数据源切换，通过zdatasource来做
两者打包，做到db和数据源一键切换，尽量缩短切换时间
MySQL性能之_软件架构
线上MySQL版本：5.1.48 ，Percona Server 5.5.20
MM架构：线上主要架构
MS架构：多Slave可以提供更多的读服务，比如论坛帖子应用
MySQL性能之_硬件架构
业务模型决定硬件选型，业务模型是什么？
•数据量大小
•读写比例，读多写少还是写多读少
基本硬件配置：
•内存基本配置24G，48G，96G，根据业务来决定内存选型，内存cache依然为王
•磁盘：Fusion io，ssd，sas，sata，fio+flashcache ，oltp应用最关注的是Iops，磁盘是否给力直接决定了性能
备注：
这几年硬件更新换代很快，单条pc服务器的性能越来越好
MySQL性能之_flashcache
url：
https://github.com/facebook/flashcache
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/
MySQL主备库延迟解决方案（transfer）
改进方案：多线程
原有方案：单线程
相关资料
http://vdisk.weibo.com/s/2IBnN/1329966761（淘宝丁奇）
MySQL主备库逻辑复制的风险
主备库：
MySQL 通过逻辑（statement or row模式）复制来实现主备库数据同步。
逻辑复制理论上是有风险的，极端情况下可能存在主备库数据不一致。
应对方案：
1.尽量采用row模式
2.主备库定期数据一致性校验
3.数据生命周期的binlog尽量保存下来
MySQL其他问题应对
MySQL高可用解决方案
MM，MS机制
动态数据源机制实现异常快速切换（秒级别）
通过改造后的semi sync来保障数据不丢失，或是应用设计上高可用考虑
应用数据补偿方案
•应用设计往前一步，任何设计都假设MySQL挂掉的应对方案
•开源软件带来更多灵活性，遇到BUG，及时去修复bug，也可以定制我们自己的MySQL
采用MySQL：App一定要站在db的角度来考虑问题，db站在app的角度来思考。
使用MySQL,你还有什么顾虑
不断假设，不断去验证
--测试（假设了很多场景，寻找解决方案，不断的打消我们自己的疑虑）
--异常测试
MySQL之技术储备
怎么让开源软件好用，怎么让普通pc服务器健壮起来，这需要所有人的参与。
--现有情况
1.MySQL 源码debug团队
2.中间层（比如taobao的tddl），尽量降低分布式MySQL下的开发成本
3.MySQL异常快速容灾切换，尽量做到对开发完全透明
4.Os(linux)问题定位非常熟练
5.MySQL online ddl解决方案
6.团队的支持，易用性稳定性努力（tddl团队，核心研发MySQL团队等）
7.工具化，能工具的尽量不人肉
8.非常完善的监控体系
MySQL定位
就是个开源软件。
轻量级数据库，蛮好用的。
不要去比较，有优势，也有劣势。
分库分表，你是否厌倦了？
MySQL化的意义
思想
思想
打破思想
打破集中式的思维
把db看成只是软件
Dba+app，开发和dba一起来实现高可用
