Orczhou

InnoDB Double write

orczhou — Thu, 04 Feb 2010 12:57:17 +0800

记得刚开始看InnoDB文档的时候，Double Write一节（其实只有一小段）就让我很困惑。无奈当时内力太浅，纠缠了很久也没弄明白。时隔几个月，重新来整理一下。

涉及到的概念：Buffer Pool简称BP，Dirty Page，Log file，Flush，innodb tablespace。

1. 什么是Double Write

在InnoDB将BP中的Dirty Page刷（flush）到磁盘上时，首先会将Page刷到InnoDB tablespace的一个区域中，我们称该区域为Double write Buffer。在向Double write Buffer写入成功后，再择机将数据拷贝到正在的数据文件对应的位置。

咋一看，这个过程有些多余

2. 为什么需要Double Write

InnoDB中有记录（Row）被更新时，先将其在Buffer Pool（简称BP）中的page更新，并将这次更新记录到Log file中，这时候BP中的该page就是被标记为Dirty。在适当的时候（BP不够、系统闲置等），这些Dirty Page会被flush到磁盘上。

试想，在某个Dirty Page（一般是16K）flush的过程中，发生了系统断电（或者OS崩溃），16K的数据只有8K被写到磁盘上，这种现象被称为（partial page writes、torn pages、fractured writes）。一旦partial page writes发生，那么在InnoDB恢复时就很尴尬：在InnoDB的Log file中虽然知道这个数据页被修改了，但是却无法知道这个页被修改到什么程度，和这个页面相关的redo也就无法应用了。

举个例子：在InnoDB的log file中有如下Log：

Log sequence number 0 4285149977
Log sequence number 0 4287355447
Log sequence number 0 4289260680
Log sequence number 0 4291279900
Log sequence number 0 4293359020

其中第1、3个Log修改了该page，但是在断电时，BP中该page只被flush了一部分。那么InnoDB是无法决定上面的Log是否应该被应用的。这时，数据就出现了不一致。

所以，Log file的有效应用，前提是InnoDB的数据文件中的Page是一致的。

简而言之，Double write就是为了避免Partial page writes而设计的。

3. Double Write对性能的影响

系统需要将数据写两份，一般认为，Double Write是会降低系统性能的。peter猜测可能会有5-10%的性能损失，但是因为实现了数据的一致，是值得的。Mark Callaghan认为这应该是存储层面应该解决的问题，放在数据库层面无疑是牺牲了很多性能的。

事实上，Double Write对性能影响并没有你想象（写两遍性能应该降低了50%吧？）的那么大。在BP中一次性往往会有很多的Dirty Page同时被flush，Double Write则把这些写操作，由随机写转化为了顺序写。而在Double Write的第二个阶段，因为Double Write Buffer中积累了很多Dirty Page，所以向真正的数据文件中写数据的时候，可能有很多写操作可以合并，这样有可能会降低Fsync的调用次数。

基于上面的原因，Double Write并没有想象的那么糟。另外，Dimitri在测试后，发现打开和关闭Double Write对效率的影响并不大。

4. 相关参数与状态

是否打开了double write:


root@(none) 07:16:16>show variables like "%double%";
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| innodb_doublewrite | ON    |
+--------------------+-------+

Double write的使用情况：


root@(none) 07:15:50>SHOW STATUS LIKE "%innodb_dblwr%";
+----------------------------+-----------+
| Variable_name              | Value     |
+----------------------------+-----------+
| Innodb_dblwr_pages_written | 145373349 |
| Innodb_dblwr_writes        | 2249336   |
+----------------------------+-----------+

上面可以看到，从BP共Flush了145373349个Pages到double write buffer中；一共调用了2249336次write写到真正的数据文件。可见，相当于每次write合并了 145373349 / 2249336 = 64.6次Flush。（这就是为什么double write buffer为什么并不会对效率有很大影响的原因）

5. 我的看法

在某些文件系统（ZFS等）层面能够保证不出现Partial page writes时，可以关闭Double Write。因为它对性能影响并不大，一般情况都建议打开，毕竟带来的数据安全性保障可能是我们更关心的。

参考文献：

[0]. Manual about Double Write

[1]. Innodb Double Write

[2]. Do you need the InnoDB doublewrite buffer

[3]. MySQL Performance: InnoDB Doublewrite Buffer Impact

Feed enhanced by Better Feed from Ozh

详解MyISAM Key Cache(后篇)

orczhou — Tue, 02 Feb 2010 21:56:43 +0800

在前两篇（前篇、中篇）中，分别介绍了Key Cache的基本原理（LRU和Midpoint Insertion Strategy）。最后，将介绍一些相关的参数、状态参数和命令。

Key Cache的配置很灵活，可以针对全局配置，还可以针对某个单独数据表分配Key Cache的大小；如果一个数据表某部分的索引块被访问的非常频繁（较之其他索引块），那么可以配置Midpoint Insertion Strategy达到最大的利用率(参考)。

1. 如何配置Key Cache的大小

#配置文件my.cnf
key_buffer_size=50*1024*1024

另外，Key Cache的大小可以动态的改变

2. 给数据表划分单独的Key Cache

例如：划分一块128K的Key buffer空间，指定数据表t1的Key cache放在里面。最后演示了如何删除这个特定的Key buffer空间。

SET GLOBAL hot_cache.key_buffer_size=128*1024;
CACHE INDEX t1 IN hot_cache;
SET GLOBAL hot_cache.key_buffer_size=0;

3. 预先载入某些数据表的索引

LOAD INDEX INTO CACHE t1, t2

4. 关于Key Cache的使用情况观察 Flush现象


mysql> show status like "key%";
+------------------------+----------+
| Variable_name          | Value    |
+------------------------+----------+
| Key_blocks_not_flushed | 14468    |
| Key_blocks_unused      | 0        |
| Key_blocks_used        | 14497    |
| Key_read_requests      | 30586575 |
| Key_reads              | 157      |
| Key_write_requests     | 7100408  |
| Key_writes             | 1199800  |
+------------------------+----------+
mysql> flush tables;             （注意，请不要在业务高峰期执行）
+------------------------+----------+
| Variable_name          | Value    |
+------------------------+----------+
| Key_blocks_not_flushed | 0        |   #所有修改的block都已经被flush了
| Key_blocks_unused      | 0        |
| Key_blocks_used        | 14497    |
| Key_read_requests      | 38333936 |
| Key_reads              | 207      |
| Key_write_requests     | 8819898  |
| Key_writes             | 1255245  |
+------------------------+----------+

5. 需要注意的事项

内存中缓存的索引块（Key Cache），有时候并不会及时刷新到磁盘上，所以对于正在运行的数据表的索引文件（MYI）一般都是不完整的。如果此时拷贝或者移动这些索引文件。多半会出现索引文件损坏的情况。

可以通过Flush table命令来将Key Cache中的block都flush到磁盘上。所以，一般要动态移动MyISAM表需要执行以下步骤：

首先，刷新数据表，并锁住数据表：（注意，请不要在业务高峰期执行）

FLUSH TABLES WITH READ LOCK;

可以通过下面的命令来查看没有被Flush的索引块数量


mysql> show status like "Key_blocks_not_flushed";
+------------------------+----------+
| Variable_name          | Value    |
+------------------------+----------+
| Key_blocks_not_flushed | 0        |
+------------------------+----------+

最后，移动对应的文件（MYI MYD FRM）。

参考

MySQL Manual about Key cache

Feed enhanced by Better Feed from Ozh

Linux下C语言连接MySQL

orczhou — Tue, 26 Jan 2010 19:21:30 +0800

相对于Window下的设置，Linux要简单的很多。

1. 示例程序


$ vi mysql-c-api.c
#include <stdio.h>
#include "mysql/mysql.h"
int main(){
        MYSQL mysql;
        mysql_init(&mysql);
        mysql_options(&mysql,MYSQL_OPT_COMPRESS,0);
        mysql_options(&mysql,MYSQL_INIT_COMMAND,"SET autocommit=0");
        if (!mysql_real_connect(&mysql,"10.2.3.4","user","passwd","database",0,NULL,0))
        {
                fprintf(stderr, "Failed to connect to database: Error: %sn",
                mysql_error(&mysql));
        }
        return 0;
}

2. 编译命令

在MySQL编译后的二进制文件中，有一个很有用的二进制文件“mysql_config”（一般和mysql命令在同一个目录下），我们可以通过这个程序找到需要的头文件和连接库：


$ gcc -o a.out $(mysql_config --cflags) mysql-c-api.c $(mysql_config --libs)
$ ./a.out

Feed enhanced by Better Feed from Ozh

详解MyISAM Key Cache(中篇)

orczhou — Sun, 17 Jan 2010 18:14:46 +0800

在前篇中介绍了Key Cache的基本机制，并且介绍了Key Cache的LRU算法。作为对LRU算法的改进，MyISAM还提供了另一个缓存算法：“Midpoint Insertion Strategy”。本文将重点介绍该算法的原理和配置。

1. 相关参数

该策略涉及的参数有：key_cache_division_limit、key_cache_age_threshold

2. 原理介绍

(1) 该策略将前面的LRU队列（LRU Chain）分成两部分，hot sub-chain和warm sub-chain。并根据参数key_cache_division_limit划分，总保持warm sub-chain在这个百分比以上。默认情况key_cache_division_limit是100，所以默认时候只有warm sub-chain,即LRU Chain。
(注：Multiple Key cache情况，每个key cache都有对应的key_cache_division_limit值)

(2) 在warm sub-chain中的某个block如果被访问（Access）次数超过某个值时候，就将该block放到hot sub-chain的底部。

(3) 在hot sub-chain中的block会随着每一次的hit调整位置，hit越多，越接近底部。在顶部停留时间过长就会被降级到warm sub-chain中，而且是warm sub-chain的顶部（很可能很快就会被移出key cache）。

(4) Hot sub-chain中的顶部的block停留时间超过一个阈值后就会被降级到warm sub-chain。这个阈值由参数key_cache_age_threshold决定。具体的计算方法是：设N为key cache中的block个数，如果在最近的（N*key_cache_age_threshold/100）次访问中，key cache顶部的block仍然没有被访问到，那么就会被移到warm sub-chain的顶部。

(5) 默认情况key_cache_division_limit = 100，这时只有只有一个Chain，所以不使用该策略。即退化的Midpoint Insertion Strategy是LRU算法。

3. 如何使用Midpoint Insertion Strategy

我们可以通过配置key_cache_division_limit、key_cache_age_threshold的值来控制。参数key_cache_division_limit控制了Key Cache Chain中warm sub-chain的百分比，如果你的Index Block中明显有30%是非常Hot（较之其他的Block更加被常常访问），那么你可以设置你的warm sub-chain长度为70%，剩余30%作为hot sub-chain。参数key_cache_age_threshold定义了warm sub-chain中的block被移除的机制（参照前文介绍）。

（未完待续）

Feed enhanced by Better Feed from Ozh

详解MyISAM Key Cache(前篇)

orczhou — Thu, 14 Jan 2010 10:12:40 +0800

本文将分为前、中、后三篇，分别介绍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为单位的。

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 ），下面是一些规则：

多个没有更新操作的session可以并发同一个block buffer
多个session同时访问某一个block buffer，如果某个session是update操作，则优先访问
多个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控制。

（未完待续）

© orczhou for 一个故事@MySQL DBA, 2010. | Permalink | 2 comments | Add to del.icio.us
Post tags: MyISAM, MyISAM Key Buffer, 图解

Feed enhanced by Better Feed from Ozh

The “Google” strikes back

orczhou — Wed, 13 Jan 2010 11:01:23 +0800

After a long war, I‘m glad to see that finally the “Google.cn” strikes back in spit of maybe it’s a negtive way.

Since Kaifu Li has left Google.cn, what’s the final state of the game between Google and Chinese goverment ?

Show me.

Feed enhanced by Better Feed from Ozh

Sphinx之配置篇

orczhou — Thu, 07 Jan 2010 20:33:31 +0800

作者：周振兴
摘要：MySQL提供了LIKE子句可以很好的实现对数据库中数据的模糊搜索，使用LIKE很多时候可以帮助我们解决一些站内搜索的问题。但是随着MySQL中数据量逐渐增加，LIKE模糊查询的效率将成为MySQL数据库的主要压力。这时候尝试使用sphinx，可以很好的帮你解决这个问题。本文将继续介绍具体如何部署sphinx。在阅读本文前，建议先浏览sphinx使用介绍(前篇)，或者跳过本文直接RTFM。

+++++++++++++++++++++++++++++++++
正文：
+++++++++++++++++++++++++++++++++

一、下载，安装

下载sphinx-0.9.8.1.tar.gz(在撰写本文时，0.9.8.1是最新版)

安装过程够简洁，在GNU/Linux 2.6.24 Ubuntu 8.04.3 LTS:

tar zxvf sphinx-0.9.8.1.tar.gz
cd sphinx-0.9.8.1
./configure    #这里你可以加上你的安装路径如：./configure --prefix=/usr/local/sphinx
make
sudo make install

二、配置sphinx的数据源

sphinx主要有两个进程indexer和searchd，在他们运行前，我们需要配置好sphinx.conf文件，告诉他们如何工作。(默认配置文件的路径/usr/local/etc/)

首先，我需要配置一个数据源(source)，告诉indexer到哪儿去获取原始数据。例如，我们将配置一个名为mars的数据源：

cd /usr/local/etc/
cp sphinx.conf.dist sphinx.conf
vi sphinx.conf
source mars
{
	type = mysql
	sql_host = localhost
	sql_user = sphinxuser
	sql_pass = sI9sWb2uFYxz
	sql_db = discuzdb
	sql_sock = /var/run/mysqld/mysqld.sock
	sql_port = 3306
	……

这里我配置了一个名为mars的数据源。数据类型是mysql，表示indexer将从mysql中获取我要的数据(除了mysql，sphinx还支持很多种类的数据源，如文本，xml文档等)。这里还配置了访问该数据库的主机名、用户、密码、数据库名、数据库端口、以及连接该数据库的socket文件。(注意：配置文件中有一些多余的source需要删除，如source src1throttled : src1)

现在indexer知道去那个数据库取数据了，但是具体取哪个数据表中的哪些列的数据呢？好，我们继续。编写需要索引的数据列的SQL，例如我需要索引字段为cdb_thread.threadtitle，那么sphinx需要用到的SQL是:

	sql_query = SELECT tid AS id, threadtitle FROM cdb_threads;
}

我们注意到，我们的query中一个时id字段，第二个才是我们需要索引的内容。sphinx有这样的规则，你的Query中获取的第一个字段必须是一个唯一的数字（使用自增的字段是很方便的），后面才是你需要索引的内容（另外，也可以你想排序的字段，这里暂不介绍）。

到这，我们就完成了一个数据源的配置，这里的我们的数据源名字是mars（如果需要，我们还可以配置更多数据源，例如Juliet等）。

三、配置sphinx的索引任务

现在有了：数据源以及需要索引的内容。接下来，我们需要在配置文件中，指定一个某个索引任务去索引前面的内容。这个索引任务应该包含：数据源用哪一个、数据数据放在什么目录下、以及其他的一些索引算法的细节参数。

index explorer{
	source = mars              #还记得前面建立的source吧？
	path    = /var/data/sphinx/catalog    #任务的工作空间在哪，sphinx需要一些空间建立索引
	morphology              = stem_en      #搜索的一些“词法”  我也不知道这是什么！:-(

	min_word_len            = 3   
	min_prefix_len          = 0   
	min_infix_len           = 3   
}

四、sphinx搜索配置

最后，还剩一点点工作。那就是配置searchd，你甚至保持默认就可以了。searchd中定义了一些搜索行为，例如当搜索结果集太大的时候，最多返回多少个（默认1000），等等。

搞定配置文件，98%的事情就算完成了。

五、启动、使用Sphinx

所有工作都已经就绪了，现在是倒计时启动的时间了。

执行indexer，对数据进行一次索引。

sudo /usr/local/bin/indexer [--rotate] --config /usr/local/etc/sphinx.conf explorer
//这里的explorer就是前面配置文件中一个索引任务

启动搜索相应进程（searchd）：

sudo mkdir -p /var/data/sphinx
sudo /usr/local/bin/searchd --config /usr/local/etc/sphinx.conf &

好了，搞定。我们来测试一下吧：（早就迫不及待了吧）

例如查找字符串 “ENG”
sudo usr/local/bin/search --config /usr/local/etc/sphinx.conf ENG
看看你的搜索结果

如果搜索结果正常，到这，我们就完成全部的sphinx配置和启动工作。在接下来的一篇文章中我将介绍如果使用php向sphinx发送搜索请求，并处理返回结果。

Feed enhanced by Better Feed from Ozh

MySQL Slow Log慢日志分析(一)

orczhou — Tue, 05 Jan 2010 20:32:36 +0800

医生给病人诊断的时候，一般会使用听诊器来诊断肺部是否正常。如果你的MySQL出现了性能问题，第一个需要“诊断”的就是slow log（慢日志）了。

slow log文件很小，使用more less等命令就足够了。如果slow log很大怎么办？这里介绍MySQL自带的工具mysqldumpslow来帮你解析慢日志(也可以跳过本文，直接阅读Manual)。

1. 基本使用

$mysqldumpslow slow.log > slow.dat
$more slow.dat

输出的数据：

Count: 3 Time=62.67s (188s) Lock=0.00s (0s) Rows=1623770.7 (4871312), root[root]@localhost
SELECT /*!N SQL_NO_CACHE */ * FROM `feed_receive_0287`

这里我们能够获得：这条语句在满日志中的出现次数、平均执行时间、总共执行时间、row send等。例如：SELECT /*!N SQL_NO_CACHE */ * FROM `feed_receive_0287`一共执行了3次，平均每次使用62秒。

在默认情况下，mysqlslowdump的输出结果会使用N和S代替SQL中出现的数字和字符串。例如：如下慢日志

SELECT COUNT(*) as counter FROM feed_receive f WHERE f.RATED_UID=21621 AND f.suspended=-1 AND f.rater_type=4 AND f.rate=-2 AND f.username=”orczhou.com”

会被mysqlslowdump抽象为：

SELECT COUNT(*) as counter FROM feed_receive f WHERE f.RATED_UID=N AND f.suspended=-N AND f.rater_type=N AND f.rate=-N AND f.username=”S”

如果想禁用这种抽象，可以使用-a参数

2. 排序参数

mysqlslowdump默认输出结果是按照count（SQL出现的次数）排序的。可以通过如下的参数控制：

-s t	按总query time排序	-s at	按平均query time排序
-s l	按总locktime排序	-s al	按平均lock time排序
-s s	按总row send排序	-s as	按平均row send排序
-s c	按count排序	–	–

例如：

mysqldumpslow -s at slow.log.old > slow.2.dat #按照平均query time排序查看日志

3. 其他参数

-r	倒着排序
-a	不要将数字和字符串抽象成N和S
-g	仅仅分析相匹配的query

4. 常用命令

由上面的常用参数就可以组合出如下的常用命令：

mysqldumpslow -s t slow.log.old > slow.1.dat #按照query time排序查看日志
mysqldumpslow -s at slow.log.old > slow.2.dat #按照平均query time排序查看日志
mysqldumpslow -a -s at slow.log.old > slow.3.dat #按照平均query time排序并且不抽象数字的方式排序
mysqldumpslow -a -s c slow.log.old > slow.4.dat #安装执行次数排序

参考：mysqldumpslow Manual

（全文完）

Feed enhanced by Better Feed from Ozh

WOW 2009

orczhou — Thu, 31 Dec 2009 17:21:43 +0800

清晰记得刚步入2009年的时候，我的MSN签名档就是WOW 2009，转眼，一年就过去了。

欣喜：来到杭州，风景何止如画；痛苦：忙至拂晓，但为系统稳定

坚持：方向正确，何惧路途荆棘；期待：天下风景，待我尽收眼底

Feed enhanced by Better Feed from Ozh

Chrome扩展一键翻墙

orczhou — Mon, 21 Dec 2009 19:18:02 +0800

写在前头：翻墙的前提仍然是“你得有能够翻墙的代理服务器，或者自己的ssh tunnel”，关于如何获得这样的代理，那是另一个故事。

正文：尝试过IE、Friefox、Opera、Chrome浏览器之后，最终被Chrome的快速、简洁征服。现在浏览网站，90%的时候使用Chrome。还有10%我不得不使用其他的浏览器：

偶尔的网页前端开发时，我不得不使用Firefox（Fire Bug等扩展）
网页有ActiveX控件的时候，我不得不用IE（也可以使用Firefox的IE Tab）
某些网站的Html对Chrome支持不好的时候，我也不得不使用IE，不过最近一年这种情况越来越少了
快速翻墙的时候，我也会使用Firefox（Foxy proxy扩展），虽然其他的浏览器也可以使用代理，但是都不能自动匹配URL使用代理，而且设置起来都很麻烦

Chrome的最新Beta版本已经可以支持扩展了（稳定版目前只能支持主题扩展），登录Chrome扩展页面，搜索了一下”firebug”、”Proxy”、”IE Tab”都有了相应的扩展。如果使用方便，上面的(1)、(2)、(4)三种情况就可以解决了。

书归正传，还是来说说如何使用Chrome的Switchy!扩展（当然，你得有能够翻墙的代理服务器，或者自己的ssh tunnel）。一般使用IE（或者当前稳定版的Chrome）时，如果你想翻墙的话，打开和关闭代理操作是很繁琐的。Chrome的Switchy!扩展则实现了一键设置和取消代理，翻墙更轻松。

1.下载Chrome Beta版

点击下载后，Chrome会自动完成安装，并提示重新启动chrome。在新的Chrome首页有如下提示：

【靠，升级后原来的主题又没了！！！装上主题先。(另外，书签同步也是个好东西)】

2.进入Switchy!扩展页面，并点击Install。下载完成后，Chrome会弹出对话框“确定安装”，安装后会自动跳转到一个Switchy!的配置页面。

上图是我的代理配置。参照此，填写你的代理配置，然后点击Save就可以了。安装Switchy!后，在你的Chrome浏览器右上角就会多了一个小图标，如下图：

通过该图标，你就可以自由的控制什么时候使用代理，什么时候禁用了。虽然没有Firefox的FoxyProxy自动匹配URL方便，但比起每次手动修改还是好多了。

(全文完)

Feed enhanced by Better Feed from Ozh