MySQL Replication可以很方便的用来做应用的读扩展，也可以帮MySQL实现一定程度的HA方案。MySQL通过向备库传送二进制日志来实现Replication，本文将通过二进制日志相关源代码的主要接口来解释：“MySQL如何传输二进制日志，是主库推，还是备库拉？MySQL日志传输的实时性如何？”。

在MySQL Replication结构中，备库端初次通过CHANGE MASTER TO完成Replication配置，再使用start slave命令开始复制。更细致的，备库通过IO Thread向主库发起读取binlog的请求（COM_BINLOG_DUMP命令），主库收到COM_BINLOG_DUMP请求后，使用单独线程（dump thread）不断向备库IO Thread发送Binlog。示意图(大图)：

全文阅读 »

Flashcache是Facebook技术团队的又一力作，最初是为加速MySQL设计的。Flashcache是在Linux层面的，所以任何受磁盘IO困绕的软件或应用都可以方便的使用之。

随着时间的流逝，网站上的数据一直在不停的积累。如果你经营的只是一个博客的话，这不会是问题，因为10G的空间，大概就够你写一辈子了（如果放在硬盘上，其实一辈子很短）。如果你恰巧在一个快速增长的公司，数据会越来越多，从MB，到GB，再到TB。

如果将这些数据全部放在大容量的SATA、SAS盘上时，会发现性能（响应时间）不够；如果全放在SSD上时，又会发现成本很高。即使公司能够大气到都放到SSD上，你会发现1TB的数据里面可能只有200G是经常被访问的，300G可能偶尔被访问到，最后剩下的500G可能已经成为历史数据了，几乎不被访问到，如果全部都放在SSD上有略有浪费。于是就有了Flashcache。

Flashcache一个非常不错的软件（准确的说是一个Linux的模块），可以动态加载。Flashcache通过在文件系统（VFS）和设备驱动之间新增了一次缓存层，来实现对热门的缓存。Flashcache是另一种缓存，一般用SSD作为介质的缓存（一般的缓存用的是内存），通过将传统硬盘上的热门数据缓存到SSD上，然后利用SSD优秀的读性能，来加速系统。这个方法较之内存缓存，没有内存快，但是空间可以比内存大很多。

本文是一个关于Flashcache的初步介绍。 全文阅读 »

本文将分为前、中、后三篇，分别介绍MyISAM Key Cache的一般机制、Mid-point strategy、状态、参数和命令。

“Cache为王”，无所不在。为了最小化磁盘I/O，MyISAM将最频繁访问的索引块（“index block”）都放在内存中，这样的内存缓冲区我们称之为Key Cache，它的大小可以通过参数key_buffer_size来控制。在MyISAM的索引文件中（MYI），连续的单元（contiguous unit）组成一个Block，Index block的大小等于该BTree索引节点的大小。Key Cache就是以Block为单位的。 全文阅读 »

当你的数据库打开了Query Cache（简称QC）功能后，数据库在执行SELECT语句时，会将其结果放到QC中，当下一次处理同样的SELECT请求时，数据库就会从QC取得结果，而不需要去数据表中查询。

全文阅读 »

在InnoDB中，buffer pool里面的dirty page一方面可以加快数据处理速度，同时也会造成数据的不一致(RAM vs DISK)。本文介绍了dirty page是如何产生，以及InnoDB如何利用redo log如何消除dirty page产生的数据不一致。

1. 当事务(Transaction)需要修改某条记录（row）时，InnoDB需要将该数据所在的page从disk读到buffer pool中，事务提交后，InnoDB修改page中的记录(row)。这时buffer pool中的page就已经和disk中的不一样了，我们称buffer pool中的page为dirty page。Dirty page等待flush到disk上。
   
   全文阅读 »

InnoDB是MySQL的重要存储引擎，为数据提供了很好的稳定性。一方面，它借鉴了很多ORACLE特性，另一方面InnoDB也有很多自己的特点诸如Insert buffering、Double write等^[2]。了解InnoDB的内部机制，可以帮助我们更好的配置和优化它。本文概述了InnoDB的表空间的结构，算是深入了解的第一步。上图先： 全文阅读 »