技术起点

根据status信息对MySQL服务器进行优化（二）

作者：Lightning@小宝 发布时间：July 26, 2009 分类：MySQL备份&优化&架构 No Comments

续根据status信息对MySQL服务器进行优化（一），直入主题。

六、进程使用情况

mysql> show global status like 'Thread%';
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_cached    | 46    |
| Threads_connected | 2     |
| Threads_created   | 570   |
| Threads_running   | 1     |
+-------------------+-------+

如果我们在MySQL服务器配置文件中设置了thread_cache_size，当客户端断开之后，服务器处理此客户的线程将会缓存起来以响应下一个客户而不是销毁（前提是缓存数未达上限）。Threads_created表示创建过的线程数，如果发现Threads_created值过大的话，表明MySQL服务器一直在创建线程，这也是比较耗资源，可以适当增加配置文件中thread_cache_size值，查询服务器thread_cache_size配置：

mysql> show variables like 'thread_cache_size';
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| thread_cache_size | 64    |
+-------------------+-------+

示例中的服务器还是挺健康的。

七、查询缓存(query cache)

mysql> show global status like 'qcache%';
+-------------------------+-----------+
| Variable_name           | Value     |
+-------------------------+-----------+
| Qcache_free_blocks      | 22756     |
| Qcache_free_memory      | 76764704  |
| Qcache_hits             | 213028692 |
| Qcache_inserts          | 208894227 |
| Qcache_lowmem_prunes    | 4010916   |
| Qcache_not_cached       | 13385031  |
| Qcache_queries_in_cache | 43560     |
| Qcache_total_blocks     | 111212    |
+-------------------------+-----------+

MySQL查询缓存变量解释：

Qcache_free_blocks：缓存中相邻内存块的个数。数目大说明可能有碎片。FLUSH QUERY CACHE会对缓存中的碎片进行整理，从而得到一个空闲块。
Qcache_free_memory：缓存中的空闲内存。
Qcache_hits：每次查询在缓存中命中时就增大
Qcache_inserts：每次插入一个查询时就增大。命中次数除以插入次数就是不中比率。
Qcache_lowmem_prunes：缓存出现内存不足并且必须要进行清理以便为更多查询提供空间的次数。这个数字最好长时间来看；如果这个数字在不断增长，就表示可能碎片非常严重，或者内存很少。（上面的 free_blocks和free_memory可以告诉您属于哪种情况）
Qcache_not_cached：不适合进行缓存的查询的数量，通常是由于这些查询不是

SELECT

语句或者用了now()之类的函数。
Qcache_queries_in_cache：当前缓存的查询（和响应）的数量。
Qcache_total_blocks：缓存中块的数量。

我们再查询一下服务器关于query_cache的配置：

mysql> show variables like 'query_cache%';
+------------------------------+-----------+
| Variable_name                | Value     |
+------------------------------+-----------+
| query_cache_limit            | 2097152   |
| query_cache_min_res_unit     | 4096      |
| query_cache_size             | 203423744 |
| query_cache_type             | ON        |
| query_cache_wlock_invalidate | OFF       |
+------------------------------+-----------+

各字段的解释：

query_cache_limit：超过此大小的查询将不缓存
query_cache_min_res_unit：缓存块的最小大小
query_cache_size：查询缓存大小
query_cache_type：缓存类型，决定缓存什么样的查询，示例中表示不缓存 select sql_no_cache 查询
query_cache_wlock_invalidate：当有其他客户端正在对MyISAM表进行写操作时，如果查询在query cache中，是否返回cache结果还是等写操作完成再读表获取结果。

query_cache_min_res_unit的配置是一柄”双刃剑”，默认是4KB，设置值大对大数据查询有好处，但如果你的查询都是小数据查询，就容易造成内存碎片和浪费。

查询缓存碎片率 = Qcache_free_blocks / Qcache_total_blocks * 100%

如果查询缓存碎片率超过20%，可以用FLUSH QUERY CACHE整理缓存碎片，或者试试减小query_cache_min_res_unit，如果你的查询都是小数据量的话。

查询缓存利用率 = (query_cache_size - Qcache_free_memory) / query_cache_size * 100%

查询缓存利用率在25%以下的话说明query_cache_size设置的过大，可适当减小；查询缓存利用率在80％以上而且Qcache_lowmem_prunes > 50的话说明query_cache_size可能有点小，要不就是碎片太多。

查询缓存命中率 = (Qcache_hits - Qcache_inserts) / Qcache_hits * 100%

示例服务器 查询缓存碎片率 ＝ 20.46％，查询缓存利用率 ＝ 62.26％，查询缓存命中率 ＝ 1.94％，命中率很差，可能写操作比较频繁吧，而且可能有些碎片。

八、排序使用情况

mysql> show global status like 'sort%';
+-------------------+------------+
| Variable_name     | Value      |
+-------------------+------------+
| Sort_merge_passes | 29         |
| Sort_range        | 37432840   |
| Sort_rows         | 9178691532 |
| Sort_scan         | 1860569    |
+-------------------+------------+

Sort_merge_passes 包括两步。MySQL 首先会尝试在内存中做排序，使用的内存大小由系统变量 Sort_buffer_size 决定，如果它的大小不够把所有的记录都读到内存中，MySQL 就会把每次在内存中排序的结果存到临时文件中，等 MySQL 找到所有记录之后，再把临时文件中的记录做一次排序。这再次排序就会增加 Sort_merge_passes。实际上，MySQL 会用另一个临时文件来存再次排序的结果，所以通常会看到 Sort_merge_passes 增加的数值是建临时文件数的两倍。因为用到了临时文件，所以速度可能会比较慢，增加 Sort_buffer_size 会减少 Sort_merge_passes 和 创建临时文件的次数。但盲目的增加 Sort_buffer_size 并不一定能提高速度，见 How fast can you sort data with MySQL?（引自http://qroom.blogspot.com/2007/09/mysql-select-sort.html，貌似被墙）

另外，增加read_rnd_buffer_size(3.2.3是record_rnd_buffer_size)的值对排序的操作也有一点的好处，参见：http://www.mysqlperformanceblog.com/2007/07/24/what-exactly-is-read_rnd_buffer_size/

九、文件打开数(open_files)

mysql> show global status like 'open_files';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Open_files    | 1410  |
+---------------+-------+

mysql> show variables like 'open_files_limit';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| open_files_limit | 4590  |
+------------------+-------+

比较合适的设置：Open_files / open_files_limit * 100% <= 75％

十、表锁情况

mysql> show global status like 'table_locks%';
+-----------------------+-----------+
| Variable_name         | Value     |
+-----------------------+-----------+
| Table_locks_immediate | 490206328 |
| Table_locks_waited    | 2084912   |
+-----------------------+-----------+

Table_locks_immediate表示立即释放表锁数，Table_locks_waited表示需要等待的表锁数，如果Table_locks_immediate / Table_locks_waited > 5000，最好采用InnoDB引擎，因为InnoDB是行锁而MyISAM是表锁，对于高并发写入的应用InnoDB效果会好些。示例中的服务器Table_locks_immediate / Table_locks_waited ＝ 235，MyISAM就足够了。

十一、表扫描情况

mysql> show global status like 'handler_read%';
+-----------------------+-------------+
| Variable_name         | Value       |
+-----------------------+-------------+
| Handler_read_first    | 5803750     |
| Handler_read_key      | 6049319850  |
| Handler_read_next     | 94440908210 |
| Handler_read_prev     | 34822001724 |
| Handler_read_rnd      | 405482605   |
| Handler_read_rnd_next | 18912877839 |
+-----------------------+-------------+

各字段解释参见http://hi.baidu.com/thinkinginlamp/blog/item/31690cd7c4bc5cdaa144df9c.html，调出服务器完成的查询请求次数：

mysql> show global status like 'com_select';
+---------------+-----------+
| Variable_name | Value     |
+---------------+-----------+
| Com_select    | 222693559 |
+---------------+-----------+

计算表扫描率：

表扫描率 ＝ Handler_read_rnd_next / Com_select

如果表扫描率超过4000，说明进行了太多表扫描，很有可能索引没有建好，增加read_buffer_size值会有一些好处，但最好不要超过8MB。

后记：

文中提到一些数字都是参考值，了解基本原理就可以，除了MySQL提供的各种status值外，操作系统的一些性能指标也很重要，比如常用的top,iostat等，尤其是iostat，现在的系统瓶颈一般都在磁盘IO上，关于iostat的使用，可以参考：http://www.php-oa.com/2009/02/03/iostat.html

“根据status信息对MySQL服务器进行优化（一）、（二）”是最近学习MySQL status信息的读书笔记，谬讹之处，望请斧正。

根据status信息对MySQL服务器进行优化（一）

作者：Lightning@小宝 发布时间：July 26, 2009 分类：MySQL备份&优化&架构 No Comments

文章作者:fuchaoqun.com 偶跟他的作品:ColaPHP framework

网上有很多的文章教怎么配置MySQL服务器，但考虑到服务器硬件配置的不同，具体应用的差别，那些文章的做法只能作为初步设置参考，我们需要根据自己的情况进行配置优化，好的做法是MySQL服务器稳定运行了一段时间后运行，根据服务器的”状态”进行优化。

mysql> show global status;

可以列出MySQL服务器运行各种状态值，另外，查询MySQL服务器配置信息语句：

mysql> show variables;

一、慢查询

mysql> show variables like '%slow%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| log_slow_queries | ON    |
| slow_launch_time | 2     |
+------------------+-------+

mysql> show global status like '%slow%';
+---------------------+-------+
| Variable_name       | Value |
+---------------------+-------+
| Slow_launch_threads | 0     |
| Slow_queries        | 4148 |
+---------------------+-------+

配置中打开了记录慢查询，执行时间超过2秒的即为慢查询，系统显示有4148个慢查询，你可以分析慢查询日志，找出有问题的SQL语句，慢查询时间不宜设置过长，否则意义不大，最好在5秒以内，如果你需要微秒级别的慢查询，可以考虑给MySQL打补丁：http://www.percona.com/docs/wiki/release:start，记得找对应的版本。

打开慢查询日志可能会对系统性能有一点点影响，如果你的MySQL是主－从结构，可以考虑打开其中一台从服务器的慢查询日志，这样既可以监控慢查询，对系统性能影响又小。

二、连接数

经常会遇见”MySQL: ERROR 1040: Too many connections”的情况，一种是访问量确实很高，MySQL服务器抗不住，这个时候就要考虑增加从服务器分散读压力，另外一种情况是MySQL配置文件中max_connections值过小：

mysql> show variables like 'max_connections';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 256   |
+-----------------+-------+

这台MySQL服务器最大连接数是256，然后查询一下服务器响应的最大连接数：

mysql> show global status like 'Max_used_connections';
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| Max_used_connections | 245   |
+----------------------+-------+

MySQL服务器过去的最大连接数是245，没有达到服务器连接数上限256，应该没有出现1040错误，比较理想的设置是：

Max_used_connections / max_connections  * 100% ≈ 85%

最大连接数占上限连接数的85％左右，如果发现比例在10%以下，MySQL服务器连接数上限设置的过高了。

三、Key_buffer_size

key_buffer_size是对MyISAM表性能影响最大的一个参数，下面一台以MyISAM为主要存储引擎服务器的配置：

mysql> show variables like 'key_buffer_size';
+-----------------+------------+
| Variable_name   | Value      |
+-----------------+------------+
| key_buffer_size | 536870912 |
+-----------------+------------+

分配了512MB内存给key_buffer_size，我们再看一下key_buffer_size的使用情况：

mysql> show global status like 'key_read%';
+------------------------+-------------+
| Variable_name          | Value       |
+------------------------+-------------+
| Key_read_requests      | 27813678764 |
| Key_reads              | 6798830     |
+------------------------+-------------+

一共有27813678764个索引读取请求，有6798830个请求在内存中没有找到直接从硬盘读取索引，计算索引未命中缓存的概率：

key_cache_miss_rate ＝ Key_reads / Key_read_requests * 100%

比如上面的数据，key_cache_miss_rate为0.0244%，4000个索引读取请求才有一个直接读硬盘，已经很BT了，key_cache_miss_rate在0.1%以下都很好（每1000个请求有一个直接读硬盘），如果key_cache_miss_rate在0.01%以下的话，key_buffer_size分配的过多，可以适当减少。

MySQL服务器还提供了key_blocks_*参数：

mysql> show global status like 'key_blocks_u%';
+------------------------+-------------+
| Variable_name          | Value       |
+------------------------+-------------+
| Key_blocks_unused      | 0           |
| Key_blocks_used        | 413543      |
+------------------------+-------------+

Key_blocks_unused表示未使用的缓存簇(blocks)数，Key_blocks_used表示曾经用到的最大的blocks数，比如这台服务器，所有的缓存都用到了，要么增加key_buffer_size，要么就是过渡索引了，把缓存占满了。比较理想的设置：

Key_blocks_used / (Key_blocks_unused + Key_blocks_used) * 100% ≈ 80%

四、临时表

mysql> show global status like 'created_tmp%';
+-------------------------+---------+
| Variable_name           | Value   |
+-------------------------+---------+
| Created_tmp_disk_tables | 21197   |
| Created_tmp_files       | 58      |
| Created_tmp_tables      | 1771587 |
+-------------------------+---------+

每次创建临时表，Created_tmp_tables增加，如果是在磁盘上创建临时表，Created_tmp_disk_tables也增加,Created_tmp_files表示MySQL服务创建的临时文件文件数，比较理想的配置是：

Created_tmp_disk_tables / Created_tmp_tables * 100% <= 25%

比如上面的服务器Created_tmp_disk_tables / Created_tmp_tables * 100% ＝ 1.20%，应该相当好了。我们再看一下MySQL服务器对临时表的配置：

mysql> show variables where Variable_name in ('tmp_table_size', 'max_heap_table_size');
+---------------------+-----------+
| Variable_name       | Value     |
+---------------------+-----------+
| max_heap_table_size | 268435456 |
| tmp_table_size      | 536870912 |
+---------------------+-----------+

只有256MB以下的临时表才能全部放内存，超过的就会用到硬盘临时表。

五、Open Table情况

mysql> show global status like 'open%tables%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Open_tables   | 919   |
| Opened_tables | 1951  |
+---------------+-------+

Open_tables表示打开表的数量，Opened_tables表示打开过的表数量，如果Opened_tables数量过大，说明配置中table_cache(5.1.3之后这个值叫做table_open_cache)值可能太小，我们查询一下服务器table_cache值：

mysql> show variables like 'table_cache';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| table_cache   | 2048  |
+---------------+-------+

比较合适的值为：

Open_tables / Opened_tables  * 100% >= 85%
Open_tables / table_cache * 100% <= 95%

待续，本文参考以下网页：

1.http://dev.mysql.com/doc/refman/5.1/en/server-status-variables.htm

2.http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html

3.http://www.ibm.com/developerworks/cn/linux/l-tune-lamp-3.html

4.http://www.day32.com/MySQL/tuning-primer.sh 具体数值主要参考此工具

Tokyo Cabinet高效的键值数据库

作者：Lightning@小宝 发布时间：July 26, 2009 分类：DBMS-Database-Cache No Comments

作者:七夜

Tokyo Cabinet 是一款高性能的DBM 数据库。该数据库读写非常快，哈希模式写入100万条数据只需0.643秒，读取100万条数据只需0.773秒，是 Berkeley DB 等 DBM 的几倍   在Tokyo Cabinet官方网站上提供perl、LUA、Java、Ruby的API,没有PHP的接口。 
    我用C封装了Tokyo Cabinet  for PHP的接口。 实现了 Hash Database 、B+ Tree Database 、Table Database 三种数据类型的操作. 以更简单的方式API提供给PHPer 使用。 使用方式几乎和 官方的差不多.

        http://www.cellphp.com/viewtopic.php?id=1  下载地址
        http://www.cellphp.com/viewtopic.php?id=2   Tokyocabinet For PHP  API文档

以下作者：老王

Tokyo Cabinet是一个高效键值数据库，不过和Redis相比，它没有内建的网络接口支持，所以得额外安装，作者已经写好了，就是Tokyo Tyrant：

分别下载源代码：

wget http://tokyocabinet.sourceforge.net/tokyocabinet-1.4.27.tar.gz
wget http://tokyocabinet.sourceforge.net/tyrantpkg/tokyotyrant-1.1.29.tar.gz

注：tokyocabinet源代码包里的Makefile.in文件内有很多用法演示，强烈推荐看看。

两个软件包的安装都很简单，就是Linux下人人皆知的三板斧：

./configure & make & make install

安装完成后，执行ttserver命令就会启动服务，缺省情况下，没有给任何参数使用的是内存数据库。

网络接口Tokyo Tyrant支持HTTP操作方式，我们新开一个命令行窗口来验证一下：

curl -X PUT http://127.0.0.1:1978/foo -d bar
curl http://127.0.0.1:1978/foo

前面是通过执行ttserver命令的方式来启动服务的，实际上还有更优雅的方式，那就是通过ttservctl脚本。

vi /usr/local/sbin/ttservctl

通过ttservctl脚本启动服务缺省使用的是文件数据库，有四种类型的文件数据库，具体使用的是哪种可以通过ttservctl脚本里的dbname扩展名来判断：

.tch - Hash
.tcb - Btree
.tcf - Fixed-length
.tct - Table

每种文件数据库都分别对应这一个mgr命令行工具，可以通过如下命令来查看：

ls /usr/local/bin/*mgr（同时还有很多测试工具，ls /usr/local/bin/*test）

比如说，tch对应的就是tchmgr，tcb对应的就是tcbmgr，tcf对应的就是tcfmgr，tct对应的就是tctmgr。剩下的tcamgr相当于是一个数据抽象层，各种类型都能操作，而tcrmgr相当于是一个远程数据接口，它们的使用都不难，可以对照man手册自己试试：

tchmgr create db
tchmgr put ./db foo bar
tchmgr get ./db foo

如果使用tcamgr的话，在创建数据库的时候要指明扩展名，以便抽象层能判断出要创建的类型：

tcamgr create db.tch
tcamgr put ./db.tch foo bar
tcamgr get ./db.tch foo

要想测试tcrmgr的话，记得先启动ttservctl再测试：

tcrmgr put localhost foo bar
tcrmgr get localhost foo

相对比较NB的是Table类型数据库的使用，可以模拟保存关系数据库中的表：

tctmgr create articles
tctmgr put articles 1 "title" "foo_1" "content" "bar_1"
tctmgr put articles 2 "title" "foo_2" "content" "bar_2"

第一个操作：

tctmgr list -pv articles

会输出如下内容：

1 title foo_1 content bar_1
2 title foo_2 content bar_2

第二个操作：

tctmgr get articles 1

会输出如下内容：

title foo_1
content bar_1

第三个操作：

tctmgr search -pv articles title STREQ foo_2

会输出如下内容：

2 title foo_2 content bar_2

就好像操作关系数据库一样，STREQ在这里是等于的意思，在man tctmgr里能查到完整的命令列表：

The operator of the 'search' subcommand is one of "STREQ", "STRINC", "STRBW", "STREW", "STRAND", "STROR", "STROREQ", "STRRX", "NUMEQ", "NUMGT", "NUMGE", "NUMLT", "NUMLE", "NUMBT", "NUMOREQ", "FTSPH", "FTSAND", "FTSOR", and "FTSEX". If "~" preposes each operator, the logical meaning is reversed. If "+" preposes each operator, no index is used for the operator. The type of the '-ord' option is one of "STRASC", "STRDESC", "NUMASC", and "NUMDESC". This command returns 0 on success, another on failure.

具体的含义可以在API文档中关于tctdbqryaddcond的部分查到。

同时，网络接口Tokyo Tyrant不仅支持HTTP的操作方式，同时还兼容Memcached协议，这无疑是个很实惠的优点，比如说对于PHP来说，可以使用现成的Memcached扩展，而不用再费力写新的扩展：

$instance = new Memcache();
$instance->connect('127.0.0.1', '1978');
$instance->set('foo', 'bar');
echo $instance->get('foo');
偶补充：

<?php

$mem = new Memcache();

$mem->connect('192.168.1.174', 11211);

$mem->set('name', array('sanbao','daxi'), 1, 600);

var_dump(unserialize($mem->get('name')));//tt不能自动反序列化，需要自行解决

?>
不过这个优点也是有代价的，在使用Memcached方式连接Tokyo Tyrant时，Tokyo Tyrant会忽略flags，exptime，cas unique这几个标志位，其中忽略flags标志位意味着，PHP客户端要自己负责反序列化。同时，在使用Memcached方式连接Tokyo Tyrant时，就不能使用Tokyo Cabinet的高级功能了，这时的Tokyo Cabinet退化成一个彻彻底底的键值数据库。

和Memcached客户端相比，使用专用客户端功能会更丰富一些，PHP的不多，就PHPTyrant还像点样。

总体感觉，和Redis相比，Tokyo Cabinet的功能易用性要稍差一些，同时，由于Tokyo Cabinet是使用同步数据磁盘操作的方式，而Redis是使用异步数据磁盘操作的方式，所以Redis的效率也会更高一些，但反过来看，一旦出现故障，Redis丢失数据的可能性也要比Tokyo Cabinet大一些。还有一个明显的区别是，Redis会把所有的数据导入到内存里来操作，所以如果你的内存不够大的话，Tokyo Cabinet则会是更合理的选择。

相关链接：

DBMによるテーブルデータベース
DBMによるテーブルデータベース その参
采用tokyo cabinet搭建表格型DBM（需翻墙）
tokyo tyrant 在 php 上不能自动反序列化的问题
利用Tokyo Tyrant构建兼容Memcached协议、支持故障转移、高并发的分布式key-value持久存储系统

补充说明：不会翻墙的可以使用Web代理：zend2.com

Xtrabackup:Innodb引擎备份工具

作者：Lightning@小宝 发布时间：July 26, 2009 分类：MySQL备份&优化&架构 No Comments

作者：老王

Xtrabackup是percona开发的产品，可以看做是InnoDB Hotbackup的免费替代品。

先看看如何安装Xtrabackup，下载最新的版本，最简单的安装方式无疑是使用RPM包，不过如果你想使用源代码方式安装的话，则会发现其安装方式有点古怪，这是因为它采用的在MySQL源代码上打补丁构建的方式。

wget http://www.percona.com/mysql/xtrabackup/xtrabackup-0.8.tar.gz
tar zxf xtrabackup-0.8.tar.gz
cd xtrabackup-0.8
./configure
make

进行到这里时，千万别惯性使然接着make install，那样就会接着安装MySQL了，正确方法是接着：

cd innobase/xtrabackup/
make
make install

如此一来，就会在你的/usr/bin目录里安装上两个有用的工具：xtrabackup，innobackupex-1.5.1：

xtrabackup可以在不加锁的情况下备份innodb数据表，不过此工具不能操作myisam。
innobackupex-1.5.1是一个脚本封装，能同时处理innodb和myisam，但在处理myisam时需要加一个读锁。

按如上的介绍，由于操作myisam时需要加读锁，这会堵塞线上服务的写操作，而innodb没有这样的限制，所以数据库中innodb表类型所占的比例越大，则越有利。实际应用中一般是直接使用innobackupex-1.5.1方法，它主要有三种操作方式，按手册中的介绍：

Usage:
innobackup [--sleep=MS] [--compress[=LEVEL]] [--include=REGEXP] [--user=NAME]
           [--password=WORD] [--port=PORT] [--socket=SOCKET] [--no-timestamp]
           [--ibbackup=IBBACKUP-BINARY] [--slave-info] [--stream=tar]
           [--defaults-file=MY.CNF]
           [--databases=LIST] [--remote-host=HOSTNAME] BACKUP-ROOT-DIR
innobackup --apply-log [--use-memory=MB] [--uncompress] [--defaults-file=MY.CNF]
           [--ibbackup=IBBACKUP-BINARY] BACKUP-DIR
innobackup --copy-back [--defaults-file=MY.CNF] BACKUP-DIR

第一个命令行是热备份mysql数据库。

The first command line above makes a hot backup of a MySQL database.
By default it creates a backup directory (named by the current date
and time) in the given backup root directory. With the --no-timestamp
option it does not create a time-stamped backup directory, but it puts
the backup in the given directory (which must not exist). This
command makes a complete backup of all MyISAM and InnoDB tables and
indexes in all databases or in all of the databases specified with the
--databases option. The created backup contains .frm, .MRG, .MYD,
.MYI., .TRG, .TRN, .opt, and InnoDB data and log files. The MY.CNF
options file defines the location of the database. This command
connects to the MySQL server using mysql client program, and runs
ibbackup (InnoDB Hot Backup program) as a child process.

带有--apply-log选项的命令是准备在一个备份上启动mysql服务。

The command with --apply-log option prepares a backup for starting a MySQL
server on the backup. This command expands InnoDB data files as specified
in BACKUP-DIR/backup-my.cnf using BACKUP-DIR/ibbackup_logfile,
and creates new InnoDB log files as specified in BACKUP-DIR/backup-my.cnf.
The BACKUP-DIR should be a path name of a backup directory created by
innobackup. This command runs ibbackup as a child process, but it does not
connect to the database server.

带有--copy-back选项的命令从备份目录拷贝数据，索引，日志到my.cnf文件里规定的初始位置。

The command with --copy-back option copies data, index, and log files
from backup directory back to their original locations.
The MY.CNF options file defines the original location of the database.
The BACKUP-DIR is a path name of a backup directory created by innobackup.

Xtrabackup还可以用来moving InnoDB tables between servers，更多的内容可以参考官方文档及例子。

参考链接：Xtrabackup online backup for InnoDB/XTraDB（pdf）

尝试key-value型数据库之redis

作者：Lightning@小宝 发布时间：July 26, 2009 分类：DBMS-Database-Cache No Comments

作者：老王

Redis马上就要释出1.0Stable了，是出手的时候了。

Redis的介绍

数据库主要类型有对象数据库，关系数据库，键值数据库等等，对象数据库太超前了，现阶段不提也罢；关系数据库就是平常说的MySQL，PostgreSQL这些熟的不能再熟的东西，至于键值数据库则是本文要着重说的，其代表主要有MemcacheDB，Tokyo Cabinet等等。

Redis本质上也是一种键值数据库的，但它在保持键值数据库简单快捷特点的同时，又吸收了部分关系数据库的优点。从而使它的位置处于关系数据库和键值数据库之间。Redis不仅能保存Strings类型的数据，还能保存Lists类型（有序）和Sets类型（无序）的数据，而且还能完成排序（SORT）等高级功能，在实现INCR，SETNX等功能的时候，保证了其操作的原子性，除此以外，还支持主从复制等功能。

详细描述参见官方手册，同时，官方提供了一个名为Retwis的项目的源代码，可以对照着官方介绍学习，注意其中关于Data Layout的描述，其他没什么。

项目实践中，多以关系数据库为主，不过合理的使用Redis这样的键值数据库，往往能扬长避短，比如说实现一个类似消息队列的功能，对MySQL来说，除非使用Q4M，否则很难满足高并发请求，不过对Redis来说，通过内建的Lists支持，消息队列就是小菜一碟。

Redis的安装

tar zxvf redis-version.tar.gz
cd redis-version
make

由于没有make install，所以得把源代码目录里的关键文件手动复制到适当的位置：

cp redis.conf /etc/
cp redis-benchmark redis-cli redis-server /usr/bin/

接着调整一些参数，首先设定内核参数：

echo 1 > /proc/sys/vm/overcommit_memory

然后编辑redis.conf配置文件（/etc/redis.conf），按需求做出适当调整，比如：

daemonize yes
logfile /dev/null

如果要记录日志的话，最好先调整loglevel到一个合适的级别，然后设定logfile，如果不需要，则可以像上面这样直接把日子丢弃到/dev/null里，还有一点，缺省情况下，数据文件dump.rdb会被生成到当前目录，可以通过dir参数设定合适的目录。

此外，如果你决定把Redis用于产品环境，还要注意maxmemory选项，因为Redis在启动时会把所有数据加载到内存中，所以设定maxmemory相对安全。

接下来直接启动服务就可以了，只有配置文件一个参数：

redis-server /etc/redis.conf

确认运行了之后，可以用redis-benchmark命令测试看看，还可以通过redis-cli命令实际操作一下，比如：

redis-cli set foo bar
OK
redis-cli get foo
bar

在设置键对应的值的时候，按照协议的规定是要提供数据大小这个参数的，上面的redis-cli命令之所以没有提供这个参数是因为redis-cli本身进行了封装。

可以通过telnet来验证一点：

telnet 127.0.0.1 6379
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
set foo 3
bar
+OK
get foo
$3
bar
^]
telnet> quit
Connection closed.

更多命令介绍参考文档介绍。

Redis源代码里附带了多种客户端的扩展，比如说php（client-libraries/php），这是一个纯PHP的实现方案，也有二进制版本的实现（phpredis）。其他语言即便没有现成的扩展实现，也可以自己按照协议规范写一个扩展，应该不是什么难事。

参考链接：http://github.com/jdp/redisent/tree/master