FreshConnection の ver0.0.2 をリリースしました。

Tsukasa OISHI

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にしてみたのですが、結果は同じです。
これってこういうものなんでしょうか。当たり前のような気もするし、そうでない気もするのですが。今度、別のロードバランサ環境でテストしてみようと思います。