kazuho’s cosmic at master - GitHub

概要 (というか近場の目標) は、以下のとおり。

• fail-safe な network RAID
  • 多重マウントが発生しないプロトコルを実装
  • RAID だから DRBD や MySQL の async replication のような lost updates 問題がない
  • software RAID + NBD を使用 (NBD は遅いから iSCSI 対応するかも)
• RDBMS レベルのレプリケーションや DRBD と異なり、高可用性のあるブロックデバイスを提供するソフトウェアレイヤとして機能
  • 様々なストレージミドルウェアを統一的に管理可能なので、管理コストが低い
  • バックアップとかもブロックデバイスレベルで統一的に。
• スケールアウトに好適
  • ソフトウェアを止めずに使用するディスクの引っ越しとか可能

背景としては、MySQL とか PostgreSQL とか mogilefs みたいな分散ファイルストアとか、それぞれレプリケーション手段が異なるので面倒だった。要件定義の段階でそれぞれ検討しなきゃいけないし、なんといっても運用が面倒。

かといって EqualLogic とか? フェイルオーバー機能を備えたストレージって馬鹿高いし。SAN が現実的な時代なんだから、ネットワーク越しに RAID 組んだらいいよね、という感じ。

もうちょっとできたら会社ブログに書く。

まずはダウンロードとインストール

shell> sudo yum install mysql

shell$gt; sudo apt-get install mysql

設定

[mysqld]
# basic settings
user = mysql
port = 3306
socket = /tmp/mysql.sock
character-set-server = utf8
datadir = /var/lib/mysql
tmpdir = /var/tmp/mysql
log_slow_queries
max_connections = 500
thread_cache_size = 500
max_allowed_packet = 16M
table_cache = 2000
#log-bin = mysql-bin
#server-id = 1
innodb_buffer_pool_size = 2500M
innodb_flush_method = O_DIRECT
innodb_log_file_size = 256M
innodb_log_buffer_size = 8M

ユーザーの作成とか初期化とか

ユーザーの作成とか
shell> sudo mkdir /var/lib/mysql
shell> sudo groupadd mysql
shell> sudo useradd -g mysql -s /bin/false -d /var/lib/mysql mysql
shell> chown mysql:mysql /var/lib/mysql && chmod 700 /var/lib/mysql
shell> passwd mysql

データディレクトリの初期化とか
shell> cd /usr/local/mysql
shell> sudo bin/mysql_install_db --datadir=/var/lib/mysql
shell> sudo chown -R mysql:mysql /var/lib/mysql

自動起動とか
shell> sudo cp /usr/local/mysql/support-files/mysql.server /etc/init.d/mysql
shell> sudo update-rc.d mysql defaults

起動＆停止

rootになって、
shell> mysqld_safe &
または
shell> /etc/init.d/mysql start
または
shell> service start mysql

shell> mysqladmin -uroot -p shutdown
または、rootで
shell> /etc/init.d/mysql start
または、rootで
shell> service start mysql

rootパスワードの設定

CLIで接続

shell> mysql -h ホスト名 -P ポート番号 -u ユーザー名 -p[パスワード] --default-character-set=文字コード データベース名

[mysql]
user=ユーザー名
password=パスワード
default-character-set=utf8
port=3306
host=127.0.0.1

ユーザーの作成

mysql> GRANT ALL ON db1.* TO user1@host1 IDENTIFIED BY 'パスワード'

コネクタ

GUIとか

レプリケーション

バックアップとリストア

バックアップ
shell> mysqldump -hホスト名 -uroot -p データベース名 > dumpfile.sql

リストア
shell> mysql -hホスト名 -uroot -p データベース名 < dumpfile.sql

困ったら？

たとえば、MySQL を使ったお手軽メッセージキュー実装 - ドワンゴ 研究開発ブログに出てくるようなInnoDBをメッセージキューのように使っているときに、キューにどれだけメッセージが溜まってるかを確認したいとき、普通に考えるとCOUNTすると思う。

SELECT COUNT(*) AS count FROM test_queue;

この軽い気持ちでしたCOUNTが、もしうっかりキューに100万レコードぐらいあったりするとInnoDBだとPRIMARYキー総なめとかしちゃってレスポンスにかかる0.1秒ぐらいのあいだ罪悪感に苛まれることでしょう。

このとき冷静に考えると、もしキューが1件も処理されていなければ、idはauto_incrementなので特に細工していなければ

SELECT MAX(id) AS count FROM test_queue;

これも全体のレコード数に等しいでしょう。

キューが既に何件か処理されている場合でも、idが小さいほうから順番に処理されていくので

SELECT MAX(id) - MIN(id) + 1 AS count FROM test_queue;

これで全体のレコード数に等しくなるはずです。

EXPLAINを見ても

EXPLAIN SELECT MAX(id) - MIN(id) + 1 AS count FROM test_queue\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: NULL
         type: NULL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: NULL
        Extra: Select tables optimized away
1 row in set (0.01 sec)

Select tables optimized awayと出てるだけあってレコード数が増えても一瞬でレスポンスが返ってきます。

こういうユースケースは実際ないかもしれないけど、とりあえずメモ。

InnoDB はデフォルトでは同期I/O *1だけど、

innodb_flush_method=nosync

っていう隠しオプションがあって、それを有効にすると MyISAM みたく fsync しなくなるよ。ってソースコードちら見した自分が言ってた。

この設定がうれしいのって、どういう時だろう？

MySQL – Wikipedia | MySQL Expert | MySQL Performance | MySQL Scalability にも書いてあるけど、スレーブ運用してて「クラッシュしたらリカバリで数時間かかるし、データ一貫性チェックするくらいだったらバックアップからリストアして再開しちゃうもんね〜」的な向きにはおすすめなのかしらん。

とは言え、fsync しないってことは OS のページキャッシュに書込みデータが滞留することになる → buffer_pool 削る必要が出てくる → 無駄な I/O が増える、わけで、設定するメリットがあるかどうかは知らない。swappiness=0 にしといて、数百MBのページキャッシュに RAID BBU キャッシュと同等の役割をさせる、ってのはあるのかな。でも、そういうケースなら inndb_flush_log_at_trx_commit=[0|2] にしとけば同等のパフォーマンスが出そうに思う。

あるいは、バッファプールが小さい、ウェブサーバと MySQL を混在させているような環境で、MyISAM に迫るパフォーマンスを稼ぎたい時とかは便利なのかも。

• mysql 5.1.42
• InnoDB Plugin 1.0.6
• XtraDB 1.0.6-9

の場合。

InnoDB -> InnoDB Pluginで増えたオプション

innodb_adaptive_flushing       ON
innodb_change_buffering        inserts
innodb_file_format     Antelope
innodb_file_format_check       Antelope
innodb_io_capacity     200
innodb_old_blocks_pct  37
innodb_old_blocks_time 0
innodb_read_ahead_threshold    56
innodb_read_io_threads 4
innodb_replication_delay       0
innodb_spin_wait_delay 6
innodb_stats_sample_pages      8
innodb_strict_mode     OFF
innodb_use_sys_malloc  ON
innodb_write_io_threads        4

InnoDB Plugin -> XtraDBで増えたオプション

innodb_adaptive_checkpoint     estimate
innodb_checkpoint_age_target   0
innodb_dict_size_limit 0
innodb_enable_unsafe_group_commit      0
innodb_expand_import   0
innodb_extra_rsegments 0
innodb_extra_undoslots OFF
innodb_fast_recovery   ON
innodb_flush_neighbor_pages    1
innodb_ibuf_accel_rate 100
innodb_ibuf_active_contract    1
innodb_ibuf_max_size   2147467264
innodb_overwrite_relay_log_info        OFF
innodb_read_ahead      linear
innodb_recovery_stats  OFF
innodb_relax_table_creation    0
innodb_show_locks_held 10
innodb_show_verbose_locks      0
innodb_stats_auto_update       1
innodb_stats_method    nulls_equal
innodb_stats_update_need_lock  1
innodb_thread_concurrency_timer_based  OFF
innodb_use_purge_thread        1

それぞれのオプションについてはそのうち調べる。

死んだプロセス (あるいは kill したプロセス) の core イメージから自動的にスタックトレースを収集するデーモンを書いたので、これをセットアップしてサーバにインストールしとくといいかもです (bt_cores at master from kazuho’s kaztools - GitHub)。Linux のみ対応*1。使い方は bt_cores --help とするか、perl Makefile.PL && make install して man bt_cores。

具体的にいうと、Q4M とか Incline とか kazuho product が落ちたり固まったりしたらスタックトレース送ってくれると、私がうれしいです (古いバージョンのスタックトレースだととても悲しいです)。コアファイルは内部データがいろいろ入ってるから外部の人には見せられないけど、スタックトレースならテキストファイルだから、やばいとこだけ伏せ字にして送ってくれますよね？　えへ。

... ということで解決するはずだったんですが ...

MySQL の場合は MySQL Bugs: #21723: Should be able to dump core after setuid() under Linux が直ってないのを忘れてた。↑の方法は使えない ToT

しょうがないので Q4M が固まった場合は、

% echo 'thread apply all bt' > allbt.cmd

のようにして gdb のコマンドをあらかじめファイルに書き出していて、あとは

% sudo gdb -batch -x tmp/allbt.cmd /usr/local/mysql/libexec/mysqld `sudo cat /usr/local/mysql/data/localhost.pid` > stacktrace.txt

のようして全スレッドのスタックトレースが取って送ってください。この方法だと、SEGV で死んじゃったりした場合の情報が得られないのが痛いですが。なにはともあれ、よろしくお願いします。

Thanks to a user of Q4M, I have found a bug that would likely lead to data corruption on 32bit versions of Q4M.  64bit versions are unaffected.

Q4M by default uses mmap(2) to read from data files.  On 32bit systems, it tries to map max. 1GB per each table into memory using mmap.  When mmap fails to map memory due to low memory, Q4M falls back to file I/O to read the data.

However there was a bug in handling the response from mmap, that led to reading corrupt data from database files when mmap(2) failed after the size of the underlying file was grown / shrunk by Q4M.  And since Q4M writes back the corrupt data into the database file when rows are being consumed, the bug will likely destroy the database files.

I have fixed the bug and have uploaded Q4M 0.9.2, into the prerelease directory at q4m.31tools.com/dist/pre.  Source tarball and prebuilt binaries for MySQL 5.1.42 for 32bit linux are available.

If you are using 32bit versions of Q4M, I highly recommend either to update to 0.9.2 or switch to 64bit versions if possible.

BTW in 0.9.2 release, I also changed the maximum mmap size per table from 1GB to 256MB, to lower the possiblity of low memory.  However this countermeasure might not be sufficient in some cases, i.e. databases having many Q4M tables or if other storage engines also used a lot of memory.  I am considering of just disabling the use of mmap(2) on 32bit systems in future releases.  If you have any comments on this, please let me know.

• MySQL Serverインスタンスの起動と停止
• 設定（my.cnf）の編集
• ユーザーアカウントの管理
• セッション（クライアントからの接続）の管理
• サーバーのステータス監視
• データのバックアップ
• ログの表示

configureオプションで--with-libeventを指定してbuildしないとスレッドプーリングは使えナッシブルです！

とりあえず自分のmacbookには以下のようにして入れてます。

./configure --prefix=/usr/local/mariadb --with-charset=utf8 --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --with-pic --with-big-tables --with-readline --with-embedded-server --with-plugins=all --without-docs --with-libevent --with-debug
make
sudo make install

linux用のバイナリパッケージは--with-libevent付きなので展開してそのまま使って大丈夫。

んで、デフォルトのthread_handlingはone-thread-per-connectionなので、--thread_handling=pool-of-threadsオプション付きでサーバ起動すればスレッドプーリングで使える。

Motives and the Features

For the servers running in our new network, I was in need for a highly configurable, but easy-to-use backup solution that can take online backups of VMs and MySQL databases running multiple storage engines.

Since my colleagues are all researchers or programmers but there are no dedicated engineers for managing our system, I decided to write a set of command line scripts to accomplish the task instead of using an existing, highly-configurable but time-taking-to-learn backup solutions, like Amanda.

And what I have come up with now is a backup solution with following characteristics, let me introduce them.

• a central backup server able to take backup of other servers over SSH using public-key authentication
• no need to install backup agents into each server
• LVM snapshot-based online, incremental backups (capable of taking online backups of LVM-based VMs)
• taking online backups of MySQL databases running mulitple storage engines with sophisticated lock control
• no configuration files, only use crontab and shell-scripts

The solution consists of two tools, blockdiff (kazuho's blockdiff at master - GitHub), and cronlog script of kaztools (kazuho's kaztools at master - GitHub).

Blockdiff

Blockdiff is a set of scripts for taking block-based diffs of files or volumes on a local machine or on remote machines over the network using SSH.  The script below takes online backup of three LVM volumes from three servers.  In the form below, a full backup will be taken once a month, and incremetal backups will be taken during every month.

#! /bin/bash

export YEARMONTH=`date '+%Y%m'`

# backup a LVM volume (using snapshot) at /dev/pv/lv on srv00
blockdiff_backup /var/backup/srv00-pv-lv-$YEARMONTH ssh_lvm_dump --gzip \
  root@srv00 /dev/pv/lv \
  || exit $?

# backup another LVM volume on an another server
blockdiff_backup /var/backup/srv01-pv-lv-$YEARMONTH ssh_lvm_dump --gzip \
  root@srv01 /dev/pv/lv \
  || exit $?


# backup a MySQL database stored on volume /dev/pv/lv on server db00 
BLOCKSIZE=16384 \
  LVCREATE_PREFIX='mysqllock --host=db00 --user=root --password=XXXX' \
  blockdiff_backup /var/backup/db00-pv-lv-$YEARMONTH ssh_lvm_dump --gzip \
  root@db00 /dev/pv/lv \
  || exit $?

The backup command of the last volume uses mysqllock command included in blockdiff to keep "FLUSH TABLES WITH WRITE LOCK" running while taking a snapshot of the LVM volume on which the database files exist.  It is also possible to implement other kinds of locks so as not to issue the "FLUSH TABLES WITH WRITE LOCK" while long-running queries are in execution.  Since the flush statement blocks other queries until all of the already running queries complete, issuing the flush query when long-running queries exist will lead to the database not responding to other queries for a certain amount of time.

Crontab and the cronlog script

The backup script is invoked by cron via cronlog, a script that logs the output of the executed task, as well as controlling the output passed to cron so that an alert mail will be sent when the backup script fails.  It uses setlock command of daemontools for holding an exclusive lock while running the backup script (and to alert the administrator on when failing to acquire the lock).

MAILTO=admin@example.com
5 3 * * * cd /var/backup && exec setlock -nX /tmp/backup.lock cronlog -l /var/backup/backup.log -t -- ./backup.sh 2>&1

This is all that needs to be set up to backup LVM volumes including MySQL databases.  Output of the log will be like the following.

------------------------------------------------------------------------------
[Sat Jan  9 03:05:02 2010] backup-srv starting: ./backup.sh
[Sat Jan  9 03:05:02 2010] creating snapshot...
[Sat Jan  9 03:05:07 2010]   Logical volume "lvm_dump" created
[Sat Jan  9 03:05:07 2010] running: ssh_blockdiff_dump --gzip "root@srv00" "/dev/pv/lv"...
[Sat Jan  9 03:19:22 2010] removing snapshot /dev/pv/lvm_dump...
[Sat Jan  9 03:19:23 2010]   Logical volume "lvm_dump" successfully removed
[Sat Jan  9 03:19:23 2010] backup completed successfully
(snip)
[Sat Jan  9 03:35:56 2010] creating snapshot...
[Sat Jan  9 03:35:56 2010] issuing lock statement: FLUSH TABLES WITH READ LOCK
[Sat Jan  9 03:36:00 2010]   Logical volume "lvm_dump" created
[Sat Jan  9 03:36:00 2010] issuing unlock statement: UNLOCK TABLES
[Sat Jan  9 03:36:00 2010] running: bin/ssh_blockdiff_dump --gzip "root@db00" "/dev/pv/lv"...
[Sat Jan  9 04:18:44 2010] removing snapshot /dev/pv/lvm_dump...
[Sat Jan  9 04:18:46 2010]   Logical volume "lvm_dump" successfully removed
[Sat Jan  9 04:18:46 2010] backup completed successfully
[Sat Jan  9 04:18:46 2010] command exited with code:0

The files in the backup directory will be like below.  The .gz files contain the backup data, and .md5 files contain per-block checksums used for taking incremental or differential backups.

% ls -l db00-pv-lv-201001*
-rw-r--r-- 1 backup backup 50289166539 2010-01-01 05:35 db00-pv-lv-201001.1.gz
-rw-r--r-- 1 backup backup   131072004 2010-01-01 05:35 db00-pv-lv-201001.1.md5
-rw-r--r-- 1 backup backup 10914423057 2010-01-02 04:32 db00-pv-lv-201001.2.gz
-rw-r--r-- 1 backup backup   131072004 2010-01-02 04:32 db00-pv-lv-201001.2.md5
-rw-r--r-- 1 backup backup 13648250036 2010-01-03 04:33 db00-pv-lv-201001.3.gz
-rw-r--r-- 1 backup backup   131072004 2010-01-03 04:34 db00-pv-lv-201001.3.md5
(snip)
-rw-r--r-- 1 backup backup           3 2010-01-18 04:34 db00-pv-lv-201001.ver

For more information, please read the source code and the accompanying documentation.

Conclusion

As can be seen, this is a powerful backup solution that can be built up with minimum setup. It will work well if you work in a small number of experienced engineers, while it might not be suitable for large-scale deployments with many admins.  If you are interested, please give it a try.  I am looking forward to your ideas and / or suggestions.

PS. The blockdiff_merge command can be used to restore the backups.

Fast Enough

GPLである

MySQL community is so good

I know MySQL Internals

Easy to install

Stable

Scalable

MySQL have enough users.

まとめ

感想文です。タイトルはテンプレから。

たとえばうちの環境（普段 20-80 IOPS くらいの負荷がかかっている HDD) で、blockdiff (参照: Kazuho@Cybozu Labs: blockdiff を使ったお手軽ホットバックアップ環境の構築 (Linux, MySQL, etc.)) を実行すると、バックアップ速度は 10MB/sec. くらいになる。これはフルバックアップでも増分バックアップでも同じで、ボトルネックは HDD のシーケンシャルリード速度。他の I/O があるから、それぐらいの速度になってしまう *1。

換言とすると、100GB のボリュームをバックアップするのに約３時間かかる。必要な時間が３時間ならデイリーバックアップで運用できるけど、これが 1TB のボリュームとかになると、ウィークリーバックアップしか選択肢がなくなる。

ただ、

• ウィークリーバックアップだと頻度が低い。もっと高頻度でバックアップしたい
• 負荷が高い昼間は、LVM スナップショットがない状態で運用できるとうれしい

という２点もあるので、TB クラスのストレージだと LVM スナップショットベースのバックアップは苦しいのかなぁ、と思っている。

この問題に対応できるのはログ構造化ファイルシステムで、例えば zfs はスナップショットベースの増分バックアップ機能を備えている。ファイルシステムが、前回のバックアップ以降 HDD のどこに変更がかかったか覚えているので、インクリメンタルバックアップの際に発生する読み込み量はストレージのサイズではなく、変更の発生した量に依存することになる。従って、ストレージのサイズに関係なく、高頻度のバックアップが可能*2。

Linux のログ構造化ファイルシステムにどういうものがあるかは良く知らないけど、Nilfs には差分バックアップ機能はなさそうだった*3。

もうひとつの可能性は、LVM ベースで同様の、差分だけを HDD からバックアップするような仕組みを作れるか、という点。前回のバックアップ時のスナップショットを取っておいて、最新のスナップショットと差分を取るようにすれば、きっとできるはず。ただ、

• おそらく、スナップショット間の差分を読み出すためのドライバは自作しなければいけない
• 常にスナップショット機能がオンだと書き込みパフォーマンスが落ちるので、あまりうれしくない

という２点がある。なので、できれば、高パフォーマンスで安定した、増分バックアップの取れるログ構造化ファイルシステムが Linux にもほしいなぁ、なんて思ってる。

　結論から先に。cronlog を使えば、アプリケーションのテストコードと全く同じ形式で、監視用のスクリプトを書くことができます。プログラマが監視ツールの記法を覚える必要はありません。これは、プログラマが運用も行うケースでは特に有効な手法だと思います。

　先週公開した Kazuho@Cybozu Labs: crontab を使って効率的にサービス監視する方法 というエントリで、crontab と拙作の cronlog を用いてサービス監視を書く手法を紹介しました。しかし、挙げた例はいずれも ping や http のテストといった外形監視の手法です。RDBMS とウェブアプリケーションのみから構成されるサービスならそれだけで十分でしょう。

　しかし、外形監視だけでは、メッセージキューのような非同期処理の遅延を観測することはできません。また、http のログを監視して、エラーレスポンスや平均応答時間の監視も行うことが望ましいです。それらの処理をどう書くか。

　自分は、監視とは継続的なテストである、という観点から、キューの処理遅延等の監視を、アプリケーションのテストスートの一部として書いています。具体的には、以下のような感じ (一部改変)。テストはアプリケーションと設定情報を共有しているので、監視ソフトウェアに様々な設定値を入力する必要もありません。

use strict;
use warnings;

use Test::More;
use Pathtraq;

my $app = Pathtraq->new;

cmp_ok
    do {
        my $row = $app->dbh->selectrow_arrayref(
            'select XXXX', # Q4M 使ってない昔のキュー監視
        ) or die $app->dbh->errstr;
        $row->[0];
    },
    '<',
    1000,
    'delay of updater';

for my $tbl (qw(analyze_page set_page_info analyze_keyword)) {
    cmp_ok
        do {
            my $row = $app->dbh_queue->selectrow_arrayref(
                "select count(*) from $tbl",
            ) or die $app->dbh_queue->errstr;
            $row->[0];
        },
        '<',
        1000,
        "delay of $tbl",
}

done_testing;

　あとは、これらのテストコードを、crontab 上で cronlog を介してテストの実行ツール (perl なら prove) に食わせるだけ。

*/5 * * * * cd /var/webapp && exec setlock -nX /tmp/monitor.lock cronlog -- prove -v monitor.t/*.t 2>&1

　これで、監視対象項目 (＝テスト項目) になんらかの問題が見つかった場合には、以下のような感じのメールが届くようになります。

Subject: Cron <user@host> cd /var/webapp && exec setlock -nX /tmp/monitor.lock cronlog -- prove -v monitor.t/*.t 2>&1

host.example.com starting: prove -v monitor.t/queue.t

#   Failed test 'delay of analyze_page'
#   at monitor.t/queue.t line 23.
#     '1396'
#         <
#     '1000'
# Looks like you failed 1 test of 4.
monitor.t/queue.t ..
ok 1 - delay of updater
not ok 2 - delay of analyze_page
ok 3 - delay of set_page_info
ok 4 - delay of analyze_keyword
1..4
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/4 subtests

Test Summary Report
-------------------
monitor.t/queue.t (Wstat: 256 Tests: 4 Failed: 1)
 Failed test:  2
 Non-zero exit status: 1
Files=1, Tests=4,  0 wallclock secs ( 0.02 usr  0.00 sys +  0.40 cusr  0.08 csys =  0.50 CPU)
Result: FAIL
command exited with code:1

　perl に限らず、テストの実行ツールは一般に、成功した場合はゼロ、失敗した場合は非ゼロを返します (そうしないと make test && make install とか自動化できない)。この特性と cronlog の、非ゼロが返った場合だけ cron を経由してログをメールで送信する、という機能を組み合わせることで、テストコードが監視系に早変わりするのです。さらに外側で setlock -nX しているのは、５分間でテストが終了しなかった場合に、やはりエラーメールを送信するため。

　以上のように、cronlog を使えば、プログラマが使い慣れたテストスートの一部として監視系を書くことができます。パストラックでは更に、リバースプロキシのログ監視を touch_if コマンドとテストコードを連動する形で実施するようにしています。どうぞご覧ください。

　一昨日に開催された hbstudy #7 にバックアップの話を聞きに行ってきました。Amanda を中心にした話で、とても勉強になりました。が、設定がめんどくさそうだなぁ、とも。自分の需要にはあわない感じでした。

　勉強会が終わったあとで、自作のバックアップスクリプト blockdiff に関する話を何人かの方とさせていただいたのですが、思いのほか反応が良かったので、あらためて紹介したいと思います。

　blockdiff は、一言でいうと、パーティションやデータベースのデータファイルの差分バックアップツールです。rsnapshot に似ていますが、rsnapshot ではデータベースのホットバックアップ不可能です。逆に blockdiff はディレクトリ単位でのバックアップには対応していないかわり、ファイルシステムやデータベースを、一貫性を保ちつつ実質無停止で差分バックアップすることができます。

　blockdiff の具体的な特徴は以下のとおりです。

• 設定ファイルが不要

複雑な設定がありません。コマンドライン (あるいは crontab) で、適当な引数をつけてバックアップコマンドを呼び出すだけの簡単インターフェイスです。コマンドラインで動作を制御するため、(ホットバックアップを含む) 様々なバックアップロジックを組むことも可能です。

• バックアップを取るサーバにソフトウェアのインストールが不要

ssh 経由でリモートサーバのバックアップを取ることができます。サーバにバックアップソフトウェアをインストールする必要はありません (バックアップを取るために必要なプログラムは自動的に送り込まれます) ^注1

• フルバックアップと増分バックアップに対応

フルバックアップと増分バックアップに対応しています。また、下位レイヤのスクリプト (blockdiff_dump) を直接実行すれば、差分バックアップも可能です。

• ファイル単位、あるいは LVM スナップショットを使ったバックアップが可能

ファイル単位のバックアップと、LVM スナップショットを使ったホットバックアップに対応しています。

• MySQL のホットバックアップが可能

同梱の mysqllock コマンドと組み合わせることで、LVM スナップショットを使った MySQL データベースのホットバックアップが可能です。PostgreSQL については確認はしていませんが、ロックコマンドを使わなくてもバックアップが取れるんじゃないかと思います。

• LVM ベースの VM のホットバックアップが可能

LVM ベースの仮想ディスクを用いた Xen の DomU のホットバックアップが可能です^注2。私は使っていないので試していませんが、KVM の仮想マシンについても同等のことが可能だと思われます。LVM ベースではない VM についても、スナップショット機構によってはホットバックアップが可能だと思われます。

　blockdiff を使った LVM ボリュームのバックアップ方法については Kazuho@Cybozu Labs: リモートからXenのDomUとかLVMやファイルを差分バックアップするスクリプトを書いた で触れたので、ここでは MySQL データベースをホットバックアップする場合の設定を紹介したいと思います。前提として、MySQL のデータが LVM ボリューム上に保存されている必要があります。

　バックアップスクリプトは、以下のような感じになります。

#! /bin/bash

export BLOCKSIZE=16834
export LVCREATE_PREFIX="mysqllock --host=db-host --user=root --password=XXX"
export YEARMONTH=`date '+%Y%m'`

blockdiff_backup /var/backup/db-backup-$YEARMONTH bin/ssh_lvm_dump --gzip \
  root@db-host /dev/mapper/logical_volume_of_mysql

このバックアップスクリプトは以下のことを行っています。

• バックアップのブロックサイズを InnoDB のブロックサイズである 16KB に設定
• スナップショットを取る瞬間に mysqllock コマンドを使って FLUSH TABLES WITH READ LOCK を使うことで、MyISAM テーブル等の一貫性のあるバックアップを実現
• １ヶ月毎にフルバックアップ。それ以内は増分バックアップ

　バックアップスクリプトを実行すると、最初に db-backup-YYYYMM.1.gz, db-backup-YYYYMM.1.md5, db_backup-YYYYMM.ver という３つのファイルが作成されます。YYYYMM.1.gz がバックアップデータ、YYYYMM1.md5 がブロック単位のチェックサム情報です。次に実行すると YYYYMM.2.* が、その次は YYYYMM.3.* が、という形で増分バックアップが増えていきます。最新のバックアップの番号は .ver ファイルが記憶しているので、バックアップが途中で失敗しても問題ありません。次回バックアップ時に壊れたバックアップファイルが上書きされます。

% ls -l db-backup-201001*
-rw-r--r-- 1 backup backup 50289166539 2010-01-01 05:35 db-backup-201001.1.gz
-rw-r--r-- 1 backup backup   131072004 2010-01-01 05:35 db-backup-201001.1.md5
-rw-r--r-- 1 backup backup 10914423057 2010-01-02 04:32 db-backup-201001.2.gz
-rw-r--r-- 1 backup backup   131072004 2010-01-02 04:32 db-backup-201001.2.md5
-rw-r--r-- 1 backup backup 13648250036 2010-01-03 04:33 db-backup-201001.3.gz
-rw-r--r-- 1 backup backup   131072004 2010-01-03 04:34 db-backup-201001.3.md5
...
-rw-r--r-- 1 backup backup           3 2010-01-18 04:34 db-backup-201001.ver

　バックアップスクリプトが正しく動作することを確認したら、crontab を設定して毎日バックアップを取るようにします。

0 4 * * * setlock -nX /var/backup/backup.lock cronlog -l /var/backup/backup.log -t -- /var/backup/backup.sh 2>&1

　ここでは、daemontools の setlock コマンドを使って万が一の重複起動を抑止しています。また、kaztools の cronlog コマンドを使うことで、バックアップの進捗をログに保存しつつ、バックアップが失敗した場合は cron 経由でアラートメールが送信されるようになっています。

　ちなみに、バックアップのログ (backup.log) は、毎日次のような感じで追記されていきます。データベースの停止期間 (アプリケーションからのクエリがロックされる期間) は 03:35:56 から 03:36:00 までの４秒間であり、実質無停止でのバックアップができていることがわかります。

------------------------------------------------------------------------------
[Sat Jan  9 03:05:02 2010] backup-srv starting: /var/backup/backup.sh
[Sat Jan  9 03:05:02 2010] creating snapshot...
[Sat Jan  9 03:05:07 2010]   Logical volume "lvm_dump" created
[Sat Jan  9 03:05:07 2010] running: bin/ssh_blockdiff_dump --gzip "root@db-host" "/dev/db/lvm_dump"...
[Sat Jan  9 03:19:22 2010] removing snapshot /dev/db/lvm_dump...
[Sat Jan  9 03:19:23 2010]   Logical volume "lvm_dump" successfully removed
[Sat Jan  9 03:19:23 2010] backup completed successfully
[Sat Jan  9 03:19:23 2010] creating snapshot...
[Sat Jan  9 03:35:56 2010] issuing lock statement: FLUSH TABLES WITH READ LOCK
[Sat Jan  9 03:36:00 2010]   Logical volume "lvm_dump" created
[Sat Jan  9 03:36:00 2010] issuing unlock statement: UNLOCK TABLES
[Sat Jan  9 03:36:00 2010] running: bin/ssh_blockdiff_dump --gzip "root@db-host" "/dev/x25m.1/lvm_dump"...
[Sat Jan  9 04:18:44 2010] removing snapshot /dev/x25m.1/lvm_dump...
[Sat Jan  9 04:18:46 2010]   Logical volume "lvm_dump" successfully removed
[Sat Jan  9 04:18:46 2010] backup completed successfully
[Sat Jan  9 04:18:46 2010] command exited with code:0

　このように、blockdiff を使うことで VM 単位のバックアップだけでなく、データベースのホットバックアップも簡単に取ることができます。パストラックでは、これらバックアップスクリプトに処理を追加し、バックアップ中は統計処理を抑止するといったことも行っています。

　blockdiff や kaztools は、いずれも私の github リポジトリ (github.com/kazuho) からダウンロードして perl Makefile.PL && make all test && make install でインストール可能です。あるいは nopan がインストールされていれば、nopan http://github.com/kazuho/blockdiff http://github.com/kazuho/kaztools と１コマンドでインストールすることができます。いずれもパストラックで実際に運用しているツール群ですが、興味のある方は (at your own risk で) お試しあれ。

注1: バックアップを取るサーバに Perl 5.8 以降がインストールされている必要があります。また、公開鍵認証を用いて SSH ログインできる必要があります
注2: XenServer のスナップショット機能とは併用できません

SQLインジェクションとは？

$sql = "SELECT user, pass FROM users
WHERE user = '" + $user + "' AND pass = '" + $password + "'"

攻撃例

SELECT user, pass FROM users WHERE user = 'nippondanji' AND pass = 'fundoshi'

• クォーテーションを文字列の中に混入させる。これにより、攻撃者は新たなSQLの文法を注入＝インジェクトすることが可能になる。
• SQL文を途中でコメントアウトしてしまう。これにより、文法的に正しいSQL文を組み立てやすくなる。
• OR 1=1など恒常的に成り立つ条件を利用する。これにより、WHERE句の条件を無視してしまう。
• UNIONを用いて任意の情報を入手する。
• INFORMATION_SCHEMAへアクセスしてどのようなテーブルが存在するかといった情報を入手する。
• セミコロンを使って複数のSQL文を記述し、任意のSQL文を実行する。これにより、不正にデータを改竄してしまう。

SELECT user, pass FROM users WHERE user = 'nippondanji'#' AND pass = 'hoge'

$sql = "SELECT user, first_name, last_name, prof FROM users
WHERE MATCH(first_name, last_name) AGAINST ('" + $search + "')"

SELECT user, first_name, last_name, prof FROM users WHERE MATCH(first_name, last_name) AGAINST('Mikiya')

SELECT user, firt_name, last_name, prof FROM users WHERE MATCH(first_name, last_name) AGAINST('') LIMIT 0 UNION SELECT user, pass, 1, 1 FROM users ORDER BY RAND() LIMIT 10 #')

対策編

まとめと宣伝

Ruby から MySQL を使うための pure Ruby ライブラリ Ruby/MySQL 2.9 を公開しました。まだベータ版です。 http://github.com/tmtm/ruby-mysql/tree/2.9

前の Ruby/MySQL は 0.2.6 だったのですが、今回 2.9 とした理由は:

• Cライブラリ版の MySQL/Ruby 2.8.x の後継。
• 次は 3.0 にしたいという希望。

…という意味があります。

gem は gemcutter にあります。http://gemcutter.org/gems/ruby-mysql/versions/2.9.0

gemcutter が設定されて入れば次のコマンドでインストールできます。

# gem install ruby-mysql -v 2.9

対応する Ruby バージョンは 1.8.7 / 1.9.1 / 1.9.2、MySQL バージョンは 5.1.x です。

MySQL/Ruby 2.8.x との互換

以前のバージョンと異なり、MySQL/Ruby 2.8.x とほぼ互換があります。ただし以下の非互換があります。

Ruby 1.8.x で使用する場合、Mysql#escape_string は、マルチバイト文字の一部として特殊記号を含むマルチバイト文字セットに対して安全ではありません。シフトJIS(sjis, cp932)等は2バイト目に「\」を含むためこの制限にあてはまります。プログラム側で独自にエスケープ処理を行うか、ストアドプロシジャを使用してください。そうでないと SQL インジェクションの危険性があります。EUC-JP や UTF-8 は問題ありません。

いくつかのメソッドがありません: Mysql#debug, Mysql#change_user, Mysql#create_db, Mysql#drop_db, Mysql#dump_debug_info, Mysql#ssl_set, Mysql#reconnect

Mysql#options でサポートしているオプションは次のものだけです: Mysql::INIT_COMMAND, Mysql::OPT_CONNECT_TIMEOUT, Mysql::OPT_LOCAL_INFILE, Mysql::OPT_READ_TIMEOUT, Mysql::OPT_WRITE_TIMEOUT, Mysql::SET_CHARSET_NAME. これら以外を指定すると "option not implementted" という warning が標準エラー出力に出力されます。

Mysql#use_result は Mysql#store_result と同じです。つまりサーバーから一気に結果セットを読み込みます。

MySQL/Ruby 2.8.x からの改良点

Ruby 1.9.x の M17N に対応しています。mysqld へのクエリ文字列やプリペアドステートメントで与える値は mysqld との接続の文字コードに自動的に変換されます。mysqld からの結果文字列は接続文字コードとして取り出されます。

Mysql::Result, Mysql::Stmt が Enumerable を include しています。

ブロックなしの Mysql::Result#each, each_hash Mysql::Stmt#each, each_hash が Enumerator を返します。

Mysql#charset= で接続 charset を指定できます。

Mysql::Error だけでなく、エラー種別ごとにエラークラスが用意されてます。たとえば、構文エラーの場合は Mysql::ParseError など。これらのエラーは Mysql::Error の継承クラスです。

他に pure Ruby 版であることのメリットとして、Ruby のマルチスレッドが同時に動くというのがあります。あるスレッドで時間のかかるクエリを実行中に他のスレッドが動くことができます。

機能的な改良点ではありませんが、ライセンスは Ruby ライセンスです。Cライブラリ版の MySQL/Ruby は libmysqlclient をリンクするため、それを使用する Ruby スクリプトも GPL にするか、それが嫌なら MySQL の商用ライセンスを購入する必要がありました。Ruby/MySQL は libmysqlclient をリンクしないため、その制限はありません。

Ruby 1.9.x M17N 対応

MySQL はデータベース、テーブル、カラム毎にそれぞれ文字セットを持っています。また、サーバーとクライアントの間の接続に文字セットを持っています。接続とカラムとの間の文字セットは MySQL のサーバー側で自動的に変換されます。

Ruby/MySQL では MySQL 接続の文字セットを Mysql#charset= で指定できます。または、Mysql#connect 前に Mysql#options(Mysql::SET_CHARSET_NAME) で設定します。

Ruby 1.9.x では文字列はそれぞれエンコーディング(文字セット)を持っています。Ruby/MySQL で Ruby プログラムから MySQL サーバーに渡す文字列（クエリ文字列や、プリペアドステートメントのパラメータ）は自動的に接続に応じた文字セットに変換されます。

MySQL サーバーから返される文字列の Ruby のエンコーディングは接続の文字セットに対応したものになります。ただし、プリペアドステートメントでは、BINARY型とBIT型のデータは ASCII-8BIT エンコーディングで返ります。

例:

# -*- coding:utf-8 -*-
require 'mysql'
my = Mysql.connect(nil, 'username', 'password')
my.charset = 'cp932'          # 接続の文字セットは CP932
query = 'select "あいう"'     # UTF-8 のクエリ文字列
query.encoding                # => #<Encoding:UTF-8>
col, = my.query(query).fetch  # 取り出した値は接続と同じく CP932
col.encoding                  # => #<Encoding:Windows-31J>
col                           # => CP932 で "あいう"

I_Sの最適化

INFORMATION_SCHEMAに対してクエリを行うSELECTに対してEXPLAINを実行すると、Extraフィールドに以下のメッセージが表示されます。

• Skip_open_table ... テーブルをまったくOpenする必要がない場合（データベースディレクトリのエントリを見るだけでクエリが解決できる場合）に表示されます。（クエリ例：select table_name from tables;）
• Open_frm_only... .frmファイル（テーブル定義ファイル）をOpenするだけでクエリを解決できる場合に表示されます。（クエリ例：select table_name, engine from tables;）
• Open_full_table... .frmファイルだけでなく実際にテーブルをOpenする（MyISAMの場合は.MYDや.MYIファイルを開く）必要がある場合に表示されます。（クエリ例：select table_name, data_free from tables;）
• Scanned 0 databases... データベースのスキャンをする必要がない場合に表示されます。（クエリ例：select table_name from tables where table_schema='test' and table_name='t1';）
• Scanned 1 database... データベースを一つだけスキャンする必要がある場合に表示されます。（クエリ例：select table_name from tables where table_schema='test';）
• Scanned all databases... 全てのデータベースをスキャンする必要がある場合に表示されます。（クエリ例：select table_name from tables;）

上記のうち、Skip_open_table、Open_frm_only、Open_full_tableのどれが表示されるかは、INFORMATION_SCHEMA内のテーブルのどのカラムへアクセスするかによって決まっています。（上記のクエリ例でSELECTされているカラムを見て下さい。）Scanned X databasesは、どれだけデータベースやテーブルが具体的に指定されているかで決まります。テーブル名がより具体的に指定されているほうがクエリの効率が良いということになります。