[B! trouble] [2ページ] muddydixonのブックマーク

Pulling Docker images: i/o timeout

muddydixon 2015/07/23

なんだこの解決・・・・確かに解決した・・・

リンク

閏秒を迎えるにあたってLinuxでは何を対策すべきか？ | Act as Professional

2016/12/27 更新Googleなどの大手IT企業がうるう秒対策済のNTPサーバが公開したため、これを利用する内容などを以下にまとめました。元旦に実施されるうるう秒の対策まとめ2016/07/08 更新2017/1/1に閏秒の実施が決定されました。対応はこの記事のとおりで問題なさそうです。 2015/06/24 情報追加(2015/06/29 更新)下記の対応に関わるntpdの比較的新しいバージョンにSLEWモードで動作していても、うるう秒が挿入されるバグが発見されました。[redhat] これによりntp-4.2.8p3-RC1以降のバージョンでないとSLEWモードで動作していてもうるう秒が挿入されます。RedHatはntp-4.2.6p5-3.el6_6という対応済みのバージョンを提供しています。Ubuntuでは今日現在12.04LTS, 14.04LTSの２バージョンはパ

muddydixon 2015/01/09

リンク

[Q&A]MySQL開発でやってしまいがちな致命的ミス | Yakst

Percona MySQL Webinarsの発表(MYSQL開発でやってしまいがちな致命的なミスについて)のQAをご紹介します。本発表はSQLアンチパターン著者のBill Karwinさんの発表です。オリジナル: http://www.percona.com/resources/mysql-webinars/how-avoid-even-more-common-deadly-mysql-development-mistakes July 17, 2014 by Bill Karwin 水曜日に「MySQLを開発する上でよく起こる(そして致命的な)ミスをどのように回避するか」をPercona MySQL webinarsで発表した。お見逃の際は、ビデオとスライドを見る為に登録すればまだご覧にいただける。参加いただいた皆様、そしてとりわけすばらしい質問をしていただきありがたく思っている

muddydixon 2014/08/13

リンク

DDoS攻撃されたらそこで試合終了!? レンサバから利用停止を宣告される前にできる8つの対策 - Qiita

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? もしも運用しているサーバにDDoS攻撃をされて、大量のトラフィックを理由にホスティング業者から、そのサーバの利用停止を唐突に宣告されたらどうしますか? なにか対策を考えていますか? by woodleywonderworks. CC BY 2.0 「ファイアウォールでそういった攻撃を防いでいるから大丈夫」「まさか契約上そんな一方的なことができるはずない」と思うかもしれません。私もそのような認識でした。しかし、実際にDDoS攻撃を受けてみると業者の対応は次のようでした。ホスティング業者は味方をしてくれないホスティング業者は技術的に的は

muddydixon 2014/05/21

想像以上に怖い話だった

リンク

大規模障害から1年余り、あの企業が「その後」を語った

「この度は取材をお受けしましたが、どう対応したらよいか。今でも迷いがあります」。担当者は取材の冒頭で、心境をこう吐露した。記者は取材のためレンタルサーバー事業を手掛けるファーストサーバ（本社：大阪市）を訪れた。1年半ほど前に、顧客企業が利用していたサーバー約5700台のデータをほぼ消失させる大規模障害を起こした事業者だ。今回の取材は、過去に失敗を経験した複数の企業や公的団体に申し込んだ。目的は、「IT運用の失敗から技術者がどう学び、再発防止に取り組むべきか」をまとめる企画記事を執筆するためだ。中でもファーストサーバは、運用のプロであるべきITベンダーが、一部とはいえ現場担当者のずさんな運用作業を見逃していた実態が明るみになり、個人としても大きな衝撃を受けた。失敗を経てどう体制を立て直したのか、大いに興味があった。「非技術者」にも分かる再発防止策を：ファーストサーバ簡単に、ファース

muddydixon 2014/02/20

読む前からドキドキした

リンク

TwilioのRedisによる決済サービスの障害、2つの原因 - unknownplace.org

Twilio というサービスで決済サービスの障害があったらしいが、恐しいことにこのサービス、決済情報をRedisで管理していたらしい、というのをRedis作者、antirez氏のblogで知った。 Twilio incident and Redis - Antirez weblog この件に関しては、Twilio自体も調査報告を出している。簡単にまとめるとこういう感じだ: TwilioではRedisを single-master, multi-slave なレプリケーション環境で使用しているネットワーク障害で一時的に master-slave 間の接続が切れたことにより、master-slave間のデータの再同期が発生この再同期がすべてのslaveに対して同時に発生したため、masterの負荷が高くなり、結果決済サービスの障害が発生この負荷を解決するためmasterを再起動する

muddydixon 2013/07/25

リンク