tl;dr RailsのコネクションプールとAmazon Auroraのフェイルオーバーの仕組みは相性が悪く、フェイルオーバー時に致命的な問題が発生する 解決方法の1つは、コネクションプールを使わないこと ただし、都度接続だと接続コストがかかる New Relicなどを使ってる場合は、自分の実装以外で使ってるコネクションまで都度接続になってしまう 別スレッドでDB操作を行っている場合、処理中であってもそのスレッドのコネクションまで切断されてしまう（Railsのコネクション破棄がプロセス単位のため） コネクションプールを活かしたままこの問題を解決できたので、その方法をご紹介します。ちなみにRails 4.2の話。 RailsとAmazon Aurora利用時のフェイルオーバー問題とは 詳しくはこちら qiita.com 問題が発生する状況をまとめると以下の通りです。 Amazon Auror
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
以前投稿したbgwokerで超簡易クラスタ管理を進化させたpg_keeperについて投稿。 コンセプト このツールのコンセプトは「PostgreSQLの自動フェイルオーバーを簡単に設定する」です。 Pacemaker/corosyncやrepmgrを使えばより細かく、柔軟に設定することが出来ますが、その一方設定が面倒だったり、多くのケースではそこまで柔軟な設定は必要ないと思ったので、「マスタ、スレーブ2台構成でもっと簡単に可用性を向上させたい」と思い作りました。 監視プロセスはPostgreSQLのプロセスの一つとして動作するので、高機能なクラスタリングミドルウェアによくある監視プロセス自体の起動・停止・監視等の作業は発生しません。 ただし、pg_keeperが対応しているのはマスタ1台、スタンバイ1台で同期レプリケーションを使用した場合のみです。 スタンバイを2台以上使用するケースには対
こんにちは。Lorentzcaです。3月ですがまだまだ寒いのでなかなか釣りに行けずテンションさげぽよです！ ↑↑ この度DBサーバー(物理マシン、MySQL)の引っ越しを行いました。 そのついでに、冗長化の仕組みをmhaとconsulを使った方法に変えたので紹介します。 はじめに まずは簡単に引っ越し前と引っ越し後の構成を比べてみます。 引っ越し前は以下の様な構成でした。 サーバー台数: 2台 MySQLフェイルオーバーの仕組み: 自作シェルスクリプト アプリの参照先を切り替える仕組み: keepalivedでvipを張り替えることで実現 引っ越し後は以下の様な構成になりました。 サーバー台数: 3台 MySQLフェイルオーバーの仕組み: mha アプリの参照先を切り替える仕組み: consulのdns機能を使って実現 なぜこのような構成にしたのか、話していきます。 引っ越し前に持っていた
1. はじめに この記事はMySQL Casual Advent Calendar 2015の22日目のエントリです。 先日、MySQL Casual Talksという勉強会で登壇してきました。その時の内容をまとめておきたいと思います。 MySQLデータベースサーバに障害が起きた時、サービスを続けるには幾つかの方法があります。障害発生時にSlaveサーバーを手作業でMasterに昇格させる方法、MySQL Utilitiesに含まれるmysqlfailoverというユーティリティーを利用する方法などです。 今回、Keepalivedというソフトウェアと、MySQLの双方向レプリケーションを使って、ほぼ無停止でフェイルオーバーする構成を試してみたので、それについてまとめておきたいと思います。 2. システム構成 db1、db2という二つのサーバで、それぞれmysqldとkeepalivedを
New Solution – Clickstream Analytics on AWS for Mobile and Web Applications Starting today, you can deploy on your AWS account an end-to-end solution to capture, ingest, store, analyze, and visualize your customers’ clickstreams inside your web and mobile applications (both for Android and iOS). The solution is built on top of standard AWS services. This new solution Clickstream Analytics on AWS a
先日(6/22/14)、6月なのにどういう分けか早めに開催されたJuly Tech Festa 2014でConsulについて発表してきた。そのユースケースの一つとしてMySQL failoverをちょっとだけ紹介したので、ここに詳しく書いておく。 MHA MySQLレプリケーションの障害時にフェールオーバーしたい場合、MHAを使うの結構ポピュラー（日本では）だと思います。MHAは最新binlogの適用、Slaveの昇格とレプリケーションの張替えまではやってくれますが、実際のフェールオーバーの部分はユーザに委ねられていて、master_ip_failover_scriptのテンプレートをカスタマイズするか独自実装する必要があり、一般的な実現方法としてはカタログデータベースの更新かVirtual IPの切替等があります。 Virtual IPだと居残りセッションの問題や切替の保証難しかったり
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く