[B! failover] muddydixonのブックマーク

Fluentd 入門〜運用に必要な基礎知識〜

最近業務で Fluentd を触ることが出てきて入門したんですが、最初のうちはトラブルが起きた時に何が起きているのか、どう対処したら良いのかがさっぱりわからなかったので、「Fluentd ってログの収集とかに使われるやつでしょ？」程度の知識しかなかった過去の自分に向けて「とりあえずこれぐらいは知っておけ！」と言いたい内容をまとめてみました。トラブルが起きた時にどの処理で問題が起きているのか素早くコードを追うことができて、データの消失を最小限に抑えつつ適切に対処できるようになることを目的としています。なお、現時点で最新版の Fluentd v0.14.21 を対象にしています。アジェンダ Getting Started Fluentd のアーキテクチャ Processes Supervisor process Worker process Threads Input thread En

muddydixon 2017/10/23

RailsとAmazon Aurora利用時のフェイルオーバー問題を解決 - matsukaz's blog

tl;dr RailsのコネクションプールとAmazon Auroraのフェイルオーバーの仕組みは相性が悪く、フェイルオーバー時に致命的な問題が発生する解決方法の1つは、コネクションプールを使わないことただし、都度接続だと接続コストがかかる New Relicなどを使ってる場合は、自分の実装以外で使ってるコネクションまで都度接続になってしまう別スレッドでDB操作を行っている場合、処理中であってもそのスレッドのコネクションまで切断されてしまう（Railsのコネクション破棄がプロセス単位のため）コネクションプールを活かしたままこの問題を解決できたので、その方法をご紹介します。ちなみにRails 4.2の話。 RailsとAmazon Aurora利用時のフェイルオーバー問題とは詳しくはこちら qiita.com 問題が発生する状況をまとめると以下の通りです。 Amazon Auror

muddydixon 2017/08/01

リンク

ConsulによるMySQLフェールオーバー - @ijin

先日(6/22/14)、6月なのにどういう分けか早めに開催されたJuly Tech Festa 2014でConsulについて発表してきた。そのユースケースの一つとしてMySQL failoverをちょっとだけ紹介したので、ここに詳しく書いておく。 MHA MySQLレプリケーションの障害時にフェールオーバーしたい場合、MHAを使うの結構ポピュラー（日本では）だと思います。MHAは最新binlogの適用、Slaveの昇格とレプリケーションの張替えまではやってくれますが、実際のフェールオーバーの部分はユーザに委ねられていて、master_ip_failover_scriptのテンプレートをカスタマイズするか独自実装する必要があり、一般的な実現方法としてはカタログデータベースの更新かVirtual IPの切替等があります。 Virtual IPだと居残りセッションの問題や切替の保証難しかったり

muddydixon 2014/07/14

リンク

flunetd、forward先がダメだった時にforward元である程度ログを担保したい · さよならインターネット

April 1, 2014 fluentdのbufferとforwardについて調べたのでメモ。 fluentd v0.10.45 追記( 04/02 00:27) @kenjiskywalker flushしようとしてできなかったbufferにもlimitまで溜まるから、1kbのbufferが128個で限界にはならないような気がしますが — fujiwara (@fujiwara) April 1, 2014 @fujiwara 今手元で試したんですけどflush_interval関係なさそうですね。普通にflush_interval 1s buffer_chunk_limit 10とか指定してもそれ以上のbuffer保持してました — kenjiskywalker (@kenjiskywalker) April 1, 2014 @tagomoris @fujiwara なるほど〜！ —

muddydixon 2014/04/06

リンク

Redis 2.8 の Sentinel の動きを検証してみた - chrone's external storage

Redis 2.8 の redis-sentinel によるレプリケーションの自動フェイルオーバーについて、比較的発生しそうな障害を想定して動作検証してみました。結論から redis-server の自動再起動を構成している場合は要注意。 daemontools とか。 Master が落ちた後すぐ(例えば数秒)に再起動してきた場合、再び Master としてレプリケーションに参加します。よって、Master 再起動の前後でデータに差異があった場合でも、再起動後のデータをもとに同期される為、データが破壊される可能性があります。これを回避する為には、Sentinel により sdown/odown として認識されるのを待ってからインスタンスを復帰させるようにします。復帰が早すぎると、障害(sdown/odown)ではなく再起動(reboot)と認識します。レプリケーションの再

muddydixon 2014/03/10

リンク

エンジニアなら知っておきたい障害報告&再発防止策の考え方 - Qiita

システムには障害がつきものです。どんなにしっかりと作られたサービスであっても思わぬところで、バグやミスが発覚して、トラブルになるものです。大事なのはこういった障害を次への糧にしていくこと。失敗というのは大事な資産なので、管理できるようにしましょうという話。あわせて読みたいあきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチメンタリングの方法について基礎をまとめました。内心でなく行動を変えることが障害報告とも共通します。新入社員が来てメンターになれって言われたけど、どうすればいいのかという対話テクニック半年で40kg痩せた！ダイエットでわかるリーンなプロジェクトマネジメント手法心理的安全性ガイドライン（あるいは権威勾配に関する一考察）障害の種類と障害報告について障害には、小さなもの、たとえば画面に表示されているテキストの乱れから、すべての画面で50xエラーが発生