私が働いているスタートアップでは、データベースのスケーリングソリューションを検討しています。（少なくとも私にとっては）MySQLクラスター、レプリケーション、およびMySQLクラスターの非同期バージョンであるMySQLクラスターレプリケーション（バージョン5.1.6から）を備えたMySQLとは多少混乱します。MySQLのマニュアルでは、クラスターに関するFAQのいくつかの違いについて説明していますが、どちらをいつ使用するかを確認するのは困難です。
これらのソリューションの違いと長所と短所をよく知っている人からのアドバイスをいただければ幸いです。それぞれをいつ使用することをお勧めしますか。
回答:
私は利用可能なオプションについてたくさん読んでいます。また、High Performance MySQL 2ndエディションも手に入れました。これは、強くお勧めします。
これは私が何とかつなぎ合わせたものです：
一般的な意味でのクラスタリングとは、外部アプリケーションからは1つのサーバーとして見える多くのサーバーに負荷を分散することです。
MySQL NDB Clusterは、同期レプリケーションと自動データパーティショニングを備えた分散型のメモリ内シェアードナッシングストレージエンジンです（すみません、High Performanceの本から文字通り借りていますが、非常にうまく配置されています）。一部のアプリケーションでは高性能のソリューションになる可能性がありますが、Webアプリケーションは一般的にうまく機能しません。
主な問題は、非常に単純なクエリ（1つのテーブルのみにアクセスする）を超えて、クラスターは通常、複数のノードでデータを検索する必要があるため、ネットワークレイテンシが忍び寄り、クエリの完了時間が大幅に遅くなることです。アプリケーションはクラスターを1台のコンピューターとして扱うため、データをフェッチするノードを指定できません。
さらに、メモリ内の要件は、多くの大規模なデータベースでは機能しません。
これはMySQLのもう1つのクラスタリングソリューションであり、MySQLサーバー上でミドルウェアとして機能します。同期レプリケーション、負荷分散、フェイルオーバーを提供します。また、リクエストが常に最新のコピーからデータを取得し、新しいデータを持つノードを自動的に選択するようにします。
私はそれについていくつかの良いことを読みました、そして全体的にそれはかなり有望に聞こえます。
フェデレーションはクラスタリングに似ているので、ここでも引っ張っています。MySQLは、フェデレーションストレージエンジンを介してフェデレーションを提供します。NDBクラスターソリューションと同様に、単純なクエリでのみ適切に機能しますが、複雑なクエリのクラスターではさらに悪化します（ネットワークの待ち時間がはるかに長いため）。
MySQLには、さまざまなサーバー上にデータベースのレプリケーションを作成する機能が組み込まれています。これは、サーバー間での負荷の分割、ホットバックアップ、テストサーバーの作成、フェイルオーバーなど、さまざまな用途に使用できます。
レプリケーションの基本的なセットアップには、主に書き込みを処理する1つのマスターサーバーと、読み取りのみを処理する1つ以上のスレーブが含まれます。より高度なバリエーションは、マスターマスター構成のバリエーションです。これにより、複数のサーバーに同時に書き込みを行うことで、書き込みをスケーリングすることもできます。
各構成には長所と短所がありますが、すべてが共有する問題の1つは、レプリケーションの遅延です。MySQLレプリケーションは非同期であるため、すべてのノードが常に最新のデータを持っているわけではありません。これには、アプリケーションがレプリケーションを認識し、レプリケーション対応のクエリを組み込んで期待どおりに機能する必要があります。一部のアプリケーションでは、これは問題にならない場合がありますが、常に最新のデータが必要な場合は、多少複雑になります。
レプリケーションでは、ノード間で負荷を分割するためにある程度の負荷分散が必要です。これは、アプリケーションコードを変更するか、専用のソフトウェアおよびハードウェアソリューションを使用するだけの簡単なものです。
シャーディングは、データベースソリューションを拡張するために一般的に使用されるアプローチです。データを小さなシャードに分割し、さまざまなサーバーノードに分散させます。これには、アプリケーションが必要な情報の場所を知る必要があるため、効率的に機能するためにデータストレージの変更を認識する必要があります。
HibernateORMの拡張機能であるHibernateShards（残念ながらJavaにあります。私はPHPを使用しています）など、データシャーディングの処理に役立つ抽象化フレームワークがあります。HiveDBは、シャードのリバランスもサポートするもう1つのソリューションです。
Sphinxは全文検索エンジンであり、テスト検索以外にも使用できます。多くのクエリでは、MySQLよりもはるかに高速で（特にグループ化と並べ替えの場合）、リモートシステムに並行してクエリを実行し、結果を集約できます。これにより、シャーディングでの使用に非常に役立ちます。
一般に、スフィンクスは、利用可能なハードウェアとインフラストラクチャをより多く取得するために、他のスケーリングソリューションとともに使用する必要があります。欠点は、スフィンクスを賢く使用するために、アプリケーションコードがスフィンクスを認識する必要があることです。
スケーリングソリューションは、それを必要とするアプリケーションのニーズによって異なります。私たちとほとんどのWebアプリケーションにとって、レプリケーション（おそらくマルチマスター）は、負荷を分散するロードバランサーを使用する方法であると私は信じています。特定の問題領域（巨大なテーブル）のシャーディングも、水平方向にスケーリングできるようにするために必須です。
また、Continuent Sequoiaを試して、アプリケーションコードへの変更が最小限で済むため、約束どおりに実行できるかどうかを確認します。
免責事項：私はMySQL Clusterを使用したことがないので、聞いたことだけを使用します。
MySQL ClusterはHA（高可用性）ソリューションです。すべてがメモリ内にあるため高速ですが、本当のセールスポイントは可用性です。単一障害点はありません。一方、レプリケーションでは、マスターがダウンした場合、実際にレプリカに切り替える必要があり、わずかなダウンタイムが発生する可能性があります。（ただし、DRBDソリューションは高可用性を備えた別の代替手段です）
クラスターでは、データベース全体がメモリに収まる必要があります。つまり、クラスター内の各マシンには、データベース全体を格納するのに十分なメモリが必要です。したがって、これは非常に大規模なデータベースでは実行可能なソリューションではありません（または、少なくとも非常に高価なソリューションです）。
HAが非常に重要でない限り（読む：おそらくそうではない）、それは価値があるよりも面倒（そしてお金）だと思います。多くの場合、レプリケーションがより良い方法です。
編集：クラスターは外部キーを許可せず、範囲スキャンは他のエンジンよりも遅いことにも言及するのを忘れました。これは、MySQLClusterの既知の制限について説明しているリンクです。
drupal.orgを管理している人々がデータベースサーバーをどのように構築したかについて、いくつかの良い議論があります。
どちらも2007年のものであるため、クラスタリングのサポートは現在より強力になっている可能性がありますが、当時はレプリケーションを選択していました。
レプリケーションを行うことのすばらしい点は、それが簡単なことです。2つのmysqlボックスを設定し、2番目のボックスのserverIDを変更してから、change mastertoコマンドを使用して2番目のボックスを最初のボックスに向けます。
これが関連するサンプルスレーブmy.cnf設定です
#
# Log names
#
log-bin=binlog
relay-log=relaylog
log-error=errors.log
#
# Log tuning
#
sync_binlog = 1
binlog_cache_size = 1M
#
# Replication rules (what are we interested in listening for...)
#
# In our replicants, we are interested in ANYTHING that isn't a permission table thing
#
replicate-ignore-db = mysql
replicate-wild-ignore-table=mysql.%
#
# Replication server ID
#
server-id = 2
したがって、各スレーブが1ずつインクリメントされたserverIDを取得することを確認してください（次のスレーブはサーバー3です）
スレーブが接続できるユーザー名とパスワードを設定してから、changemasterをMASTER_HOST = 'xxxx'に実行します。マスターをMASTER_PASSWORD = "xxxxx"に変更します。
等々。
最後に、「startslave」を実行します。
スレーブが現れ、複製を開始します。甘いね！
これは、2つの空のサーバーから開始することを前提としています。次に、データベースをマスターサーバーにダンプできます。マスターサーバーにロードすると、スレーブにもロードされます。
次のコマンドを実行して、スレーブのステータスを確認できます。
スレーブステータスを表示\ G
それを楽しんでください..すっごく簡単...
高可用性の調査を行っているときに、多くのソリューションに出くわしました。おそらく、書き込みが集中するシステムの場合、1秒あたりのトランザクション数が多いため、DRBDクラスターの方がNDBクラスターよりも優れていることがわかりました。
Mysql Replicationは、読み取りスレーブとして使用することも、ディザスタリカバリの場合に使用することもできるバックアップマシンを提供できます。
DRBDが提供するトランザクション管理のさまざまなモードを使用すると、ネットワークを介したデータのデバイスレベルのレプリケーションによって発生するパフォーマンスを低下させることができます。障害が発生した場合にトランザクションを失うことのない信頼性の高いシステムの場合は、Cモードを使用します。それ以外の場合は、Bを使用します。
http://www.techiegyan.com/?p=132でDRBDクラスターのセットアップ中に行った学習の一部をリストしようとしました。
レプリケーション専用の接続で非常にうまく機能します。つまり、drbdレプリケーション専用に両方のマシンで個別の高速インターフェイスを予約します。Heartbeatは、IPアドレス、パーティション、drbd、mysqlなどのすべてのサービスを1つずつ使用してクラスターを適切に制御できます。
DRBDのマスター-マスター構成をまだ発見していません。私がそれに成功したときに更新されます。
ありがとう。
私の見解では、ここでの混乱は私をムネシアに送り返すだけです。断片化、インデックスを処理する宣言的かつ実用的な方法、データベースレプリカの場所の透過性など
このセットアップでは、MySQLClusterとMnesiaの両方を実行します。私たちのデータはちょっと季節的なものです。したがって、しばらくすると、使用されなくなったデータの記憶喪失が解消され、MYSQLクラスターにスローされます。これにより、記憶喪失が効率的に保たれます。また、MySQLから直接データを使用するメインストリーム言語（Python、Clojureなど）で実装されたアプリケーションもあります。
一言で言えば、MySQLCluster上でmnesiaを実行します。MySQL Clusterは大規模なデータセットを処理でき、データベースは50GB以上に拡張できます。Erlang / OTPアプリケーションに電力を供給するmnesiaがあります。JavaとPHPは、交換形式としてJSONとXMLを使用して、調整されたREST（最近はThrift）APIを介してmnesiaからデータにアクセスします。
データアクセス層は、必要に応じて、Mnesiaのデータと、MySQLClusterの古い出荷データへのアクセスを抽象化しました。Mnesiaは基本的にErlang / OTPアプリケーションを強化するためにここにあります。データに夢中になったら、それをMYSQLClusterにスローします。データアクセス層は、すべてのアプリケーションに代わって、抽象化されたAPIでmnesiaとMySQLの両方のデータにアクセスできます。
私がここで言えることは、ムネシアが私たちにとって最良の選択肢であったということです。テーブルは高度に断片化され、インデックスが付けられており、クエリは非常によく実行され、データベースはトンネルを介して接続された2つの場所に複製されます。
以前は、テーブルサイズの制限により、mnesiaができるだけ多くのレコードを処理できない可能性があることを懸念していました。しかし、このステートメントは間違っていることがわかりました。適切な調整（断片化）により、当社のmnesiaデータベースは年間平均約2億5000万件のレコードを保持しています。
Erlangの複雑なデータ構造と、Mnesiaが変更せずにそれを飲み込むことができるという事実から恩恵を受けました。Erlang / OTPアプリケーションは、レガシー言語の他のすべてのアプリの中で最も効率的であり、私たちのシステムでは、すべてをErlang / OTPテクノロジーに移行することを計画しています。Erlangから、MySQL Clusterからのデータにアクセスし、サーバーに対してクエリを実行するのは非常に素晴らしいことです。実際、（Erlang）の大規模な同時実行性により、MySQLサーバーリソースを完全に使用できるErlang / OTPであると推測されます。
Mnesiaは私たちのために非常にうまく機能しており、Mnesiaはそのスリリングなパフォーマンスにより、データベースの見方を完全に変えました。SolarisサーバーのCPUコアは、ピーク時に平均約48％の使用率でビジー状態に保たれます。
mnesiaをチェックすることをお勧めします。誰が知っているか、それはあなたの配布または複製のニーズの多くに答えるかもしれません。
私はそれらを使用していませんが、ドキュメントから、最大の負荷がデータベースからの読み取りである場合は、レプリケーションが推奨されるソリューションであると言えます。
「メモリ内」の制限により、ほぼ50GbのデータにMySQL Clusterを使用できないため、DRBDとLinuxHeartbeatを使用しています。
これは、データベース/ログ/構成の同期を維持する2つ（またはそれ以上）のボックス間のRAIDアレイのようなものです（ただし、一度に「ライブ」にできるサーバーは1つだけです）。フェイルオーバーは自動で、同じIPアドレスを使用し、mysqlの再起動と同じくらい高速なので、これは私たちにとって良い解決策でした。
MySQL Clusterは奇妙な獣であり、評価するたびに、パフォーマンスが非常に悪いか、信頼性が低くなっています。
セットアップは非常に複雑です（少なくとも3つのノード、場合によってはそれ以上のノードが必要です）。また、クライアントをフェイルオーバーさせるための規定がないため、自分でフェイルオーバーする必要があります（または、プロキシとして機能するために他の何かを使用するなど）。
主キーで自動ハッシュパーティショニングを実行して書き込みをスケーリングできるため、また単一障害点がないため、非常に賢いです。
しかし、私はそれが設計された非常に特別な目的のケースにより適していると本当に思います。ほとんどの場合、パフォーマンスまたは機能のいずれかで別のデータベースエンジン（InnoDBなど）を置き換えることはできません。