愛車:マツダアテンザ
Webを中心とした、ビジネス&テクノロジーに関する思いつき
by F-shin
[ このサイトについて ] [ F-shinについて ] [ トップ ]
author:えふしん
photo_20.jpg
藤川真一について


モバツイの中の人
マインドスコープ(株)社長
人の良いジョンカビラと言われます。
AMN sponsor rolls
モバツイの2つのスマートフォン
アンドロイドアプリ!
アンドロイドアプリ モバツイtouch
全てのスマートフォンブラウザと、Nintendo3DSで! HTML5版Webアプリ「モバツイsmart」
本を書きました!
100万人から教わったウェブサービスの極意 ~「モバツイ」開発1268日の知恵と視点
Google Friend Connect
このカテゴリ[Web系]の最新30件
インターネットの可能性を信じて〜本を書きました。 ネットショップに20万円は高いという感覚は割と普通の感覚だと思う。 ソーシャルメディアの生かし方 インターネットは芸術だ ECサイトはGoolge検索エンジンのプラットフォームに乗ってることを自覚せよ Ubuntu 8.0.4でTwitter apiのSSL通信ができなくなった人向けのメモ インターネットを支える仮想共同体 twitterとfacebookのレイヤーは違う 文脈が共有できていないフロー型コミュニケーションの問題点 身も蓋もなくなるインターネット フェイスブックページっで起きるかなぁ?!って思ってること。 非公式RTじゃないとできないこと。公式RTが目指したもの。 ツイッターのつぶやき価値 ネットコミュニケーションは万人の手段ではない AWS東京リージョンとtwitter apiの関係 Facebookがインターネットになると困る デジタルネイティブではない30代のつぶやき ネチケットとアーキテクチャという法律のあいだに。 相撲の八百長問題に見られる、ITによるフローのストックという構図 Webエンジニアスキルの勘所 ツイッター面白いね WebSig一日学校で考えてたこと ソーシャルメディアについてのメモ User Streamの先にあるtwitter Web Creation Awardsにノミネートされました。 携帯Webのクッキー利用について調べてみたメモ【update】 twitterドラマと今後のツイッター デジハリの杉山学長賞をいただきました。 日経電子版を流行らせる一つの思いつき 商品の良さとリンクは、140文字で伝えなさい
[このカテゴリをもっと見る]
Powered by
Movable Type

April 24, 2009

このblogを始めた時には当然Doblogで書いてる人のblogも見てたけど、いつからかなぁ。ほとんど見なくなったのは。

こんなカタチで、有名blogサービスが一つ消滅してしまうとわ。。。

Doblogのサービス終了のお知らせ | お知らせ | NTTデータ

【故障内容の詳細】 故障内容 (1)データベースサーバーのRAID5構成のハードディスク2本が同時に破損 1本の破損であれば残りの5本から情報を再構成できますが、破損が2本に及んだためデータを読み取ることが出来なくなりました。 (2)更にバックアップ用のサーバでも障害が発生 これによりバックアップのデータにも異常が生じたため、皆様の記事情報を復旧することが困難な状態となりました。

だからRAID5は信用できないと(w

F's Garage:RAID5は全然信用できない。

RAID5は、システムの信頼性を上げる技術じゃなくて、「容量を増やす技術」だ。かつスピードを早くするための技術でもあるのかな。

勘違いしてるケースは多いと思うがシステムの信頼性は、RAID1(ミラーリング)の方が上だ。

RAID5では1台のHDDが壊れた後の再構築中に2台目が壊れることが無視できないという話がRAID6のメリットを主張する話に書いてある。同一環境、同一のデータを読み書きし続けてきた同一ロットのHDDであれば寿命も似たりよったりというのが一つの根拠。また、リビルド時の負荷で最後の引導を渡すというのもあるだろう(これはRAID1も同じ)

HDDが6台でRAID5を構成していたようだが、つまり1台目のHDDが壊れたときに続いて2台目のHDDが壊れる可能性は、ミラーリング構成の実に「5倍」ということになる。

RAID5は、6台だろうが10台HDDがあっても、そのうち2台がハズレクジを引いたら全部がオジャンという非常にリスキーな仕組みだ。

故にDBのレプリケーション(リアルタイムコピーみたいなもん)などをしてないと、バックアップが1日1回動いてたって、いつ1日分のデータが消滅するかわからないわけだが、DBがシングル構成だったわけですね。

せめてMySQLあたりと低コストサーバでレプリケーションしてあげてれば。。。

(レプリケーションは、間違って消しただの全件updateしたなどのセキュリティ不具合&人為的ミスに対処できないので物理バックアップと併用するのが正解)

あとバックアップ用サーバーってさ。つたない経験なんですが、バックアップが動いてないとかってあるわけよ。で、それが発覚するのがバックアップしてるハズのデータが必要になった時、みたいな(爆)

異常系のテストをちゃんとしてんのかよー!とか、容量が日々増えていくのでバックアップを維持運用するのも結構大変だよね、とか。今回のケースがそうだとは当然言いません。

あと、差分を取っていく世代バックアップでありがちなのが、「壊れたデータをバックアップしちゃって全部消えました」とか。更に容量の問題から、1世代までしか記録してなくて、全部消えました、とか。それまでに運用で気がつくハズという慢心がもたらす二次的被害があったり、こういう状況ではバックアップしない、というインターロックがそもそもなかったり。

バックアップはフロントシステムほど監視をしてないし、一度稼働し始めるとおざなりになりがちなので結構怖い。

なんとなくシステムの状況から邪推すると、サービスの辞め時を誤ったってのはあるんだろうなぁ。
既に先頭で旗振ってた人たちがいなくなったり、エライ人の一言で始まったサービスだったりして、誰も責任取れずに終わり時もない、みたいな。終わるは終わるためのパワーが必要ですしね。

復旧に携わったエンジニアの方々お疲れ様でした。
是非、最後まで面倒をよろしくお願いします。

■同じカテゴリ[Web系]のエントリー
<<前の記事 Web2.0は死んだとか言うbuzzwordに影響されてる開発者は、自分の開発手法が当たり前のようにWeb2.0化していることに気がつくべき。
>>次の記事 ニコニコ動画がiPhoneアプリで登場!
■このblogの書き込み最新3件
インターネットの可能性を信じて〜本を書きました。 バルスのツイート機能に関する謝罪を書いたら沢山反応があった件 モバツイの広告の取り組みについて、発表資料の共有
この記事への提案、提言一覧
この記事への提案、提言









あなたの情報を保存しますか?