FreshConnection の ver0.0.2 をリリースしました。
FreshConnectionのver0.0.2をリリースしました。ソースコードはgithubにあります。
https://github.com/tsukasaoishi/fresh_connection
インストールは以下でOKです。
sudo gem install fresh_connection
ver0.0.2で変更になったのは以下の点になります。
■常にマスターDBをみたいモデルを指定可能に
ignore-tableの設定で、スレーブにレプリケーションしていないテーブルは、当然のことながら常にマスターDBを見にいかなくてはいけません。
FreshConnectionでは、config/initializers/fresh_connection.rbなどで以下のように設定します。
require 'fresh_connection'
FreshConnection::SlaveConnection.ignore_models = %w|Amazon|
FreshConnection::SlaveConnection.ignore_modelsに、マスターのみにアクセスしたいモデル名を配列で指定します。
上記の設定で以下のようなアクションならば
def test
article = Article.find(:first)
amazon = Amazon.find(:first)
render :text => "OK"
end
amazonsテーブルへのアクセスは常にマスターに向かいます。
Processing ArticlesController#test (for 127.0.0.1 at 2011-12-03 18:50:40) [GET]
SQL (7.6ms) SET NAMES 'utf8'
SQL (1.1ms) SET SQL_AUTO_IS_NULL=0
Article Load (5.5ms) SELECT * FROM `articles` LIMIT 1
[MASTER] Amazon Load (0.2ms) SELECT * FROM `amazons` LIMIT 1
Completed in 48ms (View: 0, DB: 6) | 200 OK [http://localhost/articles/test]
■同時に接続するスレーブは1台のみに
ver0.0.1では、ひとつのアクション内で複数のスレーブに接続できましたが、ver0.0.2からは接続するのは1台のみとなります。
これは、せっかくロードバランサを採用しているのに、FreshConnection内でもロードバランサのような仕事をしていたためです。ver0.0.1では、複数のスレーブに接続したコネクションを、ラウンドロビンで回していました。
もともとは、特定のスレーブに処理が集中しないようにと考えてのことでしたが、アクション単位でスレーブは変わるので、全体的にみたらあまり意味がないことでした。
このため、ver0.0.2ではシンプルに、ひとつのアクション内では1台のスレーブにのみ接続するようになりました。
★アクション処理中で接続していたスレーブが死んだときの対応
これをやらなきゃいかないと考えていたのですが、ぼくの環境だとスレーブDBが死んだときは、LVS+keepalivedのロードバランサが自動で生きているスレーブDBに接続を変えてくれました。
Rails側から見たときはコネクションにはなんの異常もなく、ずっと同じDBにつながっているという認識でいました。NATのためだと思って、DSRにしてみたのですが、結果は同じです。
これってこういうものなんでしょうか。当たり前のような気もするし、そうでない気もするのですが。今度、別のロードバランサ環境でテストしてみようと思います。