19
Help us understand the problem. What are the problem?

More than 5 years have passed since last update.

posted at

updated at

Organization

Amazon AuroraのフェイルオーバーとRailsのコネクションプーリング

ちょっと先日事故ったのでメモを兼ねて。

Auroraのフェイルオーバーの挙動

まずは、Auroraのフェイルオーバーの挙動。
従来のRDSではマスターデータベースをAZ構成にしておいてレプリカをぶら下げる構成だったが、Auroraからはデフォルトでクラスタになっている。

使用出来るエンドポイント

クラスタの真前をfailover-aurora、インスタンス名をfailover-aurora-instance という名前でauroraのクラスタを作ると以下の様なエンドポイントが得られる。

Cluster Endpoint

クラスターに対して書き込みをする用のエンドポイント。
こんな感じ。

failover-aurora.cluster-xxxx.ap-northeast-1.rds.amazonaws.com

Reader Endpoint

クラスターに対して読み込みをする用のエンドポイント。レプリカのどれかに紐づく様になっていて、書き込みをするとエラーになる。-roというsuffixが付く。

failover-aurora.cluster-ro-xxxx.ap-northeast-1.rds.amazonaws.com

各インスタンスのEndpoint

インスタンス毎にもエンドポイントが存在する。

マスター

failover-aurora-instance.xxxx.ap-northeast-1.rds.amazonaws.com

レプリカ (AZの名前がつくらしい)

failover-aurora-instance-ap-northeast-1a.xxxx.ap-northeast-1.rds.amazonaws.com

IPをひいてみると

実際のDNSレコードがどういう構成なのかIPを問い合わせてみる。

Cluster Endpoint

failover-aurora.cluster-xxxx.ap-northeast-1.rds.amazonaws.com. 5 IN CNAME failover-aurora-instance.xxxx.ap-northeast-1.rds.amazonaws.com.
failover-aurora-instance.xxxx.ap-northeast-1.rds.amazonaws.com. 5 IN A 172.30.25.134

Reader Endpoint

failover-aurora.cluster-ro-xxxx.ap-northeast-1.rds.amazonaws.com. 1 IN CNAME failover-aurora-instance-ap-northeast-1a.xxxx.ap-northeast-1.rds.amazonaws.com.
failover-aurora-instance-ap-northeast-1a.xxxx.ap-northeast-1.rds.amazonaws.com. 5 IN A 172.30.3.157

Cluster Endpointは、マスターデータベースを指すエンドポイントのCNAMEになっていて、Reader Endpointはレプリカを指すエンドポイントのCNAMEになっている事が分かる。

フィエルオーバー後のIP

実際にフェイルオーバーを起こした後に、IPがどう変化するかを確認する。

Cluster Endpoint

failover-aurora.cluster-xxxx.ap-northeast-1.rds.amazonaws.com. 1 IN CNAME failover-aurora-instance-ap-northeast-1a.xxxx.ap-northeast-1.rds.amazonaws.com.
failover-aurora-instance-ap-northeast-1a.xxxx.ap-northeast-1.rds.amazonaws.com. 5 IN A 172.30.3.157

Reader Endpoint

failover-aurora.cluster-ro-xxxx.ap-northeast-1.rds.amazonaws.com. 1 IN CNAME failover-aurora-instance.xxxx.ap-northeast-1.rds.amazonaws.com.
failover-aurora-instance.xxxx.ap-northeast-1.rds.amazonaws.com. 3 IN A 172.30.25.134

各インスタンスのIPに変化は無く、CNAMEの切り換えだけが行われている事が分かる。
ちなみに、興味深かったのはReader側のCNAMEのTTLが1秒でCluster側が5秒担っていた事。
昇格側はさっさと切り替わる方が障害時間が短くなるためか、slaveは複数台連なるので負荷分散の為の想定かそんなところだろうか。

Railがconnection poolingしている場合

で、本題のRailsのコネクションプーリングについて。

この辺りの記事が詳しい(むしろこれで話は終わりという感じ)。
http://blog.livedoor.jp/sonots/archives/38797925.html

マスターをAZ構成にしていた場合には、旧マスターは接続不可となるのでrailsは接続出来ないエラー共に再起動され、(設定によるが)ワーカーが再起動して新しいIPをひくので問題なかったが、
Auroraの用に、マスターがスレーブに降格する様な場合には、引き続きrailsは旧マスターに接続し続けられる為に、コネクションをプーリングし続けてしまい書き込みだけが出来ない様な状態になる。
エラーとしては以下の様なものが出力される。

Mysql2::Error: The MySQL server is running with the --read-only option so it cannot execute this statement

都度接続にする

解決策としては、コネクションプーリングをやめて都度接続にする事が手っ取り早い。以下の様なgemもあるためかなり簡単に設定出来る。
https://github.com/sonots/activerecord-refresh_connection

マスター切替以外でも

スレーブが複数台いる場合に、コネクションプーリングだとスレーブへのアクセスがかなり偏る可能性がある。
特に台数が少ないうちはかなり偏るはず。

まとめ

都度接続のコストが高くない限り、コネクションプーリングはやめたほうがいんじゃないかなと思いました。

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Sign upLogin
19
Help us understand the problem. What are the problem?