MySQL 不能启动一例

现象为，启动、长时间等待，最后失败。
查看错误日志，没有任何有效信息。

060929 12:14:36 mysqld started
060929 12:14:36 mysqld ended

查看系统日志 /var/log/messages，能看到形如

Sep 29 11:51:46 localhost kernel: audit(1159498306.605:23): avc: denied { append } for pid=17579 comm="mysqld" name="mysql.err" dev=hda3 ino=4212878 scontext=root:system_r:mysqld_t tcontext=root:objec
t_r:var_lib_t tclass=file
Sep 29 11:51:46 localhost kernel: audit(1159498306.605:24): avc: denied { append } for pid=17579 comm="mysqld" name="mysql.err" dev=hda3 ino=4212878 scontext=root:system_r:mysqld_t tcontext=root:objec
t_r:var_lib_t tclass=file
Sep 29 11:51:46 localhost kernel: audit(1159498306.674:25): avc: denied { create } for pid=17579 comm="mysqld" name="mysql.sock" scontext=root:system_r:mysqld_t tcontext=root:object_r:var_lib_t tclass=sock
_file

排查后，发现为 selinux 所不容，关闭之，解决。

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 参考手册第六章。

noticpan.org update 060912

毛坯房在 perlchina 广告了一下，应者寥寥。也是，过分粗糙了，各方各面都是。同时，如期开始了装修工程。到现在为止，第一期简装已经完毕，还是很丑？多多包涵，多多包涵。期间自己在使用中发现了几个 BUG，都一一予以修正。还有部分功能缺失，如注销、忘记/更改密码等，也会于近日慢慢补上。
出乎意料的是，我自己订阅了 10+ 个模块，竟然两个多星期来没有受到一个更新通知，搞笑了，受打击了。但是不能气馁，要相信这个服务肯定是有用的，嗯嗯。
天色不早了，该休息了，各位晚安。

noticpan.org online

从想法到实施，花了三个周末，昨晚 noticpan.org 上线了。
最基础的邮件提醒功能已经可用，其他一切都处于史前文明水平，留待日后慢慢开化。
不容易啊，在虚拟主机上搭建 Catalyst 的应用程序。Catalyst 本身已经做得很好了，还有详细的教程说明如何在虚拟主机搭建站点。
革命尚未成功，同志还需努力！