很多时候，你缺少的不是知识而是热情

什么是高可用性每个应用对可用性的需求各不相同。在设定一个可用时间的目标之前，先问问自己，是不是确实需要达到这个目标。可用性每提高一点，所花费的成本都会远超之前；可用性的效果和开销的比例并不是线性的。需要保证多少可用时间，取决于能够承担多少成本。高可用性实际上是在宕机造成的损失与降低宕机时间所花费的成本之间取一个平衡。换句话说，如果需要花大量金钱去获得更好的可用时间，但所带来的收益却很低，可能就

SSD与FlashCaceh相关参考资料推荐：《Mysql基于SSD_flashcache优化实践》http://wenku.it168.com/d_129111.shtml《SSD+ RAID卡和PCI-E flash卡在淘宝的应用实践》http://v.youku.com/v_show/id_XNTA3OTExMDEy.html《淘宝商品库MyS

在「中国数据库技术大会」上，淘宝分享了「秒杀场景下MySQL的低效」，详细分析了秒杀的技术难点及改进措施，简而言之，主要就是在高并发事务请求的情况下，数据库性能由于死锁检测等因素直线下降，在这种场景下，单纯的关闭死锁检测虽然可以提升一定的性能，但这顶多是治标而已，如何治本？淘宝给出来两个改进方法：请求排队：如果请求一股脑的涌入数据库，势必会由于争抢资源造成性能下降，通过排队，让请求从混沌到

MySQL的主从复制有多种原因可以导致延迟，这个是公认的了，下面我们谈谈怎样监测复制的延迟，以及怎样尽量的解决延迟的问题。 延迟的监测Seconds_behind_master在SLAVE上执行SHOW SLAVE STATUS，监控Seconds_behind_master列值，备库Seconds_Behind_Master值是通过将服务器当前的时间戳（这里其实有个主从服务器时间

由于数据量的巨大，大部分Web应用都需要部署很多个数据库实例。这样，有些用户操作就可能需要去修改多个数据库实例中的数据。传统的解决方法是使用分布式事务保证数据的全局一致性，经典的方法是使用两阶段提交协议。长期以来，分布式事务提供的优雅的全局ACID保证麻醉了应用开发者的心灵，很多人都不敢越雷池一步，想像没有分布式事务的世界会是怎样。如今就如MySQL和PostgreSQL这类面向低端用户的

Mysql复制单线程的本质意味着从服务器效率的降低，即使从服务器有很多磁盘、cpu、和内存，也很容易落后于主服务器，因为从服务器的单线程只能有效的使用一个cpu和磁盘。 从服务器上的锁定也是一个问题，运行在从服务器上的另外的查询也会加锁并阻塞复制线程。复制是单线程，复制线程(sql_thread)除了等待也不能做别的事情。 为了解决这个问题，业界开发了一些补丁解决这类问题，一个思路

由淘宝核心系统研发—数据库组开发的MySQL-Transfer,用于解决MySQL主从同步延迟的问题，从MySQL单线程到多线程的工作模式。相关资料：MySQL多线程同步-Transfer使用说明http://wenku.it168.com/d_000355271.shtmlMySQL异步复制延迟解决的架构设计与运维架构—在线播放—优酷网http://v.you

这个海量存储系列是淘宝核心系统团队分享的一篇文章，这里转帖第六节，单机事务面临的问题及解决办法，很值得我们借鉴全部章节可以参考：http://blog.youkuaiyun.com/heiyeshuwu/article/details/9722443在我开始做淘宝数据层的时候，被问得最多的无非也就是：如何做事务，如何做join.至今仍然如此，我一般都会简单而明确的跟对方说：没有高效

Percona Sereve（PS或PS MySQL）Percona Server是个与MySQL向后兼容的替代品。它尽可能不改变SQL语法、客户端/服务器协议和磁盘的文件格式。任何运行在MySQL上的都可以运行在Percona Server上而不需要修改。切换到Percona Server只需要关闭MySQL和启动Percona Server，不需要导入和重新导入数据。切换回去也不麻烦，而这

向上扩展向上扩展（有时也称为垂直扩展）意味着购买更多强悍的硬件，对很多应用来说这是唯一需要做的事情。这种策略有很多好处。例如，单台服务器比多台服务器更加容易维护和开发，能显著节约开销。在单台服务器上备份和恢复应用同样很简单，因为无须关心一致性或者哪个数据集是权威的。向上扩展比处外扩展更简单。 尽管可以在非常强大的服务器上运行MySQL，但和大多数据库一样，在增加硬件资源的情况下MySQ

复制是如何工作的第一步是在主库上记录二进制日志，在记录二进制日志后，主库会告诉存储引擎可以提交事务了。下一步，备库将主库的二进制日志复制到其本地的中继日志中。首先，备库会启动一个工作线程，称为I/O线程，I/O线程跟主库建立一个普通的客户端连接，然后在主库上启动一个特殊的二进制转存（binlog dump）线程，这个转存线程会读取主库上的二进制日志中事件。它不会对事件进行轮询，如果该线

缓存，读和写如果有足够的内存，就完全可以避免磁盘读取请求。如果所有的数据文件都可以放在内存中，一旦服务器缓存“热”起来了，所有的读操作都会在缓存命中。虽然还是会有逻辑读取，不过物理读取就没有。但是写入是不同的问题。写入可以像读一样在内存中完成，但迟早要被写入到磁盘，所以它是需要持久化的。换句话说，缓存可以延缓写入，但不能消除写入。写入从缓冲中大大受益，因为它把随机I/O更多地转换到连续

MySQL有大量可以修改的参数——但不应该随便去修改。通常只需要把基本的配置项配置正确（大部分情况下只有很少一些参数是真正重要的），应该将更多的时间花在schema的优化、索引，以及查询设计上。确保基本的配置是正确的，如果碰到了问题，并且问题是由于服务器的某部分导致的，而这恰好可以通过某个配置项解决，那么需要做的就是更改配置。MySQL基本配置InnoDB在大多数情况下如果要运行的