アプリ版:「スタンプのみでお礼する」機能のリリースについて

お世話になります。

MySQLの冗長化について質問です。
現在新規サービスを立ち上げるためにインフラの導入を
検討しています。
求められている要件として、
・24時間無停止(計画停止はあり)
・障害発生時のフェイルオーバー時間は10分以内
・冗長化構成(遠隔地を含んだ冗長化は行わない)
があります。

MySQLではシングルマスタレプリケーションを使用することで
参照系DBのスケールアウトは可能ですが、
更新系DBの冗長化を行うにはマルチマスタレプリケーションを
行う必要があると認識しています。
とはいえ、マルチマスタレプリケーションにて冗長化を行うと、
アプリ側での作りこみやリカバリを考えると頭の痛いことが
多いように感じています。

単一障害点となるマスタDBの冗長化を行うにはどのような
方法を使えば安価かつ可用性・拡張性を得ることが可能でしょうか。
(負荷分散には目をつぶる前提です)
※基本的には作りこみではなくソフトウェアでの解決を考えています。
 また、Oracleを視野に入れると導入コストが跳ね上がるので
 考えないものとしています。

お勧めの製品・方法があれば情報をいただけないでしょうか。
宜しくお願いします。 

A 回答 (1件)

非常によく調べられているので過去の構築実績だけで簡単に説明致します。



その後、質問をお受けする形が良いと思います。

過去に行った構築では、
マスターサーバ(更新系DBに利用する)×2台
2台をSunClusterというソフトにて(アクト/スタンバイ)冗長化構成を取りました。
フェイルオーバー時間は体感で、2分以内

さらに、スタンバイサーバにてアクト側のデータをレプリケーションする事により、
参照系DBサーバのデータは待機系サーバからレプリケーションを行うように構成しました。
それにより、スケールアウトを行うサーバが複数台増えた場合にでも、更新系サーバに
負荷が掛からないように構築致しました。

メインインスタンス() → 待機系(レプリケーション) → 参照系DB(レプリケーション)
(※参照系サーバは、孫レプリケーションとなる)

SunClusterが管理するインスタンスは親インスタンス、子インスタンスです。
更新系のどちらかのサーバで障害が発生した場合、親、子インスタンスが1台のサーバで動作致します。(※起動ポート番号を変更しておく必要がある。)

つらつらと書いているので、参考になるようなら質問してください。
    • good
    • 0

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!