GitLab.comが操作ミスで本番データベース喪失。5つあったはずのバックアップ手段は役立たず、頼みの綱は6時間前に偶然取ったスナップショット － Publickey
果たしてGitLab.comで何が起きたのでしょうか？ これまでの経緯をまとめました。 スパムによるトラフィックのスパイクからレプリケーションの不調へ GitLab.comは今回のインシデントについての詳細な経過を「GitLab.com Database Incident - 2017/01/31」で公開しています。また、もう少し整理された情報がブログ「GitLab.com Database Incident | GitLab」にも掲載されています。 これらのドキュメントを軸に、主なできごとを時系列に見ていきましょう。 1月31日16時（世界協定時。日本時間2月1日午前8時）、YP氏（Yorick Peterse氏と思われる）はPostgreSQLのレプリケーションを設定するためにストレージの論理スナップショットを作成。これがあとで失われたデータを救う幸運につながります。 1月31日21時
マニュアル無視、不十分なバックアップ――ファーストサーバが最終報告書 － ＠IT
2012/08/02 ファーストサーバは7月31日、6月20日から21日にかけて発生した障害に関する調査報告書（最終報告書）を公開した。20日夕方に発生した大規模なデータ消失事故と、その復旧作業の過程で生じた情報漏えい事故それぞれについて、外部専門家からなる第三者調査委員会がまとめた。 報告書によると、顧客に大きな影響を与えたデータ消失事故の背景には、不具合を起こした担当者が社内マニュアルを無視し、独自方式でメンテナンスを行っていた事実があった。ほかの担当者は社内マニュアルに沿ってシステム変更を行っていたが、この担当者は約10年前から独自方式でメンテナンスを行っており、そのためのツールも自作。上長もこのことを認識しながら黙認していたという。 この担当者は6月20日午後5時頃、メールシステムの障害対策のため、既存の自作プログラムに改変を加えて更新プログラムを作成した。しかしこの際、既存のプロ
47NEWS（よんななニュース）
若者よ、船乗りにならないか 陸上勤務より高賃金、1カ月の長期休暇も魅力 国内貨物輸送の4割担う海運業界がPRに躍起となる深刻な事情
mixi大規模障害について 解明編 - mixi engineer blog
こんにちは、システム本部技術部たんぽぽGの森本です。 先日のmixi大規模障害の原因となったmemcachedの不具合の詳細な解明ができました。 再来週まで発表を見合わせようと思ったのですが、早くお伝えしたほうがいいと思いましたので公開発表致します。 memcachedとlibevent memcachedはlibeventというライブラリを使用してクライアントからの要求(接続、コマンド送信)を処理しています。 libeventを使用するにはevent_baseという構造体を用います。 main threadはmain_baseを使用します。 static struct event_base *main_base; ... int main (int argc, char **argv) { ... main_base = event_init(); ... /* enter the ev
楽天の研究者の方の発表聞いてきたときのメモ(大規模データ処理基盤 ROMA) - それなりにマジメなメモ
自分なりのメモなのでかなり適当です。 楽天技術研究所でやっていること 開発してるもの ROMAとは？ 大規模グリットRubyによるKey-Value Store RDBではトラフィックに耐えられない。 memocashなどを使うこともできるがデータの保障して使うことができるのか不安 使うのは主にエンドユーザー ROMAが落ちると1分間で何億もの損失 突発てきなトラフィックの増大にも強くする必要になる。 クリスマスなどのある程度いつおきるのか予想できるトラフィック増大に備えてやる 今はできていないがすべてのサービスが同時にトラフィックが増大するわけではないので サービスを動かすマシンの台数を変えられたらいいなぁ Fairy 文字抽出の研究 楽天で出てる店舗の方々はよく画像に文字を入れる人が多い。 薬事法などで使ってはいけない文字を入れてる人もいるので注意できるように画像の中の文字も検索がヒッ
mixi大規模障害について - mixi engineer blog
こんにちは。システム本部技術部たんぽぽGの森本です 先日のmixi大規模障害についてのブログです。 はじめにお断りしておきますが、弊社CTOがtwitterで公開した以上の情報はまだ得られておりません。 twitterでは書ききれなかった細部を補足してみたいと思います 現状判明しているのは以下の点です memcachedに大量の接続・切断を行うとmemcachedプロセスが突然終了することがある memcachedには異常時に終了するフローもあるが、同時に出力されるはずのエラーログは出ていなかった coreも出力されていなかった テスト環境にて追試を行ったところ、なんどか再現させることができましたが、確実に発生する条件は未だ不明です。 障害時の memcachedのバージョンは1.4.4, libeventのバージョンは1.3bです memcached の起動オプションは以下のとおり ./
mixi大規模障害について その2 - mixi engineer blog
こんにちは。システム本部技術部たんぽぽGの森本です 補足を追記しました (2010/08/20 15時) 先日のmixi大規模障害についての続報です 今回は小ネタはありません はじめに まず初めにtwitter/blogなどを通じて今回の問題の解析を行っていただいたみなさんに感謝の言葉を捧げたいと思います kzk_moverさん stanakaさん mala(bulkneets)さん llameradaさん (順不同) ありがとうございました 書き漏らした人ごめんなさい memcachedはすごい 今回の件でmemcachedに対して不安感を持たれた方もおられるとお聞きしました 説明不足だったせいで誤解を与えてしまい申し訳ありません きちんと設定および監視を行っていれば通常の使用にはまったく問題はありません 弊社にて -c 30万で起動したmemcachedに対して、先のテストスクリプトに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
