今更だが、RedisのSlaveのExpireは信用してはいけない - maedamaのブログ
また、障害起因でのブログです。忘れないようにこちらにメモります。 http://trapezoid.hatenablog.com/entry/2013/02/10/035020 にも詳しくかいてあります。 とあるreplication をくんでいるRedisの系統があった。Replication をくんではいるものの、とある事情により Slaveには参照していなかったが、突如 Masterのロードがあがったので Slave に負荷分散する必要が生まれ、あれ？大丈夫だっけ？とある事情ってなんだっけ？ってなったのでそのとある事情についてまとめます。 Slave の expireは信用できない。 結論だけ述べると、 MASTER に 以下のようなコマンドうち SETEX foo 3 1 #key Fooに3秒のexpireで1というvalueをset 10秒後にSlaveにGetコマンドをうつと
ActiveRecord Sharding
前回の続き ActiveRecordが実際にDBにクエリを発行する場合ActiveRecord::Base.connectionを経由する。話を単純にする為に、クエリの実行だけに限定してShardingを実現しようと思った場合このメソッドがそれぞれのShardに対して確立されたコネクションを返せば良い。 一番多く採用されている実現方法はconnectionメソッドを上書きしてproxyを経由させるパターンで、多くのGemで採用されている。その他にもコネクションの確立方法・管理などで既存のGemがどうやって実現しているかをいくつか紹介する。 Octopus おそらく一番有名なのかもしれないGem。kovyrin/db-charmerの影響を少なからず受けている。 実際に置き換えているのは、ActiveRecord::BaseにOctopus::Modelをextendした際に実行されるhij
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
