Installing MySQL 5.4.0 on Cygwin

First of all, it was an installation from source.

./configure
make
make install

The commands above didn't work.

A try:

./configure
make
......
gcc -DHAVE_CONFIG_H -I. -I../../include -I../../include -I../../include -O3 -MT readline.o -MD -MP -MF .deps/readline.Tpo -c -o readline.o readline.c
In file included from readline.c:54:
readline/readline.h:70:29: sys/ttydefaults.h: No such file or directory

Cygwin provides no file named `sys/ttydefaults.h'. Someone said a copy from a *nix distribution would help.
I didn't try it 'cause MySQL provides an option to skip the bundled readline kindly.

Another try:

./configure --without-readline
make
......
g++ -DUNDEF_THREADS_HACK -DDEFAULT_MYSQL_HOME="\"/usr/local\"" -DDATADIR="\"/usr/local/var\"" -I. -I../include -I../include -I../include -I../regex -O3 -fno-implicit-templates -fno-exceptions -fno-rtti -MT mysql.o -MD -MP -MF .deps/mysql.Tpo -c -o mysql.o mysql.cc
mysql.cc:1030: error: redefinition of `struct _hist_entry'
../include/readline/readline.h:46: error: previous definition of `struct _hist_entry'
mysql.cc:1033: error: ISO C++ forbids declaration of `HIST_ENTRY' with no type
mysql.cc:1033: error: conflicting declaration 'typedef int HIST_ENTRY'

I have little knowledge about compiling, so what I can do is only to guess, change options and have another try.
However, I'm lucky! I found the problem is caused by the option `-O3', well, actually is the inner `-frename-registers'. To set CFLAGS=-O2 or CFLAGS=-fno-rename-registers can help. Also, gcc-4 seems ok. Maybe gcc-3 is the bad, I don't know.

My compiler, which is the latest default compiler on Cygwin.

$ gcc -V
gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Yet another try:

./configure --without-readline CFLAGS=-O2
make
make install

Done.

P.S.1. The configure option `--with-plugin-partition' doesn't work. The MySQL guy said the issue is not repeatable with current development sources. So, just using `--with-plugins=partition' instead.

P.S.2. Cygwin is not supported for MySQL.(I didn't know that.)

MySQL Users Conference Japan 2007 講演資料公開

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

MySQL Users Conference Japan 2007 参加登録者の方へ

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

この度は、悪天候の中、MySQL Users Conference Japan 2007にたくさんの方にお越しいただき、誠にありがとうございました。カンファレンス資料を公開致しました。
http://www.mysql-ucj2007.jp/session/index.html

見逃してしまったセッション、もう一度見たいセッションがございましたら、ぜひお早めにダウンロードをお勧めいたします。10月31日まで公開しております。なお、都合により非公開の資料もございます。予めご了承ください。

次回 MySQL カンファレンスに対するご要望をお持ちの方は、ucj@mysql.com までお知らせください。


MySQL Enterprise にご興味のある方は、下記サイトでご紹介しております。
http://www-jp.mysql.com/products/enterprise/
MySQL Enterprise 30日トライアルも実施中です。

購入に関するお問い合わせは、03-5918-7507 までご連絡ください。

この度は、MySQL カンファレンスへのご登録およびご来場、ありがどうございました。

MySQL 株式会社

MySQL Users Conference Japan 2007 - 1

今天是大会第一天，由于路线选择错误，我花了近两小时才抵达会场，台场真的是好远啊。

迟到了一小时，所以错过了 E11（MySQL 高可用性解决方案简介 by Jimmy Guerrero）。

所以就从 J12（使用 DRBD 和 heartbeat 搭建高可用性 MySQL by Patrick Bolduan of MTV Japan）开始了。介绍了一个的案例，2 个 MySQL Master 节点，heartbeat 管理共享的 Virtual IP 以及 MySQL 实例，DRBD 实现数据同步。
这个方案的优点在于不需要人工干预就能实现 failover，M/S Replication 架构如果不考虑事后重建 Slave 这档子事儿的话也算是可以自动化的。缺点是，2 个数据库节点只能用其中 1 个，稍微有些浪费资源。关于 DRBD，一个问题是它本身有开销，会导致 MySQL 性能有一定程度的下降，另一个问题是在数据量大到某种程度后，安全性并不是非常可靠，Patrick 介绍他们测试下来，50GB 左右还是安全的。我对 DRBD 几乎没什么了解，找时间看看。

接下来是 E13（MySQL Performance Tuning and Benckmark by Colin Charles of MySQL AB）。介绍了一下 Tuning 和 Benckmark 的方向和若干工具，因为多数内容都有所了解，基本没有留下笔记。Peter 的 mysqlperformanceblog 大家都说不错，值得常去逛逛。

最后是 E14（面向 Web 2.0 的 MySQL 架构 by Brian Aker）。讲的内容面比较广，这里就略了，有时间以后再补上。Brian 重点推荐了一下 EC2，记一下。

参考链接：MySQL Users Conference Japan 2007

MySQL Community Server 5.0.41 is released

其中，我最关注的 bug fixed 是这个：

Loading data using LOAD DATA INFILE may not replicate correctly (due to character set incompatibilities) if the character_set_database variable is set before the data is loaded. (Bug#15126)

摔过跟头，自然印象深刻。

MySQL 子查询一例

到目前为止，MySQL 还不能支持这样的操作，子查询的 FROM 字句和更新/删除对象不能使用同一张表。

mysql> DELETE FROM tab1 WHERE col1 = ( SELECT MAX( col1 ) FROM tab1 );
ERROR 1093 (HY000): You can't specify target table 'tab1' for update in FROM clause

针对“同一张表”这个限制，撇开效率不谈，多数情况下都可以通过临时表来变通解决，像这样

DELETE FROM tab1
WHERE col1 = (
  SELECT MAX( col1 )
  FROM (
    SELECT * FROM tab1
  ) AS t
);

参考链接：
MySQL 5.0 Reference Manual - Subquery Errors

用好 MySQL 字符集

我们都知道，MySQL 支持 30 多种字符集，其中包括了我们常用的 gb2312、gbk 和 uft8 等字符集。

在很多简单应用场合下，字符集设置是可有可无的。把后台存储的视为裸数据（raw data），存入的数据可以被原封不动地取出，对于前端的处理及应用，通常是不会有问题的。

当然，不设置正确的字符集，在实际应用中也有诸多不便之处。假设情况是这样的：

前端应用：GB2312
后端存储：latin1

那么大概会得到这样的结果：

字符终端（GB2312环境）：正确
phpMyAdmin：乱码
MySQL Query Browser：乱码

如果你是个完全无视 GUI 管理工具的开发者，那么无视字符集设置就是了。

设置合适的字符集，我觉得主要是可以获得 GUI 管理工具强大支持。除此以外，其实用处并不是很多，以我的使用经验为例，只是用来做文本排序。

那么以 Perl 为例，说说我的经验，怎样使用合适的字符集，情况如下

前端应用：GB2312
后端存储：utf8

设置字符集可以分为四个环节：

客户端 <-> 前端 <-> 连接 <-> 后端

客户端，这里指浏览器。当前输出内容编码为 GB2312，所以应该在 HTML 头部加入如下语句：

<meta http-equiv="Content-Type" content="text/html; charset=GB2312">

通常，即使没有上述语句，多数浏览器也能“猜”出正确编码，这是题外话，不深入了。

前端，这里指数据处理程序。因为后端存储是 utf8，所以在这里需要把数据从 GB2312 转为 UTF8，就绪。

use Encode;
Encode::from_to( $data, 'euc-cn', 'utf8' );

连接，这里指由程序创建的数据库连接。通常我们这样连接数据库：

use DBI;
my $dbh = DBI->connect('dbi:mysql:database=test;host=localhost', $user, $password);

为了加入字符集信息，需要在连接后执行下面的命令：

$dbh->do('SET NAMES utf8');

声明了输入输出使用的都是 utf8 字符集。要保证建立连接后，首先执行字符集声明。

这在某些自动重连的情况下可能会失效，我推荐用读取配置文件的方式声明连接字符集。

首先，在配置文件 /etc/my.cnf 中加入字符集设置

[client]
default-character-set=utf8

然后，连接语句相应地改为

my $dbh = DBI->connect('dbi:mysql:database=test;host=localhost;mysql_read_default_file=/etc/my.cnf', $user, $password);

或者

my $dbh = DBI->connect('dbi:mysql:database=test;host=localhost;mysql_read_default_file=/etc/my.cnf;mysql_read_default_group=client', $user, $password);

这样保证了创建连接前就能读取到字符集设置。

后端，这里指 MySQL 数据库。在建表或数据库时，声明字符集

CREATE TABLE (
  ...
) CHARSET utf8;

以上就是各环节字符集的设置，一些描述乃属经验记忆，难免会有错漏，还望海涵。更多请参阅 MySQL 参考手册相关章节。

MySQL 的选项和变量

不得不说，MySQL 对于开发者是越来越友好。
关于可用的选项和变量，在参考手册中已经有了专门的章节，很好用。

MySQL Replication 浅尝

虽然 RAID 1 可以避免硬盘的物理损坏带来的损失，但是如果整机发生故障，单节点的数据库（相信一般的中小型站点都是）依然会造成服务陷入较长时间不可用的状态。所以需要导入其他高可用方案，于是我认识了 MySQL Replication。

MySQL Replication 从 MySQL 3.23.15 开始被引入，包含于标准的 MySQL 发行版，可以实现完全复制另一个数据库，而且配置方法很简单，主要有以下几点。

一、主（被复制方）从（复制方）数据库使用相同版本，或者从数据库可以高于主数据库。反之则有较大风险，因为复制（replication）是基于操作（statement）的，而不是基于数据行（row）的，所以高版本的某些操作可能无法被低版本正确执行。MySQL 5.1 开始会引入基于数据行的复制（replication），是个很值得期待的新特性。

二、主从双方的初始数据状态要严格一致，即从库的初始数据要和主库二进制日志（binary log）指定的复制起始点所在时刻的数据要一致。如果备份方案是计划的一部分，那么这不算是个问题，一切都从零开始。但若是要对一个正在运行的数据库实施复制（replication），就不是件那么令人愉快的事情了，烫手山芋就是如何取得一个某时刻下完整的数据拷贝，MySQL 并没有提供一个像样的热备解决方案。如果是个纯 innodb 数据库的话，还能从 InnoDB 的提供商 Innobase Oy 那里获取一个热备工具，当然，价格不菲。除此以外，停机备份几乎是不可避免的，代价取决于数据量。

三、主库需要开启二进制日志，以及创建一个特权用户。从库则相应地在配置文件中指定使用该用户，另外可按需设置复制（replication）数据库（schema）的黑名单或白名单，一般来说，可以把 mysql 和 test 加入黑名单，即在复制时忽略这两个数据库的一切操作。

准备就绪后，只需要启动从数据库，实施备份就开始了。从库上有两个工作线程，其一负责从主数据库读取日志，写入本地中继日志（relay log），其一负责根据中继日志进行数据操作，两者交错工作。

主从数据库中的表类型（Engine）可以是不同的，这一特性可以带来多少效益完全取决于你的创意。简单点的例如，主库中表 A 使用 InnoDB 来满足较大量的并发读写操作，而从库的表 A 则使用 MyISAM 来创建全文索引实现全文检索，或者从库全部使用 ARCHIVE 来节省硬盘空间等等。

MySQL Replication 是单向的，但是从数据库同时可以扮演主数据库的角色，所以双向备份是可以有条件地实现的。主要障碍是数据同步存在延时（虽然正常情况下是毫秒级别的）所以无法保证数据库群任意时刻都拥有相同的数据，一定程度上可以通过全局性的读写规划和设置复制（replication）黑白名单来减轻这个问题，但总的来说是个比较冒险的做法。

在实际应用中我遇到过这样的问题，对于受 DATABASE CHARSET 影响的 LOAD DATA 操作（statement），从数据库并不能正确地复制（replication）这一操作（statement），效果等同于从数据库的 DATABASE CHARSET = latin1，是否是 bug 有待于 MySQL 开发者的验证。

更新：
06-10-23 已被确认为 bug，并被判与 15126 重复，后者提交日为 05-11-22。
07-05-01 MySQL Community Server 5.0.41 发布，bug fixed。

其他的，更多的，可以参阅 MySQL 参考手册第六章。

MySQL可靠吗？

由于工作的原因，一直用着MySQL，一来是免费，二来简单易用。
但是随着应用的扩展，对于功能和稳定性的要求也越来越高。最近遇到了一件事情，让我觉得很是不爽，MySQL究竟可不可靠？

事情是这样的，安装完MySQL之后，在简单配置了my.cnf和启动测试之后，就清掉了binlog打算投入使用了。由于经验不足，没有删除ib_logfileX，又因为在第一次启动后修改了配置文件，已创建的ib_logfileX的文件大小和配置文件中的innodb_log_file_size不一致，导致了接下来的问题。
启动MySQL，OK。导入预先准备好的SQL脚本，OK。然后，发现了原来显式声明了Engine=InnoDB的表全部创建成了MyISAM模式。
SHOW ENGINES;后看到InnoDB的状态为DISABLE，很是莫名……最后在hostname.err里面看到，因为innodb_log_file_size的问题，导致了：
1）InnoDB被自动禁用了
2）创建InnoDB模式的表的时候，自动转成了MyISAM

我觉得不满的是，InnoDB被禁用只是在日志里这么一笔带过，终端上没有任何警告信息。据说*nix程序的普识原则是没有输出就是没有错误，难道MySQL认为这只是个小问题，并不会影响用户使用？！之后的自动转换模式就是个衍生问题了，虽然有WARNING，不过在批处理模式下显然是没有任何帮助的了。

问题虽然很好解决，删除innodb-log，重启MySQL，ALTER TABLE，就可以了。但是如果问题发现的晚，或者系统不能轻易下线，那损失就不好估算了。