Amazon Auroraでは、フェイルオーバーが発生してWriterとReaderが切り替わる場合、サーバ自体のIPアドレスは変わらず、クラスタエンドポイントおよび読み取りエンドポイントのFQDN（CNAME相当）が指すIPアドレスが入れ替わります。 また、エンドポイントが指すIPアドレスは、フェイルオーバー発生時に数回フラッピングします。 そのため、アプリケーションサーバからコネクションプーリングを使ってAmazon Auroraに接続していると、意図せずWriterからReaderに「降格」した側のサーバ（レプリカ）に再接続してしまい、更新系クエリがエラーになってしまうことがあります。 ※反対に、Readerへの接続を意図していたのに誤ってWriterに接続されてしまうことについては、ある程度までなら許容できると思いますが。 これを避けるため、コネクションプーリングをやめて都度接続に
以前、このような記事を書きました。 Amazon Auroraクラスタへの接続にコネクションプーリングを使うときのフェイルオーバー対応 このときは、オンプレTomcat 8＋MySQL 5.5環境からAWS EC2上のTomcat8＋Aurora（MySQL互換）クラスタへの移行ということで、コネクションプールにDBCP2を使いましたが、色々問題があって調整が大変でした。 今回は、これをHikariCP（2.7.6）に置き換えて、どう変わるか試してみます。 Apache DBCP2接続での問題点 一言でいえば**「とにかく遅い」**です。 特に、「プールからコネクションを取得（借用）する処理が遅い」です。 そのため、 Auroraフェイルオーバー時の再接続に時間が掛かる フェイルオーバー後のWriterインスタンスへの再接続ができるようにするために異常コネクションの除去（Eviction）
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
