Q4Mを使うときにやってはいけない一つのこと

ある日Q4Mを利用したシステムを運用していたところ、プログラマの方から

「Q4Mのテーブルが壊れたっぽいのだけども。。。」

との報告があり、状況を聞いてみた。
どうも、Queueに突っ込んだけども処理したくないデータがあったという理由で一部の行をDELETEしたとのこと。

で、早速DBを調べてみると、全部queue_waitで取り出したにも関わらず行数が0にならなかったり、
発行しているqueue_endが実行されずにずっとプロセスが残っていたりして大変カオスな状態になっていた。
(insertも止まっていた)

その場ではMySQLを強制的に再起動して、tableやschemaをdropして再作成してもらうことでことなきを得た。
が、今日帰ってきてQ4Mのページを見て謎が解決。
Q4Mの「Limitations and Known Issues」に

removal of multiple rows from a single DELETE statement is not atomic
(複数行に対する一つのDELETE文による削除はアトミックじゃありません)

と書いてあるじゃありませんか。
というわけで、これからQ4Mを使いたいという方でもし

「Queueに入れたけどやっぱり処理させたくないものは取りやめる」

というような要件がある場合

1. 1行1DELETE文で削除する。
2. もしくはignoreテーブルとかを作ってQueueを特定する情報を突っ込んでおいて、dequeueした時にignoreと照合する。
3. QUEUEストレージエンジンを利用するschemaと、それ以外のschemaは分ける。
   (あるいは別にMySQL5.0を用意してそっちに入れとく)
   

などの対策が必要になるかなと思います。

なので、Q4Mを使うときには

複数行に対して1つのDELETE文による削除はやってはいけない

です。
以上、ご参考まで〜

gzipの効用

最近面倒を見ているサーバのログ出力が1日あたり2.5GB程度とサイズが大きくなり、
放置しておくとすぐにHDDを圧迫するため、日次で前日分のログをgzip圧縮することにした。

ここでふと、
「そういやgzip使う機会はそれなりにあるけど、どのくらいの容量をどのくらいの時間で処理できるんだろ」
という疑問が沸いたので測ってみた。
(今回使ったマシンのCPUはP4 2.8GHz)

$ time gzip -9 YYYYMMDD.log
real 2m27.162s
user 1m59.045s
sys 0m8.167s

圧縮前が2,271,220,673バイト(2.2GB)で、圧縮後が215,331,701バイト(210MB)になった。
ただの文字データ2.2GBなら2分半で10分の1程度に圧縮可能という結論が出た。

以上。
作業時間の目安なりにしてください〜

過去のLT動画

・第11回 「Aから考えてみる...」

• Aから始まるテーマだったので、無理矢理こじつけてアンペアにしてみました。
• でも注意してないとおもわぬところで足をすくわれるのも事実。
  

・第10回 「パソコン1台で始める俺俺データセンター」

• 仮想マシンと1台のPCでどこまで面白い環境が作れるのかということにチャレンジしてみた内容。
  

GenesisLightningTalksの動画がUPされました。

先日挙げたエントリの内容の動画です。