DNS ラウンドロビンが効かない

Linux上で動くJavaアプリがDNS ラウンドロビンで負荷分散しているホストの一つにしかアクセスしていなかった原因を調査したのでメモ

結論から言うと、IPv6はアプリ側でラウンドロビンを実装しないとダメ(RFC3484 role 9)

しかも、Linux(Windows XP/Vistaも？)IPv6スタックが有効だと通信上IPv4しか使っていなくてもDNS周りがIPv6仕様になるのでアプリ側で実装する必要がある

Windows Vistaサポート情報
http://support.microsoft.com/default.aspx?scid=kb;EN-US;968920


一部では有名らしいけど、知らなかった･･･orz

っというわけで、IPv6を使えないように設定変更して無事解決
(CentOSなので、こちらを参照)
http://wiki.centos.org/FAQ/CentOS5#head-47912ebdae3b5ac10ff76053ef057c366b421dc4


詳細については、ここら辺が、よくまとまっている気がする
http://people.redhat.com/drepper/linux-rfc3484.html

twitter on miranda

Twitterを始めたけど、わざわざブラウザでつぶやくのがメンドイので、メッセンジャーにプラグインを追加してみた

というわけで、Mirandaからtwitterに書き込むためのプラグインがコレ
http://code.google.com/p/miranda-twitter/

今のところ不具合もなく、日本語も問題なく使えるけど、まだ枯れてないようなので要注意なプラグインらしい

一応、ｔｗｉｔｔｅｒも表示されるようにしてみた

MySQLバックアップ

MySQLの物理バックアップからの復旧で、トラブルがあったのでメモ

バックアップをレプリケーションのスレーブ(スタンバイ)側で物理バックアップを日次でとっていた。
物理バックアップなので、普段はそのままデータディレクトリに配置してMySQLを起動させれば、レプリケーションも再開されてサービス再開できるはずなのにレプリケーションを開始しようとするとエラーが発生してレプリケーションが動かなかった。

原因は、"LOAD DATA INFILE"でデータをロードする途中でレプリケーションを止めて物理バックアップを取得していて、"tmpdir"や"slave-load-tmpdir"で指定したディレクトリは、物理バックアップ対象からもれていた為、読み込み対象のファイルが無かったから、エラーが起きていた。

復旧方法は、mysqlbinlogで内容を確認してから、レプリケーションの開始位置を少し前に戻して、"LOAD DATA INFILE"を初めからやり直した。

二度とおきないようにmy.cnfにも、"slave-load-tmpdir"を指定して、バックアップ対象ディレクトリに一時データを作成するように変更した。

MySQLのレプリケーションねた2つ

MySQLのレプリケーション関連で、最近起きたトラブルねたを2つ

• レプリケーションの遅延時間が時々異常に大きな値を示す場合がある。
• MySQLのバージョンアップしたらレプリケーションが動かなくなった。

一つ目のレプリケーションの遅延時間は、Nagiosの監視(5分おき)から単発で大きすぎる遅延(5分以上)を検出していた。検出されてからコンソールで状態を確認(SHOW SLAVE STATUS\G)しても"Seconds_Behind_Master"は0としか表示されないことが続いていた。

原因は、マスタとスレーブがNTPの時刻合わせで正しい時間に設定される前にレプリケーションを初めてしまったため。レプリケーションの開始時にスレーブは、マスタとスレーブの時刻のズレを記憶して遅延時間を算出している。NTPの設定で、マスタとスレーブの時刻のズレが有る状態から無い状態へ変化していても遅延時間の算出する時には、時刻のズレを考慮しているので、異常に大きな遅延時間が出ていた。ちなみに、まったく遅延をしていない(＝最新のバイナリログが実行済み)の場合は、"Seconds_Behind_Master"は必ず0と表示されるので、遅延が発生しない限り異常な値を示さない。

解決方法は、簡単でレプリケーションを止めてからまた始めるだけ。そうすることで、もう一度マスタとスレーブの時刻のズレが正しい値になるので、異常な遅延時間が出なくなる。


2つ目の"MySQLのバージョンアップしたらレプリケーションが動かなくなった"のは、マスタ側のMySQLを5.0.51aから5.0.77へバージョンアップしたらレプリケーションが止まった。(スレーブ側は5.0.51a)

原因は"my.cnf"に記述するバイナリログファイル名の仕様変更(?)だった。バイナリログを出力するためにmy.cnfに"bin-log="とだけ記述して、ファイル名を指定していないと引っかかる。

ファイル名を指定しないとバイナリログインデックスファイル([バイナリログファイル名].index)に記述されるバイナリログのファイルのパスが、バージョンアップをしたら相対パスから絶対パスに変わった。バイナリログファイル名を記述してある場合は、どちらの場合も相対パスのままだった。

対策としては、必ずバイナリログファイル名を記述するとバージョンアップをしても問題無く使える。(指定していなければ、今のバイナリログファイル名と同じファイル名をmy.cnfに記述しておく)

Cactiの表示がおかしい

CentOS 4が入っているサーバーで、CactiのCPU表示がおかしくなっていたのでメモ

snmpのバグでInteger Maxになった際の挙動が変だった。

UCD-SNMP-MIB::ssCpuRawIdle.0 = Counter32: 4294967295

RedHatのＢｕｇｚｉllａにもあがっていたので、yumでアップデートして対応完了！

==Bug 223775 - ssRawCpu* stays on 2^32-1 forever ==
https://bugzilla.redhat.com/show_bug.cgi?id=223775

==net-snmp bug fix update==
http://rhn.redhat.com/errata/RHBA-2007-0738.html

Jrubyが動かん

Java 6で、JRuby 1.1.7のバイナリパッケージを展開してPATHを通しても動かない。
ちゃんと、JAVA_HOMEの環境変数を指定してもエラーが出て動かない

Exception in thread "main" java.lang.NoClassDefFoundError: org/jruby/Main

ソースも添付されていたから、JRubyそのものをビルドしなおしたら動いた。

connect: Network is unreachable

default gateway の設定ミスorz

同じネットワークセグメントからはアクセスできて、外のネットワークにつなげない場合にちゃんとルーティングが正しいかどうか要確認