pcmasterのブックマーク / 2014年7月24日

pcmaster id:pcmaster

2014年7月24日のブックマーク (3件)

だからMacBook Airを二台買えと言ったのに！と妻に怒られた話
結城浩 / Hiroshi Yuki @hyuki 結城は（自分としては）他人の行動を支配したいという気持ちは少ないと思っています。でも世の中にはそこ（他人が自分の思い通りに動くこと）に命をかけている人がいるようです。その感覚は理解できますが、押し進めていくと破綻する望みですよね。結城浩 / Hiroshi Yuki @hyuki まあ、他の人はいいや。私はどうかな、と自分の心を探ってみると、「自分の意志で選んでほしい」と思ってるみたい。本を選ぶとか、まあ、そういうところで。私に言われたからではなく、本当に自分が好きだからという理由で選んでほしい…そう思っているみたい。
pcmaster 2014/07/24
リンク
MySQL 5.6 でのレプリケーション遅延は危険 : DSAS開発者の部屋
MySQL 5.6 の検証中に MySQL 5.5 とは違うタイプのレプリケーション遅延を見つけたので紹介します。 MySQL のレプリケーションのおさらい MySQL のレプリケーションは次のような仕組みで動作しています。マスターの更新トランザクションが binlog を書くスレーブの I/O スレッドがマスターに接続し、 binlog を取得し、 relaylog を書く. マスター側はスレーブからの接続を受け付けると(dump スレッド)、指定された場所から最新までの binlog を転送する binlog が追記されるのを待ってさらにスレーブに送るスレーブのSQLスレッドが relaylog を再生する MySQL 5.5 でよくあったレプリケーション遅延マスターは並列してトランザクションを処理して、最終的にコミットした順で反映されれば問題ないようになっています。一方、ス
pcmaster 2014/07/24
“この問題は SHOW SLAVE STATUS では監視できないので、 SHOW MASTER STATUS の File, Position と SHOW SLAVE STATUS の Master_Log_File, Read_Master_Log_Pos を比較する必要があるでしょう。 ”
リンク
ASCII.jp：データ消失！あのとき、ファーストサーバになにが起こったか？ (1/2)｜データ消失事故から2年！ファーストサーバ、再生への第一歩
今から2年前の2012年の6月20日、レンタルサーバー会社のファーストサーバは、大規模な顧客データの消失事故を引き起こした。あのときなにが起こったか？　ファーストサーバのさまざまな部門の担当に、当時の状態を振り返ってもらった。ファーストサーバは今も変わらずビジネスを展開しているファーストサーバの顧客データ消失事故に関するドキュメンタリーを書きたいと思った。事故の原因究明や責任の所在を明らかにするのではなく、当事者の話を積み上げていくような記事が書きたいと思った。そして、今回ファーストサーバの全面的な協力により、事故当時から現場を統率してきた現代表取締役社長の村竹昌人氏をはじめ、営業、開発、運用、マーケティング、広報、サポート、管理など各部門の担当者に話を聞くことができた（以下、敬称略・役職は現職）。事故から2年間の間、ファーストサーバはひたすら事故の影響を受けたユーザーへの対応と再
pcmaster 2014/07/24
リンク
- 2014年8月15日
- 2014年7月24日
- 2014年6月2日