人の作ったものは完璧ではない。完璧でないものはクラッシュする。故にデータベースはクラッシュする。サーバハードウェアの故障、OSのクラッシュ、データベースそのもののバグなど原因は様々であるが、永遠に停止することなく動き続けるRDBMSというものは存在しない。もちろん数年間無停止で問題が出ない場合もあるが、クラッシュするときはするので対策が必要である。もしもの時に備えて抜かりないのがスマートなオトコのスタイルである。データベースのご利用は計画的に。 と思ったそこのアナタ!!人生そんなに楽ではありません。 もちろんRDBMSはトランザクションのDurabilityを保証しているので99%の場合はそれでOKだけど、それはCOMMITが成功した場合の話。COMMITは大抵の場合高速な処理であるが、それでも処理にかかる時間はゼロではない。アプリケーションがデータベースサーバにCOMMITを送信してから
ちょっと前にエントリにも書いた業務アプリですが、セッション管理に repcached を使っています。repcached とは memcached にデータのレプリケーション機能を追加実装したもので KLab 株式会社が開発したソフトウェアです。レプリケーションの機能により可用性は飛躍的に向上しているかわりに、まぁぶっちゃけ速度はかなり犠牲になっています。※ベンチマークをとったわけではないけど負荷テストで体感できるくらい違う。 さて、今回のアプリケーションサーバの構成としては、Oracle RAC + memcached でオラクルでも快適なセッション管理を! で書いたような以下の構成になっています。 memcached のメモリには 1GB を割り当てていたのですが、ちょっとメモリが少なかったようです。運用し始めて数日後にセッションが保持されない不具合にみまわれました。随所に warn
某サービスでセッション情報を保持するために利用している memcached(repcached)に障害が起こった。 ちゃんと追えていないけど、おそらく以下のような原因。他の人がハマらないように。 障害発生まで memcached(repcached)の中には揮発したらそれなりにマズい情報が入っている。 repcachedサーバ2台のOS入れ替えをしていて、1台は再起動が成功した。 1台目のサーバへ2台目のサーバからのレプリケーションが完了したのをstatsのcurr_itemsにて確認した。 よって2台目を再起動するものの、起動しなくなった。 この時点では、1台は生きているから後でデータセンターいこうっと、という気軽な気持ちだった… 現象 生きている1台目のサーバで、以下のような現象が起こった… 値をsetする際に、ある閾値以上のexptimeを指定すると即expireされる。 その閾値は
*openLDAPに異常が発生。具体例。 slapd の設定ファイルをチェック中: bdb_db_open: unclean shutdown detected; attempting recovery.〜 *この状態で固まってしまう。OS起動時にプロセスを自動起動にしてあると、これのせいでOSそのものが立ち上がらなくなるので注意。その場合はプロセスを手動で起動していく。 *bdbの破損を疑ってみる。 *データベースファイルのフォルダに移動。 # cd /var/lib/ldap (ここはslapd.confに依存) # ls DB_CONFIG __db.004 cn.bdb log.0000000001 ou.bdb __db.001 __db.005 dn2id.bdb mail.bdb sn.bdb __db.002 __db.006 gidNumber.bdb memberUid
How To Troubleshoot Wireless Network Connection in Ubuntu by ruchi · March 29, 2008 In setting up their wireless connection for the first time, Im discovering many individuals having problems connecting through Network Manager or other GUI wireless connection tools. In fact my Network Manager is intermittently buggy, connecting sometimes and not others. This guide benefits all users in case the GU
どれだけ自分のLinuxマシンを溺愛していたとしても、いずれはレスキューを行わなければならないときがやってくるのである。そう、Linuxマシンであっても大惨事が起こってしまうことはあり得るのだ。画面設定を誤ったり、カーネルの更新に失敗したり、initスクリプトの設定でミスを犯したりといったことは避けられないのである。実際、私はさまざまな場面でそれが起こるのを目の当たりにしてきた。ときには、それは私自身のマシンでも起きた。多くの場合、それらはXの設定を間違えたのが原因だったが、そのたびにいつも私は腹を立てていた。 このような状況ではレスキューを試みるしかないわけだが、私の考えでは、最善の策には再インストールは含まれない。それどころか、レスキューディスクからのブートすら必要とならない場合もよくある。本稿では、そのような状況に陥らないための方法と、動作しなくなったLinuxマシンを復旧させるため
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く