konbuizm 様

平岡です。
コメントありがとうございます。

MySQL の冗長化について、頂きました情報を元に実際に評価を
行い、どれが良いのかを決定しようと思います。

From: konbuizm <konbuizm@xxxxxxxxxx>
Subject: [mysql 15141] Re: MySQL の冗長化方針について
Date: Mon, 11 Jan 2010 06:56:35 +0900

> MySQL に詳しくない身で恐縮ですがコメントします。
> 引用順序を一部変更しています。
> 
> 2010/1/5 Seiichirou Hiraoka <flathill@xxxxxxxxxx>:
> > 現在 MySQL を 2 台のサーバに導入して、運用系と待機系として
> > 動作させて、運用系に障害が発生した際や停止が必要な場合は
> > IP アドレスを待機系と付け替えることで運用しています。
> >
> >  Server1:MySQL (運用系)          Server2:MySQL (待機系)
> >            ^
> >            |
> >       参照・更新
> >
> > このシステムを今後以下のように改善したいと思います。
> >
> >  - 負荷分散
> >    応答速度向上のため、参照要求を 2 台のサーバに分散したい。
> >    更新要求は通常片方のサーバのみで処理して良いが、サーバが
> >    停止した際は別のサーバで代行したい。
> >  - 同期
> >    2 台のサーバをレプリケーションにより自動的に同期したい。
> >  - 冗長化
> >    運用系から待機系に切り替える必要が無いようにしたい。
> >  - 障害・停止時対応
> >    障害や停止が発生した際に、出来る限り容易に通常状態に
> >    復旧させたい。
> >  - アプリケーションの対応
> >    上記の要件をアプリケーション側の対応無しで実現したい。
> >
> > この要件を実現するための方法としては、MySQL Cluster を使う
> > 必要があるのか、もしくはレプリケーションが良いか等、皆様の
> > 御経験からアドバイスを頂けますと幸甚です。
> 
> かなり想像を含めての回答ですが、ご希望を満たすのに、MySQL Cluster
> は必須ではありません。レプリケーションがベストとは言いきれませんがご希望の一部を実現できそうです。
> 
> >  - 負荷分散
> >    応答速度向上のため、参照要求を 2 台のサーバに分散したい。
> >    更新要求は通常片方のサーバのみで処理して良いが、サーバが
> >    停止した際は別のサーバで代行したい。
> 
> MySQL Community Server や MySQL Enterprise Server
> にコネクションの負荷分散機能はありません。アプリケーションで作り込むか、負荷分散を行う何かを RDBMS
> とアプリケーション間に作り込むことが必要です。
> 
> サーバが停止した際は別のサーバで代行するには、負荷分散の仕組みにそれなりの作り込みが必要です。

了解しました。Heartbeat による切り替えや負荷分散装置等による切り替え
が必要となりますね。

> ご存知かと思いますが、負荷分散が応答速度を向上させるかは疑問です。負荷分散で副次的に応答速度が速くなるかもしれませんが、負荷分散はあくまでも負荷を分散させるものでしかありません。ですので「応答速度向上のため、参照要求を
> 2 台のサーバに分散したい。」は目的と手段がマッチしているとは言い切れません。必要なステップが欠落してます。何が遅くしているかを考えるべきでしょう。

はい。今回のケースにおいても、遅い原因の切り分けを行う予定です。
Web サーバが遅いのか、DB が遅いのか、その他要因があるのかを
切り分けないことには、負荷分散の必要があるのかどうかも不明
ですね。

> >  - 同期
> >    2 台のサーバをレプリケーションにより自動的に同期したい。
> 
> レプリケーションを設定すればできます。
> 
> >  - 冗長化
> >    運用系から待機系に切り替える必要が無いようにしたい。
> 
> 正直、何を伝えたいのかわかりません。「今後、冗長化は不要にしたい」と主張したいのか「今後、待機系を廃止して、何か別のもので冗長化を図りたい」と主張したいのか、あるいは別の何かなのか、どちらでしょう。加えて、「運用系」は文脈からある程度の推測ができそうなのですが、「待機系」の意味がわからないことも、この文の意図がわからない理由の一つです。

確かに意味不明ですね。
今回ケースでは、(2 台の DB サーバを何らかの方法で同期するように
して、片側が停止した際にもう片側に(出来れば)自動的に切り替わる
ようにしたい、という事です。とはいえ、これは上記のように MySQL
自体の機能としては持っていませんので、何らかの方法で切り替える
必要がありますね。

> そもそも「冗長」について理解されているでしょうか。冗長とは、本来必要ない物を用意することで、例えば N 個必要な物にたいして N+1
> 個以上のものを用意しておくことです。「切り替える必要が無いようにしたい」は冗長化されたサーバをどう利用するかを言っているのであって、冗長化そのものについて述べていません。
> 
> >  - 障害・停止時対応
> >    障害や停止が発生した際に、出来る限り容易に通常状態に
> >    復旧させたい。
> 
> 様々な要因に依存しそうです。
> 予算、
> 要件(アプリケーション要件、データ復旧要件、など)、
> 運用者のITスキル、
> システム稼働時間／停止時間、
> システムの構成（RDBMSサーバ構成、各テーブルのストレージエンジン、ファイルシステム等のOS構成、ハードウェア構成など）、
> 他。

了解しました。もっと情報収集や検証を行います。

> 
> >  - アプリケーションの対応
> >    上記の要件をアプリケーション側の対応無しで実現したい。
> 
> アプリケーション側で対応しないなら、アプリケーション側での負荷分散の作り込みは難しいでしょう。接続先ホスト名の変更も許されないでしょうから作業も面倒そうですね。負荷分散の仕組みとしては
> MySQL Proxy (alpha しかないのが残念)やその他の負荷分散ソフトを探すといいかもしれません。

了解しました。
コメントを頂きありがとうございます。

現時点では理解不足のようですので、実際に検証を行い、理解を
深めようと思います。

この度はどうもありがとうございました。

- flathill