ただつらつらと日記が書かれていくようです。

投稿者: 管理人 (40ページ目 (41ページ中))

「unauthenticated user」が溢れた。

なんかサーバが重いなぁと思って、show processlistで見てみると、MySQLが「unauthenticated user」で溢れていた。netstatで見てみても、MySQLのポートがこれまでにないくらいESTABLISHEDであふれかえっていて、結局、「unauthenticated user」からのアクセスが、コネクションを使い切って、…あー(涙)という状況になった。

とりあえず、何らかの対処をしないと困るので、とりあえず、MySQLを再起動してみたが、解決せず。さらに、Webサーバも再起動してみたし、OSも再起動してみたが、やっぱり解決せず。で、「unauthenticated user」でGoogle先生に聞いてみたところ、MySQLがアクセスしてくるクライアントのIPアドレスのDNSの逆引きをやっているらしく、逆引きができないときに「unauthenticated user」が溢れるという事象が起こるらしかった。

そこで、MySQLが動いているマシンの/etc/hostsファイルを編集して、アクセスしてくるマシンの名前解決ができるようにしたら、「unauthenticated user」にお引き取りいただくことに成功して、再び平和が訪れた。

しかし。「unauthenticated user」が溢れることになるトリガーがよくわからない。特にMySQL周辺の設定を変更したわけでもないのだが、突然、溢れ出したように見えた。

あと、MySQLがなんでDNSの逆引きをやってるかがわからないので調べてみた。MySQLの権限テーブルでアクセス元を制限できるけど、その制限の指定にホスト名が使える(…そういえば、localhostとか使ってるなぁ…)背景には、MySQLがアクセスしてきてるクライアントのIPを逆引きしているということがあるらしい。なるほどなぁ…。

fsck…。

とあるサーバが応答しなくなったので、某所のデータセンターに行ってみた。すると、サーバのコンソールは一連のブートシーケンスらしきものが表示されていて、ファイルシステムがおかしいぞー的なエラーメッセージが出力された状態で止まっていた。

止まっていたサーバは、かなり前に構築されたサーバであるため、カーネルが古いせいか、kernel panicを起こすことがある。おそらくは、kernel panicして自動的に再起動して、再起動時のfsckで、修復が必要なエラーが検出されて止まっていたといった感じだろうか(…よくわからん…)

そんなわけで、、、冷や汗をかきながら、fsckをやってみた。といっても、fsckからinodeを見せられて、「修復しますか?」って聞かれたところで、「y」を押す以外のことはできるはずもなく、ただ、ひたすら「y」を連射。すると、リペアが完了した、みたいなメッセージが出力されて再起動。

…起動した。

たらいうどん@長田 in 香の香

お仕事日記と言いながら、年末年始は結局何もしなかったので(汗)とりあえず、日記を。

年末年始は実家に帰省した。せっかく、香川に帰ったんだから…ということで、釜揚げうどんを食べに「長田 in 香の香」に行ってきた。

駐車場は、讃岐うどんを食べに来ている県外ナンバーの車であふれかえっていて、行列は店の外までつながっていた。まぁ、香川県の人は、こんなに並んでるうどん屋を見かけると撤退しそうではあるが、久しぶりなので、意地と根性で並んでみた。

f:id:y_fudi:20090102130948j:image

で、家族と一緒に行ったので、「たらいうどん」にしてみた。ただ、たらいうどん(大)だと、12玉入っているらしく、さすがにそれは多いだろうということになったが、たらいうどん(小)だと、6玉。ちょっと少ない。というわけで、たらいうどん(小)と釜揚げうどん(大)を頼んでみたら、たらいうどんに一緒に入れてくれるとのこと。

f:id:y_fudi:20090102133244j:image

やっぱり、いりこの効いたつけダシはさいこー!あっという間にたらいは空になってしまった。で、勢い余って、最後にダシだけいただいてしまったが、このダシをアテに日本酒が飲めてしまうんじゃないかとちょっと思った。

drbdのスプリットブレイン訓練

DRBDを使っていて、うっかりスプリットブレインになっちゃった時に、リカバリー方法を間違えるとややこしいことになるような気がした(どっちをマスターにするかを間違えると、スレーブでマスターを上書きしてデータのロストとか起きたりしそう)ので、ちょっと試しにスプリットブレイン状態を作ってリカバリーしてみた。

使ったDRBDは8.3.0。インターネットを探してみると、DRBDが動いている状態でネットワークを引っこ抜くとスプリットブレインが発生すると書いてあるサイトもあったので、試しにL2スイッチの電源を落としてみた。そしたら、お互いに「WFConnection」(接続待ち)状態に遷移した。一方、マスター側は「Primary」状態なので、そのままマウントして、アプリケーションからいじってたりしたけれど影響はなかったみたいだ。で、ネットワークを再接続すれば、切断前のPrimary/Secondaryの関係性を維持したまま、「Primary」から「Secondary」への同期が始まった。で、同期が完了すると、「Connection」状態に戻った。

結局、ネットワークがダウンするだけでは、スプリットブレインは発生しないようだ。とりあえず、運用中にLANケーブルが引っこ抜ける的な障害が起こった場合は、LANケーブルを刺し直せば自動で対応してくれそうだ。

次に、意図的にスプリットブレインを作ることにした。L2スイッチを落とすところまでは同じだが、ネットワークが切れていることをいいことに、スレーブ側のマシンを「Primary」状態にしてみた。その後、L2スイッチの電源を入れる。これによって、お互いが「Primary」になっていることを検出するので、スプリットブレインとして、お互いが「StandAlone」に落ちる。ただ、もともと「Primary」になっていたマスター側は、StandAloneになっても「Primary」なので、マウントは可能っぽい。ただ、同期が取られないだけのようだ。dmesgでログを確認すると、以下のようなログが出力されていた。

drbd0: drbd_sync_handshake:

drbd0: self 6ABCC0B39EEBC9D5:03B0E55FA3B63131:38D5407DCCBC17FE:1C2D0C92A346572F

drbd0: peer 705B58F4947E0C9C:03B0E55FA3B63130:38D5407DCCBC17FE:1C2D0C92A346572F

drbd0: uuid_compare()=100 by rule 9

drbd0: Split-Brain detected, manually solved. Sync from this node

さて、両方のノードが「StandAlone」になったときにどう復旧するか。「drbdadm」にはいくつもコマンドオプションがあるので、いろいろ試してみたが、同期を取ってくれない。。。

そんなわけで、DRBDのマニュアルを探してみたら、「Manual split brain recovery」って項目があった。

DRBD detects split brain at the time connectivity becomes available again and the peer nodes exchange the initial DRBD protocol handshake. If DRBD detects that both nodes are (or were at some point, while disconnected) in the primary role, it immediately tears down the replication connection.

DRBDは、コネクティビティが復活した時や、同期相手とDRBD Protocolによるハンドシェイクを行う時にスプリットブレインを検出する。DRBDが両方のノードがPrimary(role)になっている(もしくは、接続が切れている、どこかの時点でPrimaryになっていた)場合、レプリケーションの接続をすぐに切断する。

After split brain has been detected, one node will always have the resource in a StandAlone connection state. The other might either also be in the StandAlone state (if both nodes detected the split brain simultaneously), or in WFConnection (if the peer tore down the connection before the other node had a chance to detect split brain).

スプリットブレインを検出した後では、一方のノードはずっと「StandAlone」になっていて、両方のノードが同時にスプリットブレインを検出していれば、もう一方のノードも「StandAlone」になっているかもしれないし、もう一つのノードがスプリットブレインを検出する前にコネクションを落としていれば、「WFConnection」になっているかもしれない。

At this point, unless you configured DRBD to automatically recover from split brain, you must manually intervene by selecting one node whose modifications will be discarded (this node is referred to as the split brain victim). This intervention is made with the following commands:

DRBDを自動的にスプリットブレインから復旧するように設定していなければ、こうなった時に、どっちのノードの変更を破棄するかを選択して、手動で介入する必要がある。この介入は、このコマンドで行われる。

と。

マスターとなる側では以下のコマンドを実行するらしい。

drbdadm connect resource

スレーブとなる側(つまり、変更点があっても破棄される側)では、以下のコマンドを実行するらしい。

drbdadm secondary resource

drbdadm — –discard-my-data connect resource

…というわけで、やってみたら、無事にConnection状態に戻った。

DRBD8からオプションが変わってた

DRBDをマスターとなるマシンとスレーブの両方にインストールし終わっただけでは、両方とも「Secondary」状態になっているので、マスター側を「Primary」状態にする必要がある。そのためには、2つのマシン間でデータの同期を行う必要がある。

そのマスターを「Primary」にして、最初の同期を取るコマンドが、DRBD7までは「–do-what-I-say」ってオプションが有効だったけれど、それがDRBD8からは「-overwrite-data-of-peer」に変更になったそうだ。というわけで、

drbdadm — -overwrite-data-of-peer primary all

をマスターとなるマシンで実行する。確かに「do what I say」よりは「overwrite data of peer」の方がわかりやすいオプションではあるけども。で、同期が始まった後で、/proc/drbdを覗いてみると、同期の進捗などが見える。

$ cat /proc/drbd

version: 8.3.0 (api:88/proto:86-89)

GIT-hash: 9ba8b93e24d842f0dd3fb1f9b90e8348ddb95829 build by root@localhost.localdomain, 2008-12-22 17:52:35

0: cs:SyncTarget ro:Secondary/Primary ds:Inconsistent/UpToDate C r—

ns:0 nr:28678656 dw:28670464 dr:0 al:0 bm:1749 lo:257 pe:1560 ua:256 ap:0 ep:1 wo:b oos:13271260

[============>…….] sync’ed: 68.4% (12960/40958)M

finish: 0:07:24 speed: 29,796 (29,676) K/sec

ただ、speedのところに書いてある、この約30M/secってのは、単位は何だろうってことで、調べてみた。で、DRBDのドキュメント(no title)を見てみると、speedの単位としては書かれていなかったけど、随所で「KiByte」って書いてあるから、きっと「30MByte/sec」ってことなんだろう。ってことは、だいたい240Mbpsくらいか。ギガビットなイーサネットを使っておいてよかった。

DRBDのプロトコル

DRBDのマスターとスレーブの通信方式は、3つの中から選べる。

drbd-8.3.0.tar.gzのサンプルのdrbd.confより

C: write IO is reported as completed, if we know it has reached _both_ local and remote DISK.

* for critical transactional data.

B: write IO is reported as completed, if it has reached local DISK and remote buffer cache.

* for most cases.

A: write IO is reported as completed, if it has reached local DISK and local tcp send buffer. (see also sndbuf-size)

*for high latency networks

DRBDを扱ったblogとかに載ってるdrbd.confを見ると、「C」になってることが多いけど、このサンプルファイルでは、「B」が「for most cases」となっている。サンプルのdrbd.confの続きにはこうも書いてあった。

uhm, benchmarks have shown that C is actually better than B. this note shall disappear, when we are convinced that B is the right choice “for most cases”. Until then, always use C unless you have a reason not to.

ベンチマーク的には「B」よりも「C」が優れているらしい。しかし、「B」の「remote buffer cache」って何を指しているんだろうか。Aがわざわざ「tcp」send bufferって書いてあるわけだから、tcpが付いてない=ネットワーク関連じゃないキャッシュなんだろう。そうなると、ディスクの書き込みキャッシュが思いついたりするが…そうなのか(汗)

でも、なんとなーく「C」の方が安心なプロトコルで、それって性能を犠牲にして実現されている方が、なんとなーく納得いくんだけどなぁ。まして、drbd.confを書いた人が、多くの場合、「B」が正しい選択って言う理由も気になるけども、、、書いてないか。

…でも、まぁ、とりあえず、「C」にしとく(汗)

DELL 2007 FP

会社でDELLの「デジタルハイエンドシリーズ 2007FP HAS」を使っている。この液晶、しばらく使っていると画面に横に長いノイズが何本か出て、ところどころ表示がおかしくなる傾向が出ていた。あと、液晶に特定の色が表示されているとおぼしきところがノイズでちらちらしたり。いずれにせよ、液晶の電源をいったん落として、再度、入れると直ったりする、ややこしい症状。

最初はこんなもんかなぁと思ってしばらく使っていたけど、なんとなく、いらいらしてきたのでDELLに電話してみた。そしたら、静電気が疑われるとのこと。液晶の電源を引っこ抜いて、電源ボタンを20回くらい押しまくってくれと言われた。素直に電源ケーブルを外して、電源ボタンを押しまくって、再度、電源をつっこむと普通に点いた。

…いや、点くのは点くんだよね。使っていると、時折、ノイズが出て、表示がおかしくなるのがタチ悪いわけで(汗)DELLのサポート担当には、今、その症状が出ているわけではなくて、こんなことをやっても再現性とか難しいと伝えてはみたのだが、しばらく様子を見てくださいと言われた。

これまで液晶を何枚も使ってきたが、(1)静電気がたまって、(2)それを取り除くために、電源を外して、電源ボタンを連射するなんて初めてなんだけどなぁ。。。

船橋の「蔵6330」ってカフェに行ってみた

前から気になっていた「蔵6330」ってカフェに行ってきた。GoogleMapで見てみると、どの駅からも遠くて歩いていくのは無理かなぁと思ったけれど、そこは強行軍(汗)。東葉高速の飯山満駅から意地と根性で歩いてなんとか到達。

f:id:y_fudi:20090412162135j:image

蔵6330の外観。

昼時を外して到着したのと、周囲の光景(…特に周りになんにもないので…)の割には、お客さんの数が多かった。

f:id:y_fudi:20090412145937j:image

蔵6330の看板。

オススメされるままに贅沢ランチセットをオーダー。サーモンのムニエルに、蔵焼きという名前の石窯で焼いた風のピッツァ、野菜のスープ、あと、飲み物とデザートがセットになっていて約2000円。サーモンのムニエルは火の通り、ソースともに絶妙で、真っ昼間からビールを頼んだことを後悔させない一品だったし、蔵焼きも、上に乗っていたゴルゴンゾーラの風味がすばらしかった。

食後にはジェラートを選択して、ジェラートの中でも季節限定の桜にしてみた。牛乳たっぷりで濃厚なジェラートに、おそらくは桜の塩漬けの風味と、塩漬けの塩分が効いていて、食後に口をさっぱりさせてくれる一品だった。

f:id:y_fudi:20090412153947j:image

隣の席のおじさんがおいしそうにコーヒー牛乳を飲んでいたけれど、もうおなかいっぱいで牛乳もコーヒー牛乳も飲めなかったのが残念。。。メニューにさりげなく書いてあったことだけど、牛乳の殺菌を蔵6330自身でやっているらしく(蔵6330の「6330」って、「63度で30分」っていう牛乳の低温殺菌のやり方から来ているらしい)、かなりこだわっているっぽかったので、これは悔やまれる。てか、また行くしかないかなぁと(汗)こだわりの牛乳で作ったプリンもおいしそうだった…。

あの「宮武」が閉店…。

四国新聞がさりげなく報じていたが、あの「宮武」が閉店したそうだ。

no title

上記の記事より。

讃岐うどんブームを代表する人気店「宮武うどん店」(香川県琴平町上櫛梨)が閉店した。店主の宮武一郎さん(66)が、年齢を重ね、体力的に限界を感じたことから決断したという。

同店は、父の士郎さん(故人)が1953年に創業。同店の代名詞にもなっている「あつあつ」「ひやあつ」といった注文の言葉は、同店を訪れた客が使ったのが発祥という。

「ひやあつ」とか「あつあつ」とか、今では普通に使われている、讃岐うどんの専門用語(?)を発明(??)したのが、宮武であったわけだし、とにかく、(地元の人間が立ち寄りづらいくらいに)県外からお客さんが訪れていたのもまた宮武だったような気がする。

私が最後に「宮武」を訪れたときの写真を貼っておく。この写真が撮影されたのは2006年9月だから、今から3年前の「宮武」を写していることになる。

f:id:y_fudi:20060917092755j:image

f:id:y_fudi:20060917102502j:image

9時半に並び始めて、1時間近く行列に並んで、宮武のうどんにありつけた。香川県民がうどん屋の行列に1時間も並ぶってのはかなりレアな事態だと思われる(…が、最近はそうでもないのかもしれない…)ので、ま、県外からかなり覚悟を決めてやってきているお客さんばかりだっただろう。

宮武のうどんは、讃岐うどんの「コシ」というものを理解できるうどんだった(個人的には、強いコシの麺が好みではないが、宮武のうどんのコシはキライじゃなかった)。関東でも、讃岐うどんっぽいうどんを目指して、単に茹で時間不足のうどんを出している店もあるが、宮武のうどんを食べれば、それが違うことを理解してもらえたような気がする。また、うどんを手切りしているためか、麺が微妙にねじれてたりするのがまた味わい深い。

確か、アジ天とげそ天を付けたが、5分もかからずに完食してしまった。正直、うどんをゆっくり味わう暇もなく、「食らってしまった」感じで、ちゃんと味わっておくべきだったと反省。。。

f:id:y_fudi:20060917103500j:image

上の「本日終了」の写真が撮影されたのは、宮武のうどんを堪能した帰りの午前10時30分頃。それでもかなりの行列ができていたことを覚えている。しかも、県外ナンバーのクルマが大挙して押し寄せて、駐車場があふれて、道路をふさいでいたため香川県警がやってきていたと思う。で、そのせいか(行列が長かったから玉切れの可能性はあったけど)、10時半にして「本日終了」になってしまっていた。

「宮武」はご主人の「体力の限界」を理由に閉店することになったが、とにかく大量の客が押し寄せるなか、これまで営業を続けてきた「宮武」のご主人の体力、気力はすさまじいと思う。

しかし。讃岐うどんが注目され、多くの観光客が押し寄せることは、香川県や多くのうどん屋にとって悪いことではないとは思うが、もし、大量の観光客が押し寄せず、「宮武」が田舎のうどん屋のままであったなら、もう少し、宮武のうどんを食べられたかもしれないなんて思うと、きっと、そんなもしもは無意味ではあるんだろうけれど、やはり残念な気がする。ま、ほどよいブームってのは無理か(汗)

*1:個人的には、強いコシの麺が好みではないが、宮武のうどんのコシはキライじゃなかった

«過去の 投稿 新しい 投稿 »