沙漠之周的Blog

修改完/etc/my.cnf的配置一直没有重启，今天重启了一下，看似一切正常，但是却没法访问原有的数据表，出现类似的提示：
Incorrect information in file: './DATABASE_NAME/TABLE_NAME.frm'

仔细查看mysql的错误日志文件，发现提示ib_logfile0文件大小设置不正确：

InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes
InnoDB: than specified in the .cnf file 0 268435456 bytes!

下面即时具体受影响的数据表信息。

显然mysql启动时会对比ib_logfileN和配置里设置的文件大小，可见是我更改innodb_log相关的配置导致的：
> innodb_log_file_size = 256M
> innodb_log_files_in_group = 3
< innodb_log_file_size = 5M
< innodb_log_files_in_group = 2


改回以前配置就没有问题了。

如题，发贴暗自庆贺一下，废话不多说，以免又被人误以为咱这里包含敏感内容。。。

Happy new year!

事实证明，rsync是个很好的备份工具，无论目标地址是网络还是本地。

1. 备份本地根目录下/dev, /home目录意外的目录
rsync -av --exclude=/dev --exclude=/home / /mnt/sdb1/root/

2. 通过ssh拷贝（备份整个目录的文件）
rsync -av smzz.org:/file/to/path/ /file/to/path/

反过来上传目录也可以：
rsync -av /file/to/path/ smzz.org:/file/to/path/

非默认ssh端口下，以56789为例
rsync -av -e 'ssh -p 56789' /file/to/path/ smzz.org:/file/to/path/

当然，也可以通过rsync自己的协议备份数据，网上例子很多，就不在此累赘。

需要特别注意的时，如果是备份目录，源目录一定要对应上，特别是后面的斜杠，否则就差之毫厘失之千里，
比如：
如果写成
rsync -av /file/to/path smzz.org:/file/to/path/

步骤：
1. 删除相关的输入法，我用的是scim:
ls /var/log/packages | grep scim | xargs sudo removepkg

2. 安装ibus，我是从SBo上下载的安装脚本（链接）
同时还需要gconf、pyxdg两个软件包。

3. 更改配置
sudo chmod +x /etc/profile.d/ibus.{csh,sh}

4. 重启X即可

注意：
1. ibus-qt不是必须的
因为我依然可以在opera、freemind等基于qt的程序里调用ibus输入中文

2. 有关scim以及输入法相关的配置，可参见slackware里的CHANGES_AND_HINTS.TXT文件

rsync -av -e 'ssh -p 2222' /home/svn/repos2/ smzz.org:/home/zhouguoqiang/svn/repos/

这样即便远程ssh不是默认的22端口，也可以通过rsync同步文件

周末参加了2009系统架构师大会，期间对自己感兴趣的话题做了部分笔记，现摘录如下：

大型可扩展系统架构-新浪网动态应用平台介绍

童剑 新浪高级系统架构师，研发中心平台部总监

在使用MySQL时，印象中Innodb表无法进行事务之间的嵌套，其实是有条件的：同一个连接里的事务无法嵌套，但不同连接之间的事务却可以嵌套。

<?php
$dsn = 'mysql:dbname=test;host=127.0.0.1';
$user = 'root';
$password = 'root12';

try {
    $dbh = new PDO($dsn, $user, $password);
    $dbh2 = new PDO($dsn, $user, $password);
} catch (PDOException $e) {
    echo 'Connection failed: ' . $e->getMessage() . "\n";
}

try {
    $dbh->beginTransaction();
    if (true) {
        $dbh2->beginTransaction();
        $dbh2->commit();
    }
    $dbh->commit();
    echo "It's OK.\n";
} catch (Exception $e) {
    echo "Transaction Faild: " . $e->getMessage() . "\n";
}

?>

今天犯了一个很低级的错误，通过命令行恢复一个mysqldump出来的很大的文件时，由于没有没有将它放到后台进行，运行几个小时之后突然由于超时而中断与远程服务器的连接了。幸好可以通过SQL语句导出导入部分记录的数据：

导出：

SELECT * FROM park_log WHERE pl_id > 51025594 INTO OUTFILE '/tmp/apps_park_log_51025594.txt';

导入：

 LOAD DATA INFILE '/data1/apps_park_log/xB' INTO TABLE park_log;

yejr曾经测试比较，LOAD DATA比导入SQL文件快，但由于LOAD DATA必须所有操作进行完之后才向数据库里写记录，所以有时候往往会感觉LOAD DATA比较慢。我刚操作一个数千万行的文件时，还以为程序没有工作而手动中止了。真是一个活生生的例子。

操作远远没有想象中的复杂：先通过wordpress将原Blog内容导出为一个WXR格式的文件，然后通过Drupal的Wordpress Import模块，点几下鼠标即可将wordpress的内容转移至durpal里。

为了简化url，这次干脆将drupal程序放到了网站的根目录，值得一提的是，转换前后blog的feed订阅地址都没有变，不知道是不是巧合。

fdisk /dev/sdb
mkfs.ext3 /dev/sdb1

mkdir /data1
e2label /dev/sdb1 /data1
然后编辑/etc/fstab文件，添加如下内容
LABEL=/data1 /data1 ext3 defaults 1 0
然后mount -a

e2labe就好像给一个磁盘设备添加标签，便于记忆。不过我觉得挂载时还是使用设备标识（如/dev/sdb1）比较明显一些。