こんにちは、masm11 です。
弊社では PostgreSQL のデータベースを Amazon Aurora に移そうとしていますが、
フェイルオーバー時の処理が気になっています。
ググってみたところ、MySQL の情報はたくさん出てくるのですが、PostgreSQL の情報は
少なく、欲しい情報が出てきません。
今回は、弊社で使用している Rails 5.1 でフェイルオーバー時の動作をコードレベルで追いかけてみます。
unicorn は都度接続なのか?
その前に、確認しておきたいことが一つありました。
unicorn が HTTP リクエストごとに DB に接続/切断しているのかどうかです。
config/database.yml には、以下のように設定してあります。
staging:
adapter: postgresql
database: ...
username: ...
password: ...
host: ...
statement_limit: ...
伏せ字ばかりですが、pool: の設定はしていません。
activerecord-5.1.7/lib/active_record/connection_adapters/abstract/connection_pool.rb に以下のコードがあります。
@size = (spec.config[:pool] && spec.config[:pool].to_i) || 5
省略した場合、デフォルトは 5 ですね。プールしていそうです。
他の確認もしてみました。
$ netstat -anp | grep :5432
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp 0 0 172.31.30.216:24023 172.31.26.254:5432 ESTABLISHED 13853/unicorn worke
(以下略)
少し時間が経った後、もう一度確認したところ、:24023 の部分が変わっていませんでした。
都度接続しているなら、ここが変わっていくはずです。
やはりコネクションをプールしているようです。
unicorn はシングルスレッドで、コネクションプールから接続を取得して返却し取得して返却し… を
繰り返しているので、デフォルトの 5 でもプロセスごとに1本しか使っていないのでしょう。
都度接続なら、そのたびに Aurora の cluster endpoint を DNS で引けば常に master を向いており、
フェイルオーバー時も新しい master を向いているので、そのまま何もしなくて良いはずです。
しかし、今コネクションプールを使っているアプリケーションを(なんとかして)都度接続に変更すると、
接続のコストが高すぎるように思います。
やはり、フェイルオーバーで接続が切れた場合にどうなるのか、処理を追う必要がありそうです。
Rails のコネクションプールの処理を追う
接続を取得する際によく使うメソッドは ActiveRecord::Base.connection ですね。ここをスタート地点にします。
activerecord-5.1.7/lib/active_record/base.rb では以下のようになっています。なお、途中のコメントやコードは省略して、必要な部分のみ引用しています。
module ActiveRecord
class Base
extend ConnectionHandling
そして activerecord-5.1.7/lib/active_record/connection_handling.rb に
module ActiveRecord
module ConnectionHandling
def connection
retrieve_connection
end
とあります。スタート地点はここのようです。
同じ module の中に以下がありました。
def retrieve_connection
connection_handler.retrieve_connection(connection_specification_name)
end
retrieve_connection メソッドを呼び出しています。同名ですが別のメソッドのようです。
探してみたところ、activerecord-5.1.7/lib/active_record/connection_adapters/abstract/connection_pool.rb に以下のメソッドがありました。
module ActiveRecord
module ConnectionAdapters
class ConnectionHandler
def retrieve_connection(spec_name)
pool = retrieve_connection_pool(spec_name)
raise ConnectionNotEstablished, "No connection pool with '#{spec_name}' found." unless pool
conn = pool.connection
raise ConnectionNotEstablished, "No connection for '#{spec_name}' in connection pool" unless conn
conn
end
クラス名から考えて、おそらくこれでしょう。
該当するコネクションプールを取得して、pool.connection で接続を取得しているようです。
同じファイルの中に以下のメソッドがあります。
module ActiveRecord
module ConnectionAdapters
class ConnectionPool
def connection
@thread_cached_conns[connection_cache_key(@lock_thread || Thread.current)] ||= checkout
end
ここでは、スレッドごとに接続をキャッシュしているようです。キャッシュになければ checkout するのですね。
checkout を見ていきましょう。
def checkout(checkout_timeout = @checkout_timeout)
checkout_and_verify(acquire_connection(checkout_timeout))
end
checkout_and_verify。それっぽい名前ですね。接続が生きているか確認してそうです。このメソッドを追います。
def checkout_and_verify(c)
c._run_checkout_callbacks do
c.verify!
end
c
rescue
remove c
c.disconnect!
raise
end
なんだか複雑です。引数 c には acquire_connection の返り値が渡るので、接続ですね。
c.verify! でチェックしてそうです。
verify! は activerecord-5.1.7/lib/active_record/connection_adapters/abstract_adapter.rb にあります。
def verify!(*ignored)
if ignored.size > 0
ActiveSupport::Deprecation.warn("Passing arguments to #verify method of the connection has no effect and has been deprecated. Please remove all arguments from the #verify method call.")
end
reconnect! unless active?
end
active? と reconnect! が出てきました。一つずつ見ていきます。
active? は同じファイルの中にもあるのですが、
def active?
end
と空っぽです。おそらく他の場所でクラスを継承してオーバーライドしているのでしょう。
activerecord-5.1.7/lib/active_record/connection_adapters/postgresql_adapter.rb にありました。
def active?
@lock.synchronize do
@connection.query "SELECT 1"
end
true
rescue PG::Error
false
end
SELECT 1 を実行してみて、問題なければ true、失敗なら false を返しているだけですね。
接続が生きているかの確認はここにありました。
active? は理解したので、引き続き reconnect! を見てみます。
activerecord-5.1.7/lib/active_record/connection_adapters/abstract_adapter.rb に
def reconnect!
clear_cache!
reset_transaction
end
とあって、それだけ?? と思いましたが、activerecord-5.1.7/lib/active_record/connection_adapters/postgresql_adapter.rb にもありました。
def reconnect!
@lock.synchronize do
super
@connection.reset
configure_connection
end
end
super で先に上げた方の reconnect! を呼び出しているんですね。
そして @connection.reset です。
@connection は同じファイルで以下のように作っています。
def connect
@connection = PG.connect(@connection_parameters)
configure_connection
rescue ::PG::Error => error
if error.message.include?("does not exist")
raise ActiveRecord::NoDatabaseError
else
raise
end
end
PG.connect で作っています。PG は pg という gem で定義されています。
つまり @connection.reset の reset メソッドは pg gem の方にあります。
せっかくここまで来たので、ついでに見ていきます。ここからは C 言語になります。
pg-0.21.0/ext/pg_connection.c で以下のようになっています。
rb_define_method(rb_cPGconn, "reset", pgconn_reset, 0);
ruby でいう reset というメソッドは、C では pgconn_reset() 関数なのですね。
この関数は以下のようになっています。
static VALUE
pgconn_reset( VALUE self )
{
pgconn_close_socket_io( self );
gvl_PQreset( pg_get_pgconn(self) );
return self;
}
いろいろやってますね。一つずつ見ていきます。
pgconn_close_socket_io() は以下の通りです。
static void
pgconn_close_socket_io( VALUE self )
{
t_pg_connection *this = pg_get_connection( self );
VALUE socket_io = this->socket_io;
if ( RTEST(socket_io) ) {
#if defined(_WIN32) && defined(HAVE_RB_W32_WRAP_IO_HANDLE)
int ruby_sd = NUM2INT(rb_funcall( socket_io, rb_intern("fileno"), 0 ));
if( rb_w32_unwrap_io_handle(ruby_sd) ){
rb_raise(rb_eConnectionBad, "Could not unwrap win32 socket handle");
}
#endif
rb_funcall( socket_io, rb_intern("close"), 0 );
}
this->socket_io = Qnil;
}
見づらいので、windows 専用コードを削除してみると、以下のようになります。
static void
pgconn_close_socket_io( VALUE self )
{
t_pg_connection *this = pg_get_connection( self );
VALUE socket_io = this->socket_io;
if ( RTEST(socket_io) ) {
rb_funcall( socket_io, rb_intern("close"), 0 );
}
this->socket_io = Qnil;
}
ruby レベルで socket を close しているようです。
次に、pg_get_pgconn() は以下のようになっています。
PGconn *
pg_get_pgconn( VALUE self )
{
t_pg_connection *this;
Data_Get_Struct( self, t_pg_connection, this);
if ( !this->pgconn )
rb_raise( rb_eConnectionBad, "connection is closed" );
return this->pgconn;
}
接続に対応する構造体のポインタを取得しているだけのようです。
最後に gvl_PQreset() です。パッと見、見つかりませんでしたが、gvl_wrappers.c にありました。
FOR_EACH_BLOCKING_FUNCTION( DEFINE_GVL_STUB );
FOR_EACH_BLOCKING_FUNCTION はマクロです。gvl_wrappers.h で以下のようになっています。
#define FOR_EACH_BLOCKING_FUNCTION(function) \
(略)
function(PQreset, GVL_TYPE_VOID, void, PGconn *, conn) \
(略)
DEFINE_GVL_STUB が引数 function に渡されるので、
DEFINE_GVL_STUB(PQreset, GVL_TYPE_VOID, void, PGconn *, conn)
となります。そして DEFINE_GVL_STUB がまたマクロで、以下のようになっています。
#define DEFINE_GVL_STUB(name, when_non_void, rettype, lastparamtype, lastparamname) \
rettype gvl_##name(FOR_EACH_PARAM_OF_##name(DEFINE_PARAM_LIST3) lastparamtype lastparamname){ \
return name( FOR_EACH_PARAM_OF_##name(DEFINE_PARAM_LIST1) lastparamname ); \
}
渡された引数を使って展開すると、以下のようになります。
void gvl_PQreset(FOR_EACH_PARAM_OF_PQreset(DEFINE_PARAM_LIST3) PGConn *conn){
return PQreset( FOR_EACH_PARAM_OF_PQreset(DEFINE_PARAM_LIST1) conn );
}
FOR_EACH_PARAM_OF_PQreset もマクロで、以下のように定義されています。
#define FOR_EACH_PARAM_OF_PQreset(param)
空です。これも展開すると、以下のようになります。
void gvl_PQreset(PGConn *conn){
return PQreset(conn);
}
たくさんのコードを列挙しなくて済むようマクロが使われていたので、解読に少し手間取りましたが、
結局 gvl_PQreset() は PQreset() を呼んでいるだけですね。
PQreset() のドキュメントはこちらにあります。
同じパラメータを使って同じサーバへ接続するそうです。
まとめ
ActiveRecord::Base.connection は、コネクションプールから接続を取得して返します。
コネクションプールは配列から接続を取り出して、生きていればそれを返し、死んでいたら PQreset() で
復活させてからそれを返すようです。
PQreset() のドキュメントを読むと、同じパラメータを使って同じサーバへ接続するそうでが、
接続時のパラメータとして指定するのはホスト名であって IP アドレスは指定しません。
接続しなおす時に DNS を引き直してくれるのかどうかは判りませんでした。
DNS を引き直さない場合、本当に「同じサーバ」(同じインスタンス) になってしまい、
そこはおそらく read-only です。
ドキュメントの説明が若干曖昧なので、あとは実際にテストしてみるしかないかな、と思いました。
