2013年12月26日木曜日

コミケ85にLinux本を出します(3日目西せ18a)

コミケ85に「低級はっかーズ」として出展します。3日目(火曜日)西せ18aです。

今回の新刊は "Linux Kernel Updates 2013.12" です。価格は300円です。内容は

  • What's New in Linux 3.11?
  • What's New in Linux 3.12?
  • TCP/IPチューニング特集
です。下にプレビューを掲載します!

TCP/IPチューニング特集は主にsysctlのパラメータを解説しています。自称日本語で一番詳しい解説になっています!

表紙は毎度おなじみきのとなおとさんに描いていただきました。

前回までの既刊2冊も持っていきます。こちらも一冊300円です。よろしくお願いします!

2013年12月16日月曜日

MySQLにMHA を導入してハマったところ

この記事はMySQL Casual Advent Calendar 2013の16日目の記事です。

MySQLのマスタ冗長化のいち手段としてMHAというものがあります。マスタが落ちた時に自動的にスレーブに切り替えてくれます。詳しいアーキテクチャは公式ページやそこから辿れるスライドに詳しいのでそちらを参照していただくとして、ここではカジュアルに導入の時に詰まった店を挙げます。

幾つかはバグらしきものも含まれているので、後ほど公式にレポートしようと思います。

MySQLのパスワードに記号が入っているとうまくいかない

MySQLのパスワードに一部の記号が入っていると認証が通りませんでした。コードを見るとエスケープして戻して、MySQL向けのエスケープしたりシェル向けのエスケープをしたりと入り組んでいたので、どこかで対応が崩れているのかと思いましたが他にもこの種の問題はありそうなのでとりあえず記号を使わないパスワードに変更して乗り切りました。

shebangがenv perlになっている

MHAのスクリプトはすべてshebangが "#!/usr/bin/env perl" になっています。make installしても変わりません。ところで、#!/usr/bin/envはイマイチという噂もありますが、これperlbrewと相性が極端に悪くって、システムperlのパッケージを入れてもperlbrewのほうが実行されてライブラリが見つからなかったり逆にperlbrewに入れたのにシステムperlのほうが実行されたりして危ないのです。今回はすべてperlbrewの方に統一することにしました。

たぶんmake installする際に書き換えるのが正解だと思います。

relay_log_info=TABLEだとうまく動かない

MySQL 5.6の新機能でmaster-infoやrelay-log-infoがテーブルに入れれるようになりましたが、これがMHAではうまく動きませんでした。コードを見ると一見サポートしてそうに見えるのですが、マスタはrelay-log-infoが無いのにrelay-log-infoをSELECTして、見つからないのでエラーで止まります。ファイルの場合はちゃんと動くのですけどね。というわけで今回はファイルで使うことにしました。

パスワードを平文で書かないといけない

これはMySQLに常に付きまとう問題ですしもはや仕様なのですが、例えばpurge_relay_logsを動かそうとするとオプション引数にパスワードを平分で書く必要があります。crontabをちゃんと一定のユーザーに設定すれば見られる危険は少ないですが、気持ち悪いですね。

SSHのオプションがおかしい

failoverするときに使うサンプルスクリプトが付属していますが、これから参照されているSSHのオプション定数がちょっとおかしいです。

our $SSH_OPT_CHECK =
"-o StrictHostKeyChecking=no -o PasswordAuthentication=no -o BatchMode=yes -o ConnectTimeout=VAR_CONNECT_TIMEOUT";

VAR_CONNECT_TIMEOUT って謎の定数らしきものが使われていて、sshがinvalid time valueと言って死にます。ちょっとハマりました。

新しいレプリカセットを作って切り替えするときには同時に入らない

MHAはthree tier以上のレプリケーションも限定的にサポートしているのですが、これは一番上のマスタを登録する必要があります。新しいマスタスレーブのペアを既存のマスタにぶら下げて切り替えるという時に、既存のマスタへ新しいマスタからレプリケーションが走っていると、MHAがその既存のマスタに飛んでいって「Master %s:%d from which slave %s replicates is not defined in the configuration file!」というエラーメッセージとともに死にます。ので、新しいセットにMHAを入れてから切り替えようということはできません。

切り替えてからMHAを起動すればいいだけなのですが、どうしようか少し悩みました。

何回もテストすると失敗する

MHAは最近failoverした時刻を .failover.complete というファイルで管理していて、最近failoverしたばっかりでもう一度failoverしようとすると、「Current time is too early to do failover again.」というエラーで止まります。毎回手動でファイルを削除する必要があって少し面倒でした。

おわりに

問題点ばかり列挙しましたが、MHAは実績のある限られたマスタ冗長化ツールです。一度導入してしまえば安眠できると思います。これからパッチやバグレポートを書きます...

明日はYuya Takeyamaさんです。

2013年12月6日金曜日

EC2でプロセッサパワーがほしい時に使うインスタンスはcc2.8xlarge

AWS EC2に新しいc3世代のインスタンスタイプが追加されたのですが、値段あたりの処理性能がいまいちわからなかったのでHeavy Reserved Instanceを1年使う計算で比べてみました。比較対象は c1.xlarge, c3.xlarge, c3.2xlarge, c3.4xlarge, c3.8xlarge, cc2.8xlargeです。3年でもあんまり変わらないと思います。リージョンはバージニアです。

というわけで値段あたりのCPUパワーが一番いいのはcc2.8xlargeでした。c3世代はSSD搭載なので、SSDほしい時は選択肢が変わってくると思いますが、単純にCPUだけほしい、という時はcc2.8xlargeが良さそうです。c3世代より2割ぐらい安い計算になりました。

備忘録的な記事で雑なまとめですがこのへんで。