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

在主库端一旦有新的日志产生后，立刻会发送一次广播，dump线程在收到广播后，则会读取二进制日志并通过网络向备库传输日志，所以这是一个主库向备库不断推送的过程；

新日志在产生后，只需一次广播和网络就会立刻（<1ms）向发送到备库，如果主备之间网络较好的话（例如RTT<1ms），备库端的日志也就小于2ms了。所以，一般的（依赖于RTT），备库的实时性都非常好。

参考：

1. MySQL Replication Manual

2. 图解"How MySQL Replication Works"

Have fun!

广告：我们寻找靠谱的人 | 感谢作者

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

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

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

本文是一个关于Flashcache的初步介绍。

数据量很大（例如4TB），热门数据也很大（800GB），不必要或者不舍得全部买内存来缓存。

数据量不大的话，一般Flashcache就没什么用武之地了，内存就可以帮你解决问题了；

不差钱，买内存呗；

另外Flashcache的加入也使得系统的复杂度增加了一层，如果你坚持KISS原则（Keep it simple, Stupid!），也可以弃用之。

上图中，Flashcache将普通的SAS盘（/dev/sda）和一个高速的SSD(/dev/sdb)虚拟成一个带缓存的块设备（/dev/mapper/cachedev）。后续还将会有更多关于Flashcache相关的文章出现，敬请期待。

对于当前，PCI接口的SSD价格还十分昂贵，而随着时间的推移，价格会降；另外，根据摩尔定律，未来会有更快的设备出现，所以Flashcache是一个“持久的”产品，还只是一个过渡软件，这并不好说。

关注未来新技术的发展吧:)

参考：

1. Facebook / Flashcache

2. Releasing Flashcache of Facebook

3. flashcache-doc.txt

PS：写完整篇文章，最大的收获是：发现人的一生其实很短、很短，可能连1GB都不到。

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

1. MyISAM如何使用Key Cache

当MySQL请求(读或写)MyISAM索引文件中某个Index Block时，首先会看Key Cache队列中是否已经缓存了对应block。如果有，就直接在Key Cache队列中进行读写了，不再需要请求磁盘。如果是写请求，那么Key Cache中的对应Block就会被标记为Dirty（和磁盘不一致）。在MyISAM在Key Cache成功请求（读写）某个Block后，会将该Block放到Key Cache队列的头部。

如果Key Cache中没有待请求（读或写）的Block，MyISAM会向磁盘请求对应的Block，并将其放到Key Cache的队列头部。队列如果满了，会将队列尾部的Block删除，该Block如果是Dirty的，会将其Flush到磁盘上。我们看到MyISAM维护了一个LRU（Least Recently Used）的Key Cache队列。队列中的Dirty Block会在Block被踢出队列时Flush到磁盘上。

2. 图解

下图展示了访问Index Block的过程：（黑色部分为磁盘中的Index文件）

3. 并发访问

Key Cache中的index Block是可以被并发访问的（Shared access ），下面是一些规则：

1. 多个没有更新操作的session可以并发同一个block buffer
2. 多个session同时访问某一个block buffer，如果某个session是update操作，则优先访问
3. 多个session如果都需要进行block replacement，是可以并发操作。（从index file中读取block更新到key cache，但是key cache已满，需要删除一些block buffer的操作叫做block replacement）

4. 补充说明

Key cache中的Block大小可能和索引文件中的Index Block大小不同，可能是大于、小于、等于中的任何一种，但是一般都是成倍数关系的。Key Cache的block大小由参数Key_cache_block_size控制。

（未完待续）

在这个“Cache为王”的时代，我们总是通过不同的方式去缓存我们的结果从而提高响应效率，但一个缓存机制是否有效，效果如何，却是一个需要好好思考的问题。在MySQL中的Query Cache就是一个适用较少情况的缓存机制。在上图中，如果缓存命中率非常高的话，有测试表明在极端情况下可以提高效率238%^[1]。但实际情况如何？Query Cache有如下规则，如果数据表被更改，那么和这个数据表相关的全部Cache全部都会无效，并删除之。这里“数据表更改”包括: INSERT, UPDATE, DELETE, TRUNCATE, ALTER TABLE, DROP TABLE, or DROP DATABASE等。举个例子，如果数据表posts访问频繁，那么意味着它的很多数据会被QC缓存起来，但是每一次posts数据表的更新，无论更新是不是影响到了cache的数据，都会将全部和posts表相关的cache清除。如果你的数据表更新频繁的话，那么Query Cache将会成为系统的负担。有实验表明，糟糕时，QC会降低系统13%^[1]的处理能力。

如果你的应用对数据库的更新很少，那么QC将会作用显著。比较典型的如博客系统，一般博客更新相对较慢，数据表相对稳定不变，这时候QC的作用会比较明显。

再如，一个更新频繁的BBS系统。下面是一个实际运行的论坛数据库的状态参数：

可以看到，数据库一共往QC中写入了约800W次缓存，但是实际命中的只有约500W次。也就是说，每一个缓存的使用率约为0.66次。很难说，该缓存的作用是否大于QC系统所带来的开销。但是有一点是很肯定的，QC缓存的作用是很微小的，如果应用层能够实现缓存，将可以忽略QC的效果。

-------------下面是关于QC的一些其他细节-----------------

一、Query Cache相关参数：

• query_cache_size QC占用空间大小，通过将其设置为0关闭QC功能
• query_cache_type 0表示关闭QC；1表示正常缓存；2表示SQL_CACHE才缓存
• query_cache_limit 最大缓存结果集
• query_cache_min_res_unit 手册上说，QC会按照这个值分配缓存block的大小。
• Qcache_lowmem_prunes 这是一个状态变量(show status)，当缓存空间不够需要释放旧的缓存时，该值会自增。

二、Query Cache观察：

CREATE TABLE t1(id INT,var1 varchar(10));
	//Com_select:8	Qcache_hits:1
INSERT INTO t1 VALUES(1,’WWW’);
	//Com_select:8	Qcache_hits:1
SELECT * FROM t1 WHERE id=1;
	//Com_select:9	Qcache_hits:1
SELECT * FROM t1 WHERE id=1;
	//Com_select:9	Qcache_hits:2 Qcache_queries_in_cache:1
INSERT INTO t1 VALUES(2,’RRRR’);
	//Com_select:9	Qcache_hits:2 Qcache_queries_in_cache:0
SELECT * FROM t1 WHERE id=1; //INSERT后Cache失效
	//Com_select:10  Qcache_hits:2 Qcache_queries_in_cache:1

参考：

1. http://dev.mysql.com/doc/refman/5.0/en/query-cache.html
2. http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html
3. http://www.mysqlperformanceblog.com/2006/07/27/mysql-query-cache/

(全文完)

1. 当事务(Transaction)需要修改某条记录（row）时，InnoDB需要将该数据所在的page从disk读到buffer pool中，事务提交后，InnoDB修改page中的记录(row)。这时buffer pool中的page就已经和disk中的不一样了，我们称buffer pool中的page为dirty page。Dirty page等待flush到disk上。
   
   
2. dirty page既然是在Buffer pool中，那么如果系统突然断电Dirty page中的数据修改是否会丢失？这个担心是很有必要的，例如如果一个用户完成一个操作（数据库完成了一个事务，page已经在buffer pool中修改，但dirty page尚未flush），这时系统断电，buffer pool数据全部消失。那么，这个用户完成的操作（导致的数据库修改）是否会丢失呢？答案是不会(innodb_flush_log_at_trx_commit=1)。这就是redo log要做的事情，在disk上记录更新。
3. redo log在每次事务commit的时候，就立刻将事务更改操作记录到redo log。所以即使buffer pool中的dirty page在断电时丢失，InnoDB在启动时，仍然会根据redo log中的记录完成数据恢复。
4. redo log的另一个作用是，通过延迟dirty page的flush最小化磁盘的random writes。（redo log会合并一段时间内TRX对某个page的修改）
   
5. 正常情况下，dirty page什么时候flush到disk上？
   1).redo log是一个环(ring)结构，当redo空间占满时，将会将部分dirty page flush到disk上，然后释放部分redo log。这种情况可以通过Innodb_log_wait(SHOW GLOBAL STATUS)观察，情况发生该计数器会自增一次。
   2).当需要在Buffer pool分配一个page，但是已经满了，并且所有的page都是dirty的（否则可以释放不dirty的page），通常是不会发生的。这时候必须flush dirty pages to disk。这种情况将会记录到Innodb_buffer_pool_wait_free中。一般地，可以可以通过启动参数innodb_max_dirty_pages_pct控制这种情况，当buffer pool中的dirty page到达这个比例的时候，将会强制设定一个checkpoint，并把dirty page flush到disk中。
   3).检测到系统空闲的时候，会flush，每次64 pages。
6. 涉及的InnoDB配置参数：innodb_flush_log_at_trx_commit、innodb_max_dirty_pages_pct；状态参数：Innodb_log_wait、Innodb_buffer_pool_wait_free。

参考文献

1. http://mysqldump.azundris.com/archives/78-Configuring-InnoDB-An-InnoDB-tutorial.html
2. http://dev.mysql.com/doc/refman/5.0/en/innodb.html

1. 在配置文件中可以配置InnoDB的表空间^[1]，一般格式如下(共享表空间)：
   datadir = /opt/mysql/data
   innodb_data_file_path=ibdata1:1G;ibdata2:1G;ibdata3:1G;ibdata4:1G;ibdata5:1G
2. 完整的表空间，会被分成如下结构供给InnoDB使用。最小单位是page，每个page为16K；64个连续的page组成一个extent；多个extent和page构成一个segment。Segment初始时InnoDB会为它分配32个pages，之后根据需要会将extent分配给segment，单次最多会分配4个extends给segment。^[1]
3. 具体的，InnoDB中一个索引（B-tree）由两个segment组成。其中，所有的叶子节点（leaf nodes）存放在一个segment中，所有的非叶子节点（nonleaf nodes）存放在一个segment中。^[1]
4. 一个存放记录(row)的page，由page header、page trailer、page body组成。如下图:^[2]
   
5. 相关的InnoDB的参数:innodb_data_file_path。

参考文献:

1. http://dev.mysql.com/doc/refman/5.0/en/innodb-file-space.html
2. InnoDB Internals: InnoDB File Formats and Source Code Structure,MySQL Conference, April 2009, Heikki Tuuri CEO Innobase, Calvin Sun Principal Engineer, Oracle Corporation

在使用MySQL的应用中，如果你的MySQL Server压力逐渐增大，在应用层优化已经到了一定瓶颈时，那么你应该首先考虑MySQL_Replication。本文将利用图示的方式简单的描述出MySQL Replication是如何工作的。

如何同步

1. 主库将所有的更新操作，写入二进制日志。
2. 从库运行"IO线程"（Slave IO Thread）读取主库的二进制日志。
3. 从库运行"SQL线程"（Slave SQL Thread）执行IO线程（Slave IO Thread）读取的日志中的SQL,从而保持和主库的一致。

如何分配请求

1. 目前，这部分需要在应用层实现。
2. 执行更新SQL(UPDATE，INSERT，DELETE)时，请求主库。
3. 执行查询SQL(SELECT)时，请求从库。

所以，当你的应用(Application)SELECT请求所占的比率越大，那么Relication就会越有效。