MySQLの負荷分散
MySQLインフラストラクチャの負荷を分散する方法を検討していますが、自分に合った答えが見つからないようです... :)
だから、私はすべてを処理する1つの大きくて太ったサーバーを持っています。多くのDB、多くの読み取り、多くの書き込みなど。それはかなりうまく処理しますが、単一障害点です。
読み取りをリダイレクトするためにいくつかのスレーブを設定しましたが、2つの問題に直面しました。読み取りと書き込みを分割するためにすべてのプログラムを再構築するのに多大な労力がかかります。また、スレーブが遅れることがあり、アプリケーションに非常に興味深いアーティファクトが発生します。
スレーブが遅れる問題：多くのデータベースが混在しているため、データマイニング側で実行される10〜20分の重いクエリと、時間のかからないアトミッククエリの両方があります。ただし、スレーブは一度に1つのクエリを実行するため、すべてのアトミッククエリは重いクエリが終了するまで待機する必要があります。
これらの2つの問題を解決するために、私はプロキシのようなものを考えていました。
- 読み取り/書き込みを自動的に分割
- 単一のエントリーポイントとして機能し、データベースを必要とする適切なサーバーにリクエストをリダイレクトします（たとえば、バックエンドでdb1とdb2を分離しますが、アプリケーションに対して透過的にします）
- スレーブラグに注意し、スレーブラグが発生したときにマスターに読み取りを送信します（これがデータベースごとに実行できる場合は理想的ですが、サーバー全体でもかなり素晴らしいでしょう）
- 適格なすべてのスレーブ間の負荷分散読み取り（単純なラウンドロビンまたはLAの監視による）
まだ残っているが、私が検討したい問題の1つは、フェイルオーバーです。マスターが失敗した場合-スレーブがマスターの責任を引き受け、マスターがバックアップされた場合-それはスレーブになります。
RTFMまたはこのテーマに関するケーススタディ）へのポインタは大歓迎です=）
編集：グーグルでさらにいくつか、そしてタングステンエンタープライズに加えて-dbShardsとSchoonerを見つけました。それを深く調べている間、誰かがこれらのソリューションの経験を持っていますか？フィードバックはありますか？
チェックアウト Tungsten Enterprise
MySQL-MMMは推奨されるソリューションではありません。参照： http://www.xaprb.com/blog/2011/05/04/whats-wrong-with-mmm/ 元の作者の1人でさえコメントに同意しました。
乾杯
編集：おっと、2番目のリンクは最初のリンクと同じでした。修正済み
レプリケーションの遅延に対処するために、スレーブのプライマリストレージとしてSSDを実装しました。書き込み時間が速いため、スレーブでのレプリケーションがシングルスレッド操作であるにもかかわらず、スレーブデータベースが維持されます。
アプリケーションデータベースとして機能する2台のサーバーと、データマイニング層として機能する別のサーバー（または2台）はどうでしょうか。 2つの「アプリケーション」データベースは、重いクエリを処理していないため、（あまりにも）遅れることはありません。 mysql-mmm をセットアップしてフェイルオーバーを処理することもできます。次に、ロードバランサーでセットアップしたMysql VIPをアプリケーションにポイントできます。このVIPには2つのMMMIPがあります。しかしMMMは「ねえ、ボックス2はかなり遅れています。追いつくことができるように、そのIPをボックス1に移動します。」
次に、2つの異なるクエリタイプを処理するデータベースの2つの層があります。これらのマシンのキャッシュは、クエリタイプに合わせて最適化されます（理論上）。
Fusion-IOカードまたはViridentTachIOnも調べてください。それはたくさんのハードウェアを追加することなく問題を解決するかもしれません。