从办公到家庭环境，或者从会议室到办公工位上的IP切换相信已经把你搞的烦死了，那么用下面的2个小脚本吧，呵呵，药到病除。

1. 切换成自动获取IP

@echo off
netsh interface ip set address name="local" source=dhcp
netsh interface ip set dns name="local" source=dhcp

2. 切换成固定IP

@echo off
netsh interface ip set address local static 192.168.0.84 255.255.255.0 192.168.0.254
netsh interface ip set dns local 192.168.0.254
netsh interface ip add dns local 202.106.196.115 index=2
netsh interface ip add dns local 202.106.0.20 index=3

"local" 是你的本地网卡名称，也可能是 "本地连接"，需要自己替换下。如果是2个固定IP间的来回切换，把第2个脚本自己改改吧 :)
dns设置中，第一个是set，表示设置，后面两个则是添加，自己替换成当地的dns server。

怎么在同一个mysql里配置mysql跑两个端口，如3306和3312两个

目前我用的HP 360G5服务器中，4个单核的cpu，6块盘，8G内存，按理说和DELL 2950差不多，应该性能来说也差不多，可是发现在大文件操作模式下，360G5比2950慢多了。经查，发现是raid控制器的firmware和磁盘控制器的firmware版本太低导致，下面是firmware升级前后的对比单项测试：

测试文件大小：38G

1.升级前

time cp -f file1 file2
real    10m48.215s

2.硬盘fw也升级后

time cp -f file1 file2
real    10m26.801s

3.升级 raid firmware

time cp -f file1 file2
real    9m15.767s

4.调整write cacheratio 50/50 => 25/75后

time cp -f file1 file2
real    8m13.572s

想要在MySQL 5.1以下的版本中动态抓取提交到MySQL中的查询日志，可以采用tcpdump的方法，大致如下：

tcpdump -i eth0 -s 0 -l -w - dst port 3306 | strings | egrep -i 'SELECT|UPDATE|DELETE|INSERT|SET|COMMIT|ROLLBACK|CREATE|DROP|ALTER|CALL'

eth0指mysqld监听的网卡，330自然是指mysqld监听的端口，正则匹配模式里，可以自己添加想要抓取的SQL语句类型。

0、前言

本文主要探讨 mysqldump 的几种主要工作方式，并且比较一下和 mk-parralel-dump 的一些差异，为备份方式的选择提供更多的帮助。

1、mysqldump

首先来看下 mysqldump 的几个主要参数的实际工作方式。

mysqldump 几个主要选项
1. -q
很简单，什么都不做，只是导出时加了一个 SQL_NO_CACHE 来确保不会读取缓存里的数据。

081022 17:39:33       7 Connect     root@localhost on
7 Query       /*!40100 SET @@SQL_MODE='' */
7 Init DB     yejr
7 Query       SHOW TABLES LIKE 'yejr'
7 Query       LOCK TABLES `yejr` READ /*!32311 LOCAL */
7 Query       SET OPTION SQL_QUOTE_SHOW_CREATE=1
7 Query       show create table `yejr`
7 Query       show fields from `yejr`
7 Query       show table status like 'yejr'
7 Query       SELECT /*!40001 SQL_NO_CACHE */ * FROM `yejr`
7 Query       UNLOCK TABLES
7 Quit

2. --lock-tables
跟上面类似，不过多加了一个 READ LOCAL LOCK，该锁不会阻止读，也不会阻止新的数据插入。

081022 17:36:21       5 Connect     root@localhost on
5 Query       /*!40100 SET @@SQL_MODE='' */
5 Init DB     yejr
5 Query       SHOW TABLES LIKE 'yejr'
5 Query       LOCK TABLES `yejr` READ /*!32311 LOCAL */
5 Query       SET OPTION SQL_QUOTE_SHOW_CREATE=1
5 Query       show create table `yejr`
5 Query       show fields from `yejr`
5 Query       show table status like 'yejr'
5 Query       SELECT /*!40001 SQL_NO_CACHE */ * FROM `yejr`
5 Query       UNLOCK TABLES
5 Quit

3. --lock-all-tables
这个就有点不太一样了，它请求发起一个全局的读锁，会阻止对所有表的写入操作，以此来确保数据的一致性。备份完成后，该会话断开，会自动解锁。

081022 17:36:55       6 Connect     root@localhost on
6 Query       /*!40100 SET @@SQL_MODE='' */
6 Query       FLUSH TABLES
6 Query       FLUSH TABLES WITH READ LOCK
6 Init DB     yejr
6 Query       SHOW TABLES LIKE 'yejr'
6 Query       SET OPTION SQL_QUOTE_SHOW_CREATE=1
6 Query       show create table `yejr`
6 Query       show fields from `yejr`
6 Query       show table status like 'yejr'
6 Query       SELECT /*!40001 SQL_NO_CACHE */ * FROM `yejr`
6 Quit

4. --master-data
除了和刚才的 --lock-all-tables 多了个 SHOW MASTER STATUS 之外，没有别的变化。

081022 17:59:02       1 Connect     root@localhost on
1 Query       /*!40100 SET @@SQL_MODE='' */
1 Query       FLUSH TABLES
1 Query       FLUSH TABLES WITH READ LOCK
1 Query       SHOW MASTER STATUS
1 Init DB     yejr
1 Query       SHOW TABLES LIKE 'yejr'
1 Query       SET OPTION SQL_QUOTE_SHOW_CREATE=1
1 Query       show create table `yejr`
1 Query       show fields from `yejr`
1 Query       show table status like 'yejr'
1 Query       SELECT /*!40001 SQL_NO_CACHE */ * FROM `yejr`
1 Quit

5. --single-transaction

InnoDB 表在备份时，通常启用选项 --single-transaction 来保证备份的一致性，实际上它的工作原理是设定本次会话的隔离级别为：REPEATABLE READ，以确保本次会话(dump)时，不会看到其他会话已经提交了的数据。

081022 17:23:35       1 Connect     root@localhost on
1 Query       /*!40100 SET @@SQL_MODE='' */
1 Query       SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
1 Query       BEGIN
1 Query       UNLOCK TABLES
1 Init DB     yejr
1 Query       SHOW TABLES LIKE 'yejr'
1 Query       SET OPTION SQL_QUOTE_SHOW_CREATE=1
1 Query       show create table `yejr`
1 Query       show fields from `yejr`
1 Query       show table status like 'yejr'
1 Query       SELECT /*!40001 SQL_NO_CACHE */ * FROM `yejr`
1 Quit

6. --single-transaction and --master-data
本例中，由于增加了选项 --master-data，因此还需要提交一个快速的全局读锁。在这里，可以看到和上面的不同之处在于少了发起 BEGIN 来显式声明事务的开始。这里采用 START TRANSACTION WITH CONSISTENT SNAPSHOT 来代替 BEGIN 的做法的缘故不是太了解，可以看看源代码来分析下。

081022 17:27:07       2 Connect     root@localhost on
2 Query       /*!40100 SET @@SQL_MODE='' */
2 Query       FLUSH TABLES
2 Query       FLUSH TABLES WITH READ LOCK
2 Query       SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
2 Query       START TRANSACTION WITH CONSISTENT SNAPSHOT
2 Query       SHOW MASTER STATUS
2 Query       UNLOCK TABLES
2 Init DB     yejr
2 Query       SHOW TABLES LIKE 'yejr'
2 Query       SET OPTION SQL_QUOTE_SHOW_CREATE=1
2 Query       show create table `yejr`
2 Query       show fields from `yejr`
2 Query       show table status like 'yejr'
2 Query       SELECT /*!40001 SQL_NO_CACHE */ * FROM `yejr`
2 Quit

关于隔离级别可以看手册 13.2.10.3. InnoDB and TRANSACTION ISOLATION LEVEL，或者本站之前的文章：[InnoDB系列] - 实例解析Innodb的隔离级别以及锁模式。

关于 START TRANSACTION WITH CONSISTENT SNAPSHOT 的说明可以看下手册描述：

The WITH CONSISTENT SNAPSHOT clause starts a consistent read for storage engines that are capable of it. This applies only to InnoDB. The effect is the same as issuing a START TRANSACTION followed by a SELECT from any InnoDB  table. See Section 13.2.10.4, “Consistent Non-Locking Read”. The WITH CONSISTENT SNAPSHOT clause does not change the current transaction isolation level, so it provides a consistent snapshot only if the current isolation level is one that allows consistent read (REPEATABLE READ or SERIALIZABLE).

12.4.1. START TRANSACTION, COMMIT, and ROLLBACK Syntax

2. mysqldump 和 mk-parralel-dump 的比较

mk-parralel-dump 是开源项目 Maatkit 中的一个工具，主要由 Baron Schwartz 维护。
mk-parralel-dump 是由 perl 开发的，可以实现并发的导出数据表。具体的功能不细说，自己去看相关文档吧。这里只列出在我的环境下和 mysqldump 的对比数据。

2.1 mysqldump 常规使用

#导出耗时
time mysqldump -f --single-transaction -B yejr --tables yejr | gzip > /home/databak/yejr.sql.gz
real    10m15.319s
user    6m47.946s
sys     0m38.496s
#文件大小
608M /home/databak/yejr.sql.gz
#导出期间系统负载
05:00:01 PM       all      0.71      0.00      0.61      7.33     91.36
05:10:02 PM       all     13.93      0.00      2.21      4.64     79.22

2.2 mysqldump + gzip --fast

#导出耗时
time mysqldump -f --single-transaction -B yejr --tables yejr | gzip --fast > /home/databak/yejr_fast.sql.gz
real    9m6.248s
user    4m21.467s
sys     0m37.604s
#文件大小
815M Oct 21 17:33 /home/databak/yejr_fast.sql.gz
#导出期间系统负载
05:20:01 PM       all     11.94      0.00      2.43      5.69     79.94
05:30:01 PM       all      6.46      0.00      1.57      3.95     88.02

2.3 mk-parallel-dump 常规使用

time ./mk-parallel-dump --database yejr --tables yejr --basedir /home/databak/
default:             25 tables,    25 chunks,    25 successes,  0 failures, 404.93 wall-clock time, 613.25 dump time
real    6m48.763s
user    4m20.724s
sys     0m38.125s
#文件大小
819M    /home/databak/default/yejr/
#导出期间系统负载
05:10:02 PM       all     13.93      0.00      2.21      4.64     79.22
05:20:01 PM       all     11.94      0.00      2.43      5.69     79.94

可以看到，mk-parallel-dump 尽快确实实现了并发导出，速度相对快多了，却有个致命伤：那就是它不支持InnoDB的一致性备份，目前已经有人提交相关代码了，不过还没实现，期待中。

由于某些BT的需求，把ftp的服务端改成ssl加密的，而标准的linux ftp客户端不支持，google了下，发现有个sslftp支持，它是 SurgeFTP 的组件之一。SurgeFTP的服务器端版本是收费的，客户端貌似免费，呵呵，正好。
下面演示如何用它登录ftp(ssl)。假设ftp(ssl)的端口是1234。

sslftp 192.168.0.84 -i -implicit_port 990
Connected to 192.168.0.84:1234
starting SSL/TLS
secure protocol TLSv1 used.
220 Serv-U FTP Server v7.2 ready...
(secure) User: yejr
331 User name okay, need password.
(secure) Password: ****************
230-User logged in, proceed.
230 Welcome！
Type in "save" to save login details to /root/.netrc
sslftp> bye
221 Goodbye, closing session.
Channel Closed.
Bye :-)

上面是用命令行交互的方式，如何用脚本实现自动登录呢？看下面：

#!/bin/bash
##
FTP_SERV=192.168.0.84
FTP_PORT=1234
FTP_USER="yejr"
FTP_PASS="yejr"
sslftp -i -implicit_port :$FTP_PORT -script <

大功告成 :)

0. 前言

AWStats是一个免费的日志分析工具，用perl开发的。可以用于分析各种linux下的应用程序产生的日志，包括 apache/squid/samba/resin/tomcat 等等。在这里，我用它来分析apache日志。

1. 安装

AWStats 是采用perl开发的，linux系统中一般都有perl语言环境，因此无需做特别处理。如果还像通过web server查看分析结果，就需要让web server支持cgi才行了。在这里，我使用apache作为web server，因此我在编译apache时，加上了选项：--enable-cgi。

下载 AWStats 压缩包，解开后，放到/usr/local/awstats下。主要有以下几个文件：

docs
README.TXT
result
tools
wwwroot

接下来，编辑配置文件，AWStats 支持针对多个子域名生成分析日志，这里以 imysql.cn 域名为例。配置文件名为：/etc/awstats/awstats.imysql.cn.conf，主要修改以下几行：

LogFile="/data/log/imysql.cn-access_log"
LogFormat=4
SiteDomain="imysql.cn"
DirData="/usr/local/awstats/result"

LogFile 指明apache的access log所在，这里也可以使用变量，例如：LogFile="/data/log/imysql.cn-access_log.%YY-24%MM-24%DD"，具体的请查看 相关文档。
LogFormat 表示日志格式，我在apache的日志格式中，采用 combined，因此这里写成 4。如果apache里设置的是 common，则在这里写 2，具体的对应关系可以看 Awstats文档。
SiteDomain 要分析的域名
DirData 分析结果存放位置

2. 运行、使用

2.1 分析日志

[yejr@imysql log]# /usr/local/awstats/tools/awstats_updateall.pl now

上面这种方式是一下子分析所有的域名，也可以像下面这样只分析某个域名：

[yejr@imysql log]# /usr/local/awstats/wwwroot/cgi-bin/awstats.pl -update -config=imysql.cn

2.2 查看分析结果

首先，要先配置apache，如下：

Alias /awstatsclasses "/usr/local/awstats/wwwroot/classes/"
Alias /awstatscss "/usr/local/awstats/wwwroot/css/"
Alias /awstatsicons "/usr/local/awstats/wwwroot/icon/"
ScriptAlias /awstats/ "/usr/local/awstats/wwwroot/cgi-bin/"

Options None
AllowOverride All
Order allow,deny
Allow from all

在这里，我允许 /usr/local/awstats/wwwroot 目录定义自己的访问规则，因此我可以编辑自己的 .htaccess 来限制可以访问该目录的用户，设定是否需要密码等规则。

[yejr@imysql log]# cat /usr/local/awstats/wwwroot/.htaccess
AuthType Basic
AuthName "Restricted Files"
AuthUserFile /usr/local/apache/conf/passwords
Require user yejr

[yejr@imysql log]#  cat /usr/local/apache/conf/passwords
yejr:kAfG4CMXiIB3w

然后，我就可以通过这个url(http://xxxxx/awstats/awstats.pl?config=imysql.cn)来访问我的分析结果了，呵呵。

原文：http://www.mysql.com/news-and-events/generate-article.php?id=2008_27

Kickfire Brings Powerful Purpose-Built Analytic Appliance to the MySQL World

Santa Clara, CA – October 14, 2008 – Kickfire™, Inc. today
announced that it has entered into a global multi-year MySQL
Enterprise™ data warehouse agreement with Sun Microsystems. Under the
terms, Kickfire's Series 2000 and 3000 analytic appliances will include
a MySQL Enterprise subscription, providing customers with a fully
integrated, plug-and-play solution. Kickfire will provide customers a
single point of contact for both hardware and MySQL™ technical support,
ensuring a seamless end-user experience.

Sun's MySQL Enterprise database subscription is a comprehensive set of production-tested
software, proactive monitoring tools, and premium support services -- designed to help corporate
database developers, DBAs and other customers to deliver optimal performance, reliability,
security, and uptime for their critical MySQL applications.

Kickfire's small form factor analytic appliance is designed for the
vibrant MySQL market to break through today's performance, data
scalability, and costly hardware buildout problems. The
appliance, which transparently integrates MySQL Enterprise, Kickfire's
pluggable MySQL analytic
storage engine and the industry's only SQL chip, delivers world
record-breaking performance and
price-performance as demonstrated on the rigorous TPC-H* data
warehousing benchmark.
Kickfire took number one position in both non-clustered system
performance and
price/performance – beating all other column store analytic databases,
relational databases and
data warehouse appliances on the 300GB and 100GB tests.

"Before Kickfire, MySQL customers who wanted high-performance analytics had to choose
between expensive manual tuning, adding hardware or migrating to a proprietary data warehouse
appliance or column store database engine," commented Raj Cherabuddi, president and founder
of Kickfire. "These solutions can be extremely expensive and none can match the query
performance speeds of a Kickfire appliance at our mass market prices."

In addition to high performance, Kickfire's appliance offers unrivaled integration with existing
MySQL environments. Kickfire integrates hardware and software into a simple plug-and-play
appliance, increasing the ease-of-use of MySQL and streamlining the customer purchase,
installation and support processes. Kickfire also features built-in MySQL data migration utilities
that are not found in other offerings, to greatly simplify initial product setup and speed time-tovalue.

Once installed, Kickfire’s appliance does not rely on pre-computed results. Instead, Kickfire
delivers its fast performance on complex ad hoc queries across a wide variety of schemas and
SQL commands, simplifying administration and enhancing user value.

"Industry demand for database solutions that accelerate query performance at an affordable cost
is at an all-time high which is why data warehousing continues to grow dramatically as a use case
for MySQL," said Mark Burton, vice president, MySQL Global Software Practice, Sun
Microsystems. "Kickfire's analytic appliance is a unique approach that brings data warehousing
and BI to a mass market of users."

About TPC-H

The TPC Benchmark™H (TPC-H) is an industry standard decision support benchmark defined
and maintained by the Transaction Processing Council (TPC). The TPC is a non-profit
corporation founded to define transaction processing and database benchmarks and to
disseminate objective, verifiable TPC performance data to the industry. A vendor is required to
go through a stringent testing and audit process prior to officially publishing TPC-H results. More
information is available at http://www.tpc.org.

About Kickfire

Kickfire provides the first high-performance, easy-to-use analytic appliance for the burgeoning
MySQL market. Based on a patented SQL chip that packs the power of tens of CPUs into an
exceptionally small, low-power form factor, Kickfire delivers a quantum leap in performance
efficiency -- avoiding the hardware build out, power, and space costs of today's data warehouse
and database offerings. By delivering astoundingly fast query performance out of the box,
Kickfire’s plug and play appliance enables organizations to use MySQL for demanding
business intelligence, reporting, and analysis. Kickfire appliances scale from gigabytes to
terabytes and are based on Linux and commodity hardware. They leverage existing storage as
well as the openness of MySQL and its entire ecosystem to ensure compatibility and rapid
deployment. Kickfire is backed by blue chip venture capital firms: Accel Partners, Greylock
Partners, The Mayfield Fund and Pinnacle Ventures. For more information, please visit
www.kickfire.com.

原来一切正常，但是近来mysql收到巨大的查询，经常导致服务器宕机，从昨天开始mysql的InnoDB不能使用，所有使用InnoDB引擎的数据库全部不能读取，刚开始以为数据库损坏，但是恢复备份以后依旧存在，同时mysql的my.cnf没有经过修改，默认是支持InnoDB的。
081011 19:40:01 mysqld started
InnoDB: Error: log file ./ib_logfile0 is of different size 0 268435456 bytes
InnoDB: than specified in the .cnf file 0 5242880 bytes!
081011 19:40:01 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.0.45-log' socket: '/var/lib/mysql/mysql.sock' port: 0 Source distribution

ib开头的日志文件按照网上大家说的清除过，但是无效，清除日志以后重启的日志如下

081011 19:53:58 mysqld started
InnoDB: The first specified data file ./ibdata1 did not exist:
InnoDB: a new database to be created!
081011 19:53:58 InnoDB: Setting file ./ibdata1 size to 10 MB
InnoDB: Database physically writes the file full: wait...
081011 19:53:58 InnoDB: Log file ./ib_logfile0 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile0 size to 5 MB
InnoDB: Database physically writes the file full: wait...
081011 19:53:58 InnoDB: Log file ./ib_logfile1 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile1 size to 5 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: Doublewrite buffer not found: creating new
InnoDB: Doublewrite buffer created
InnoDB: Creating foreign key constraint system tables
InnoDB: Foreign key constraint system tables created
081011 19:53:59 InnoDB: Started; log sequence number 0 0
081011 19:53:59 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.0.45-log' socket: '/var/lib/mysql/mysql.sock' port: 0 Source dist
ribution

但是再次重启依然会出现
InnoDB: Error: log file ./ib_logfile0 is of different size 0 268435456 bytes这样错误。

访问使用InnoDB的数据库会得到如下日志：
081011 19:54:54081011 19:54:54 [ERROR] Cannot find table wiki/page from the
internal data dictionary
of InnoDB though the .frm file for the table exists. Maybe you
have deleted and recreated InnoDB data files but have forgotten
to delete the corresponding .frm files of InnoDB tables, or you
have moved .frm files to another database?
See http://dev.mysql.com/doc/refman/5.0/en/innodb-troubleshooting.html
how you can resolve the problem.

服务器系统是centos 5.2 x86_64 内存2G 系统设置都是默认的。

phpmyadmin“数据库中没有表。”
浏览一个完整的数据库，phpmyadmin侧边栏显示：
drupal (102)
数据库中没有表。

表的格式都是MyISAM，所有的表都可以正常操作，但是就是不能在phpmyadminM中显示，phpmyadmin版本是2.11.9.1，有遇到过这种情况的吗？

参考文章：Making MySQL more usable: InnoDB save/restore buffer pool patch。
Jeremy Cole同学写了个补丁，用于将InnoDB 缓冲池(buffer pool)里的列表在关闭mysqld时保存到本地文件中，重启启动时再加载到内存中去。该补丁目前只适用于MySQL 5.1版本。作者计划该补丁至少应具备以下几点要求：

• 可以自定义本地文件名
• 可以在启动时自主选择是否需要加载到内存中
• 支持在接受用户请求前先加载一部分，剩下的可以放到后台进程中继续加载

不过，作者目前只是想到了以下几点特性，虽然有的还没有实现：

• 采用多线程来加载，这对于使用RAID阵列更有优势
• 支持在线保存/还原缓冲池，而无需重启mysqld
• 增加缓冲池的统计信息，便于在加载时能选择哪些优先级别比较高，避免所有的页都以同一优先级加载

下面我们来尝试用以下这个补丁，看看效果如何。

1、准备

下载innodb plugin 1.0.1，下载补丁buffer_pool_save_restore.patch 和 move_buf_chunk_struct.patch。下载MySQL 5.1.26源码。
然后是解压缩，打补丁，编译。

[yejr@localhost yejr]# cd innodb_plugin-1.0.1
[yejr@localhost yejr]# patch -p1 < ../buffer_pool_save_restore.patch
patching file handler/ha_innodb.cc
Hunk #1 succeeded at 1986 with fuzz 2 (offset 67 lines).
patching file include/srv0start.h
patching file srv/srv0start.c
Hunk #1 succeeded at 1950 (offset 18 lines).
[yejr@localhost yejr]# cd ..; alias cp=cp; cp -rf innodb_plugin-1.0.1/* mysql-5.1.26-rc/storage/innobase/
[yejr@localhost yejr]# cd mysql-5.1.26-rc
[yejr@localhost yejr]# ./configure '-without-embedded-server' '-with-innodb' '-with-zlib-dir=bundled' '-with-big-tables' '-enable-assembler' '-enable-local-infile' '-with-pic' '-prefix=/usr/local/mysql' '-with-extra-charsets=complex' '-enable-thread-safe-client' && make && make install-strip
[yejr@localhost yejr]# strings /usr/local/mysql/libexec/mysqld | grep ib_buf_pool_state

可以看到，已经将该补丁编译进去了。在这里，也可以下载 percona 提供的源码，里面已经集成了其他的几个补丁。

2、测试

首先，模拟各种方法，将innodb buffer pool尽量填满，最快的办法就是导出全部数据。设置 innodb_buffer_pool_size 大小为 14G，然后导出全部数据，可以看到全部被填满了：

...
Buffer pool size   917503
Free buffers       0
Database pages     917503
Modified db pages  0
...

关闭mysqld，查看一下是不是产生了本地文件。

[yejr@localhost yejr]# mysqladmin shut
[yejr@localhost yejr]# ls -lh ib_buf_pool_state
-rw-rw----  1 mysql mysql 19M Oct  8 14:34 ib_buf_pool_state
[yejr@localhost yejr]# file ib_buf_pool_state
ib_buf_pool_state: ASCII text
[yejr@localhost yejr]# head -2 ib_buf_pool_state
43 1344258 0 69 0 122
43 1344259 0 69 0 122
[yejr@localhost yejr]# wc ib_buf_pool_state
917439  5504634 19545127 ib_buf_pool_state

然后启动mysqld，可以看到日志中记录了大量类似下面的内容：

	....
081008 14:36:28 mysqld_safe Starting mysqld daemon with databases from /data/mysql
081008 14:36:30  InnoDB: highest supported file format is Barracuda.
081008 14:36:35 InnoDB Plugin 1.0.1 started; log sequence number 205351853106
succeeded for space=43 offset=1344258 table_id=0 69 index_id=0 122
succeeded for space=43 offset=1344259 table_id=0 69 index_id=0 122
.....

然后，再看看buffer pool的情况：

...
Buffer pool size   917503
Free buffers       0
Database pages     917503
Modified db pages  0
...

可以看到，几乎填满了所有buffer pool，相当于还原到了重启前的内存状态，省去了需要经过一段时间运行才能使内存填满所需缓冲的过程，实在是方便。不过，它也有一个致命的缺点，那就是如果你的buffer pool较大(测试时最高用到14G)，则启动可能会非常慢，有时候甚至无法忍受。我的测试服务器配置应该说还算不错了(dell 2950, 16Gb ram, MD3000盘阵)，然而上面的测试中，启动mysqld居然花了几乎7个小时才完成，根本无法忍受。
把buffer pool大小调成6G，还是执行上面的测试，发现启动时间立刻缩小了很多，只需要 2min53s。

注意：不建议在非常重要的系统中使用该补丁，万一出了问题，没人为你负责 :)

附：下面是我的一些测试数据

417439	3m0.737s
617439	4m50.357s
637439	5m38.622s
667439	6m8.553s
717439	7m10.761s
727439	7m14.659s
827439	6h20m

第一列是表示 ib_buf_pool_state 文件中有多少行数据。另外，可以通过 head/tail/grep 等工具来自主选择需要被重新加载的buffer内容。

原文出自：The new cool MySQL patch has landed! Check your queries performance!，本文做只部分翻译。

MySQL微秒慢查询(microtime slow query)补丁包具有以下特色：

• 识别连接

每个慢查询结果中都记录了是哪个连接线程引起的，如下：

# Thread_id: 571

• 微秒计数

可以记录执行时间在1秒一下的慢查询，选项 long_query_time 的单位现在是微秒，而不是秒，例如设置成300000表示0.3秒。

# Query_time: 0.021752  Lock_time: 0.000016  Rows_sent: 1  Rows_examined: 103

• 记录复制产生的慢查询

通常情况下，MySQL并不记录复制产生的慢查询，使用该补丁后，只需要打开选项 --log-slow-slave-statements 解决这一问题。


• 详细的查询执行计划

每次查询的执行计划都不一样。可能使用索引扫描，或者全表扫描，或者使用临时表。通常这些信息也能从 EXPLAIN 结果中得到。该补丁会在日志中显示了查询中最重要的几个方面，如下：

1.  # QC_Hit: No  Full_scan: No  Full_join: No  Tmp_table: Yes  Tmp_table_on_disk: No
2.  # Filesort: Yes  Filesort_on_disk: No  Merge_passes: 0

QC_Hit 表示本次查询是否命中了查询缓存(Query Cache)。如果显示的是 0，则表示该查询并没有真正的执行。
如果 Full_scan 的结果为 Yes 表示该查询比较糟糕，因为需要扫描全表。
Full_join 表示联合查询时没有使用索引。
如果需要创建临时表，则 Tmp_table 的结果为 Yes；如果需要创建基于磁盘的临时表而不是基于内存的，则 Disk_tmp_table 的值为 Yes。
如果用到 filesort 算法，则 Filesort 的值为 Yes，Filesort_on_disk 则表示排序是基于临时文件进行的。


• InnoDB 的使用

最后一部分是InnoDB使用结果的统计。MySQL现在允许运行 SHOW SESSION STATUS 来查看每个线程的统计信息，但是这并不包括InnoDB的使用，因为InnoDB部分而总是显示全局统计的结果。该补丁允许你查看每次查询的InnoDB资源使用情况。

#   InnoDB_IO_r_ops: 3  InnoDB_IO_r_bytes: 49152  InnoDB_IO_r_wait: 0.018690
#   InnoDB_rec_lock_wait: 0.000000  InnoDB_queue_wait: 0.000000
#   InnoDB_pages_distinct: 7

InnoDB_IO_r_ops 统计计划需要读取的页数。实际数量可能不太一样，虽然它可以异步完成，不幸的是并没有好办法来衡量它。它的单位是字节(bytes)。
从 InnoDB_IO_r_wait 中可以看到 InnoDB 从存储引擎中读取数据锁等待的时间(单位是秒)。
InnoDB_rec_lock_wait 表示等待行锁所需时间(单位是秒)。
InnoDB_queue_wait 表示等待进入 InnoDB 队列或在队列中等待执行所消耗的时间(单位是秒)。
InnoDB_pages_distinct 显示了读取的独立页个数。这只是基于用小哈希数组表示的整个缓冲池的近似值，因为有可能需要用很大的内存来映射所有页。同一个查询却产生不准确的读取页数量增长可能是发生了哈希冲撞的缘故。
如果查询中没有用到InnoDB，则相关日志行变成下面这样，其他的不变：

# No InnoDB statistics available for this query

注意：尽管该补丁已经做过压力测试，并且还在实际环境中使用过，但仍然建议不要在非常重要的系统中使用，万一出了问题，人家可不负责啊 :)

注：本系列文章主要探讨 MySQL 内存利用以及执行计划相关的一些知识点，从而为 MySQL 优化打下更好的基础。

环境说明

OS: AS4U6, 2.6.9-67.0.15.ELsmp, 16G Ram, MD3000阵列, xfs文件系统
MySQL 5.1.26 - percona(innodb plugin, innodb stat, user stat, msl, show patch, acc-pslist 补丁)

MySQL 主要配置参数

default_table_type = innodb
log_slow_queries
long_query_time = 0.001
log_slow_verbosity=query_plan,innodb
innodb_data_file_path = ibdata1:1024M:autoextend
innodb_log_file_size = 400M
innodb_log_files_in_group = 3
innodb_file_per_table
innodb_file_format="Barracuda"

其他参数均为默认值，因此其他几个内存相关参数值如下：

innodb_buffer_pool_size = 8388608
join_buffer_size = 131072
key_buffer_size = 8388600
max_heap_table_size = 16777216
query_cache_size = 0
read_buffer_size = 131072
read_rnd_buffer_size = 262144
sort_buffer_size = 2097144
tmp_table_size = 16777216

以后的所有例子中，如果没有特地注明，则测试相关的表都使用 InnoDB 引擎。

1、 排序缓冲

相关参数：sort_buffer_size, read_rnd_buffer_size

1.1 利用InnoDB的主键进行排序

EXPLAIN SELECT SQL_NO_CACHE * FROM T1 WHERE ID<10000 ORDER BY ID DESC;
+----+-------------+-------+-------+---------------+---------+---------+------+-------+-------------+
| id | select_type | table | type  | possible_keys | key     | key_len | ref  | rows  | Extra       |
+----+-------------+-------+-------+---------------+---------+---------+------+-------+-------------+
|  1 | SIMPLE      | T1    | range | PRIMARY       | PRIMARY | 8       | NULL | 14872 | Using where |
+----+-------------+-------+-------+---------------+---------+---------+------+-------+-------------+
# Query_time: 0.207893  Lock_time: 0.000056  Rows_sent: 9999  Rows_examined: 9999
# QC_Hit: No  Full_scan: No  Full_join: No  Tmp_table: No  Tmp_table_on_disk: No
# Filesort: No  Filesort_on_disk: No  Merge_passes: 0
#   InnoDB_IO_r_ops: 91  InnoDB_IO_r_bytes: 1490944  InnoDB_IO_r_wait: 0.083391
#   InnoDB_rec_lock_wait: 0.000000  InnoDB_queue_wait: 0.000000
#   InnoDB_pages_distinct: 93
SELECT SQL_NO_CACHE * FROM T1 WHERE ID<10000 ORDER BY ID DESC;

由于是针对主键/索引进行排序，因此无需使用临时表

1.2 利用 InnoDB 使用非索引字段排序

EXPLAIN SELECT SQL_NO_CACHE * FROM T1 WHERE ID<10000 ORDER BY C1 DESC;
+----+-------------+-------+-------+---------------+---------+---------+------+-------+-----------------------------+
| id | select_type | table | type  | possible_keys | key     | key_len | ref  | rows  | Extra                       |
+----+-------------+-------+-------+---------------+---------+---------+------+-------+-----------------------------+
|  1 | SIMPLE      | T1    | range | PRIMARY       | PRIMARY | 8       | NULL | 14872 | Using where; Using filesort |
+----+-------------+-------+-------+---------------+---------+---------+------+-------+-----------------------------+
# Query_time: 0.120879  Lock_time: 0.000023  Rows_sent: 9999  Rows_examined: 19998
# QC_Hit: No  Full_scan: No  Full_join: No  Tmp_table: No  Tmp_table_on_disk: No
# Filesort: Yes  Filesort_on_disk: Yes  Merge_passes: 1
#   InnoDB_IO_r_ops: 0  InnoDB_IO_r_bytes: 0  InnoDB_IO_r_wait: 0.000000
#   InnoDB_rec_lock_wait: 0.000000  InnoDB_queue_wait: 0.000000
#   InnoDB_pages_distinct: 93
SELECT SQL_NO_CACHE * FROM T1 WHERE ID<10000 ORDER BY C1 DESC;

由于 C1 不是索引字段，因此需要额外排序，并且由于 sort_buffer 和 read_rnd_buffer 不够大，也用到了磁盘文件。
加大 sort_buffer_size，再看看

set session sort_buffer_size = 1024 * 1024 * 5;

再次执行刚才的测试，结果发生了变化。

# Query_time: 0.080727  Lock_time: 0.000030  Rows_sent: 9999  Rows_examined: 19998
# QC_Hit: No  Full_scan: No  Full_join: No  Tmp_table: No  Tmp_table_on_disk: No
# Filesort: Yes  Filesort_on_disk: No  Merge_passes: 0
#   InnoDB_IO_r_ops: 0  InnoDB_IO_r_bytes: 0  InnoDB_IO_r_wait: 0.000000
#   InnoDB_rec_lock_wait: 0.000000  InnoDB_queue_wait: 0.000000
#   InnoDB_pages_distinct: 93
SELECT SQL_NO_CACHE * FROM T1 WHERE ID<10000 ORDER BY C1 DESC;

可以看到，Filesort_on_disk 变成了 No, Merge_passes 也变成了 0，表示无需使用磁盘文件，而直接在内存里排序。

1.3 加大 read_rnd_buffer_size 看看对 filesort 是否有影响

EXPLAIN SELECT SQL_NO_CACHE * FROM T1 AS T1 WHERE ID<10000 ORDER BY C1 DESC;
+----+-------------+-------+-------+---------------+---------+---------+------+-------+-----------------------------+
| id | select_type | table | type  | possible_keys | key     | key_len | ref  | rows  | Extra                       |
+----+-------------+-------+-------+---------------+---------+---------+------+-------+-----------------------------+
|  1 | SIMPLE      | T1    | range | PRIMARY       | PRIMARY | 8       | NULL | 14872 | Using where; Using filesort |
+----+-------------+-------+-------+---------------+---------+---------+------+-------+-----------------------------+
# Query_time: 0.103654  Lock_time: 0.000045  Rows_sent: 9999  Rows_examined: 19998
# QC_Hit: No  Full_scan: No  Full_join: No  Tmp_table: No  Tmp_table_on_disk: No
# Filesort: Yes  Filesort_on_disk: Yes  Merge_passes: 1
#   InnoDB_IO_r_ops: 0  InnoDB_IO_r_bytes: 0  InnoDB_IO_r_wait: 0.000000
#   InnoDB_rec_lock_wait: 0.000000  InnoDB_queue_wait: 0.000000
#   InnoDB_pages_distinct: 93
SELECT SQL_NO_CACHE * FROM T1 AS T1 WHERE ID<10000 ORDER BY C1 DESC;

具体过程不再每次重复贴了，结果是从 1M 到 512M，发现一直没什么变化，对 filesort 没什么帮助。 待续......

原文： http://blog.sina.com.cn/s/blog_48ea108c0100agq1.html

看看所谓砖家的言论吧

哈哈，利用阿里妈妈广告上月的全部收入：4.19，小小心意 :)

一、前言

随着安全要求的提高，我们逐渐采用sftp或scp来取代ftp。然而，可能由于网络状况等原因，使得scp/sftp可能发生中断。为此，不得不很痛苦的重新拷贝文件，不仅麻烦，还严重浪费带宽和时间。在这里，我们采用rsync over ssh的方式，既安全又方便，因为rsync支持断点续传。

二、配置rsyncd.conf

rsyncd.conf只需做非常简单的判断，即可直接使用，贴一下我自己的例子：

#/etc/rsyncd.conf

#常规设定
uid = nobody
gid = nobody
use chroot = no
max connections = 5

#设定日志
syslog facility = local5
pid file = /var/run/rsyncd.pid

#多种方式设定许可hosts列表
hosts allow=192.168.0.1,192.168.0.2,192.168.1.0/255.255.255.0

#设定rsyncd目录
[backup]
  path = /home/yejr/

  #如果同时还允许上传文件，把 read only 设成 false 即可
  read only=false

由于采用的是rsync over ssh，因此无需启动rsyncd实例，而是通过ssh来rsync，非常简单。
注意到上面的 read only=false，可能很多人认为rsync只能用于下载，不能上传，其实不然，这么设置一下之后，就可以利用rsync上传文件了。
看下面的例子。

三、使用

1. 下载文件

rsync -P -av --timeout=10 --rsh="ssh -l yejr" 192.168.0.84::backup/yejr/ /home/yejr/

把服务器上的目录 /home/yejr/ 上的所有文件下载到本地目录 /home/yejr/ 下。
在这里，需要注意目录名后面是否带上了目录分解符 /，如果有，那么只处理目录下的文件，如果不带，则把目录名本身也下载了。

2. 上传文件

rsync -P -av --timeout=10 --rsh="ssh -l yejr" /home/yejr/ 192.168.0.84::backup/yejr/

把 /home/yejr/ 目录下的文件上传到服务器 /home/yejr/ 下。即：/home/yejr/*。

3. 上传目录结构

rsync -P -av --timeout=10 --include '*/' --exclude '*' --rsh="ssh -l yejr" /home/yejr/ 192.168.0.84::backup/yejr/

or

rsync -P -av --timeout=10 --include '*/' --exclude '*' --rsh="ssh -l yejr" 192.168.0.84::backup/yejr/ /home/yejr/

有些时候，我们需要先同步一下目录结构而无需上传/下载文件，就采用这种方式。

上面的例子中，我已经采用ssh key的方式建立了信任关系，因此无需每次输入密码。

关于三鹿奶粉事件ccav的最新报道：目前，有毒奶粉的责任方三鹿正把责任推给奶站，奶站把责任推给奶农，奶农把责任推给奶牛，警方正全力抓捕不法奶牛。据报道，责任奶牛已携二奶、三奶们潜逃，仅捕获一小撮不明真相的牛群（并非说相声的那个）。目前母牛们情绪稳定。。。。。另据最新消息，水牛、黄牛、牦牛和蜗牛已通过半岛电视台发表声明，声称和此事件无关……

查看电池相关信息

MegaCli -AdpBbuCmd -a0

就可以看到跟raid卡电池相关的信息了，例如：

Relative State of Charge: 94 %
Charger Status: Complete
或者
Discharging             : Yes
Initialized             : Yes
还有
Auto Learn Period: 7776000 Sec
Next Learn time: 274648826 Sec
Learn Delay Interval:0 Hours
Auto-Learn Mode: Enabled

得到和电池相关的一些信息。
另外，还可以通过这个命令知道下一次raid卡电池充电信息：

/usr/sbin/MegaCli -fwtermlog -aall

查看结果中最后一次出现的：

08/24/08 12:28:07:       *** BATTERY FEATURE PROPERTIES ***
08/24/08 12:28:07:  _________________________________________________
08/24/08 12:28:07:       Auto Learn Period     : 90  days
08/24/08 12:28:07:       Next Learn Time       : 280672087
08/24/08 12:28:07:       Battery ID            : 36a804d0
08/24/08 12:28:07:       Delayed Learn Interval: 0  hours from scheduled time
08/24/08 12:28:07:       Next Learn cheduled on: 11 22 2008
08/24/08 12:28:07:  _________________________________________________

就可以知道下一次充电预计发生在 2008-11-22 这个时间了，注意它用的是美国时区，不是中国的，呵呵。

大家好：
我有一个表用MyISAM做存储引擎，其中含有三个BLOG字段用来存图片，当这个表有1800多条记录时，对主键进行查询（不查三个BLOG字段)，需要要20多秒。当把存储引擎换成InnoDB时，几乎瞬间完成。
我不明白，不是MyISAM比较快吗，还是MyISAM对大字段查询支持不太好。

事件类型: 警告
事件来源: MySQL
事件种类: 无
事件 ID: 100
日期: 2008-9-2
事件: 6:03:15
用户: N/A
计算机: YC2
描述:
Changed limits: max_open_files: 2048 max_connections: 1910 table_cache: 64

For more information, see Help and Support Center at http://www.mysql.com.

超出链接大小了吗？

如何解决？
mysql 5.1
怎么解决

TCMalloc 是用于优化C++写的多线程应用，比glibc 2.3的malloc快。详细说明请看TCMalloc：线程缓存的Malloc。这里我只测试它对mysql的影响到底有多少；从测试结果来看，数据量较小时，采用TCMalloc还是值得的，但是数据量较大之后，貌似反而更差了。本次测试采用sysbench工具，实际表现还是放到真正运行环境中才能知晓了。

明明是64位系统下，有16G内存，启动mysqld时指定 innodb_buffer_pool_size 为12G，却报一下错误：

080829 14:15:14  mysqld started
InnoDB: HugeTLB: Warning: Failed to allocate 12884918272 bytes. errno 22
InnoDB HugeTLB: Warning: Using conventional memory pool
080829 14:15:14  InnoDB: Error: cannot allocate 12884918272 bytes of
InnoDB: memory with malloc! Total allocated memory
InnoDB: by InnoDB 44607312 bytes. Operating system errno: 12
InnoDB: Check if you should increase the swap file or
InnoDB: ulimits of your operating system.
InnoDB: On FreeBSD check you have compiled the OS with
InnoDB: a big enough maximum process size.
InnoDB: Note that in most 32-bit computers the process
InnoDB: memory space is limited to 2 GB or 4 GB.
InnoDB: We keep retrying the allocation for 60 seconds...
InnoDB: Fatal error: cannot allocate the memory for the buffer pool
Warning: Failed to allocate 29360128 bytes from HugeTLB memory. errno 12
Warning: Using conventional memory pool
080829 14:16:14 [Note] /usr/local/mysql/bin/mysqld: ready for connections.
Version: '5.0.45-log'  socket: '/home/mysql/mysql.sock'  port: 3306  MySQL Community Server (GPL)

是不是很奇怪呢？
根据错误提示的内容，google一下，发现是内核限制的缘故：

[root@yejr mysql]# cat /proc/sys/vm/nr_hugepages
6000

修改一下内核限制：

[root@yejr mysql]# echo 0 > /proc/sys/vm/nr_hugepages

然后重启mysql，一切正常了。
另外，还需要关注一下配置文件 /etc/security/limits.conf 里的内容。

我搭建了一个很简单的MySQL集群,由于建表时需要加engine=ndbcluster ,或者建表以后需要修改表类型.
我的项目是通过hibernate来建整个数据库的,所以我想通过修改配置文件的方式来实现普通建表就能在MySQL集群里面用.
我上网查了,在my.cnf里面添加 default-storage-engine=ndbcluster , 但是我添加了以后, MySQL 无法启动了, 也没有报任何信息, 就是starting MySQL.............ERROR. 改成default-storage-engine=MyISAM,或者default-storage-engine=INNODB也一样无法启动. 但是去掉又可以了.
我下的版本是:mysql-max-5.1.5-alpha-linux-i686-glibc23.
谁能教教我,现在要怎么做?

习惯了*nix下的命令行，相信回到windows的命令行窗口后还是有些不习惯，没关系，现在可以用unix like commands工具包了，呵呵。

我自己也从各个地方收罗了其他命令行工具，打成一个包了，欢迎下载。比较有用的命令有：ls, bzip2, cat, cp, cut, diff, fping, (e)grep, gzip, md5, ps等等。

友情提示：想要下载本站的附件，必须注册账号，然后登录才行，这么做是为了防止被某些流氓工具盯上。

最重要的就是方便，可以支持一下子ping多个ip。

linux版本的自己找个安装包或者源码编译一下，windows下也有哦，看这里。 enjoy it :)

my.cnf 自动生成器，当前处于试用版本阶段，欢迎大家提出宝贵建议，谢谢。
本工具产生的配置文件仅作参考用途，对此带来的后果本站不符任何责任，请注意使用。

目的是为了防止他人修改grub，用单用户模式启动。

grub加密码只需要修改grub启动文件，增加一行 password 关键字，可以采用明文存储或者 MD5 加密后存储。下面我们介绍一下用 MD5 加密的方式。

1、先用 /sbin/grub-md5-crypt 产生一个 MD5 密码串

/sbin/grub-md5-crypt
Password: 
Retype password: 
$1$oWpTe$/MWUUYbBlF.2RUZK8nbWU0

原始密码是 "abc"。

2、修改 grub.conf 文件

default=0
timeout=5
splashimage=(hd0,0)/boot/grub/splash.xpm.gz
hiddenmenu
password --md5 $1$oWpTe$/MWUUYbBlF.2RUZK8nbWU0
title Red Hat Enterprise Linux AS (2.6.x-xx.EL)
.........

 
这里要注意， password 这样必须加在 splashimage 和 title 之间这段，否则不能生效。
然后重启机器，就会发现想要修改 grub 菜单，就必须要先按 P 然后输入正确的密码才可以继续了。

再附上一个用 sed 修改 grub.conf 方法，可以利用这个方法批量修改所有的服务器。

GRUB=/boot/grub/grub.conf
TEMP=/tmp/grub.conf
grep -v password $GRUB && cat $TEMP | sed -e 's/hiddenmenu/hiddenmenu\npassword --md5 \$1\$oWpTe\$\/MWUUYbBlF.2RUZK8nbWU0/g' > $GRUB

现场气氛就是好吖，中国观众真是热情，日本人特别被安排在我们后方不远的地方，不过加油声音远比我们小多了。最后女排不负众望，3:0完美拿下。开局差点大比分落后，还好追上来了，没让我的手掌白白拍红了，欧耶。

Leading Online Advertising Firms Select MySQL to Help Power their Business

原来数据的字符为gbk,倒出的时候指定为latin1导出了请问有啥方法可以恢复吗?