私が働いているスタートアップでは、現在、データベースのスケーリング ソリューションを検討しています。MySQLクラスター、レプリケーション、およびMySQLクラスターの非同期バージョンであるMySQLクラスターレプリケーション（バージョン5.1.6以降）を備えたMySQLでは、（少なくとも私にとっては）やや混乱します。MySQL のマニュアルでは、クラスターの FAQでいくつかの違いについて説明していますが、どちらをいつ使用するかを確認するのは困難です。
これらのソリューションの違い、長所と短所、それぞれをいつ使用することをお勧めするかについて詳しい方からのアドバイスをいただければ幸いです。
私は利用可能なオプションについてたくさん読んでいます。また、High Performance MySQL 2ndエディションも手に入れました。これは、強くお勧めします。
これは私が何とかつなぎ合わせたものです：
一般的な意味でのクラスタリングとは、外部アプリケーションに1つのサーバーとして表示される多くのサーバーに負荷を分散することです。
MySQL NDB Clusterは、同期レプリケーションと自動データパーティショニングを備えた分散型のメモリ内シェアードナッシングストレージエンジンです（すみません、ハイパフォーマンスの本から文字通り借りていますが、非常にうまく配置されています）。一部のアプリケーションでは高性能のソリューションになる可能性がありますが、Webアプリケーションは一般的にうまく機能しません。
主な問題は、非常に単純なクエリ（1つのテーブルのみにアクセスする）を超えて、クラスターは通常、複数のノードでデータを検索する必要があるため、ネットワークレイテンシーが忍び寄り、クエリの完了時間が大幅に遅くなることです。アプリケーションはクラスターを1台のコンピューターとして扱うため、データをフェッチするノードをアプリケーションに指示することはできません。
さらに、メモリ内の要件は、多くの大規模なデータベースでは機能しません。
これはMySQLの別のクラスタリングソリューションであり、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 が非常に重要でない限り (読んでください: おそらくそうではないでしょう)、それは価値があるよりも手間 (そしてお金) がかかると思います。多くの場合、レプリケーションはより良い方法です。
編集:クラスターは外部キーを許可しないこと、および範囲スキャンが他のエンジンよりも遅いことも言及するのを忘れていました。これは、 MySQL Cluster の既知の制限について説明しているリンクです。
drupal.org を維持している人々がデータベース サーバーをどのように構築したかについて、いくつかの良い議論があります。
どちらも 2007 年のものなので、現在はクラスタリングのサポートが強化されている可能性がありますが、当時は複製を選択していました。
レプリケーションを行うことのすばらしい点は、それが簡単なことです。2つのmysqlボックスを設定し、2番目のボックスのserverIDを変更してから、changemastertoコマンドを使用して2番目のボックスを最初のボックスに向けます。
これが関連するサンプルスレーブmy.cnfconfigです
#
# 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
それを楽しんでください..すっごく簡単...
私の見解では、ここでの混乱は私を Mnesia に送り返すだけです。フラグメンテーション、インデックスを処理する宣言的かつ実用的な方法、データベース レプリカの場所の透過性など
私たちのセットアップでは、MySQL Cluster と Mnesia の両方を実行しています。私たちのデータは季節的なものです。しばらくすると、使用されなくなったデータの記憶喪失が解消され、MYSQL クラスターにスローされます。これにより、記憶喪失が効率的になります。また、MySQL から直接データを使用するメイン ストリーム言語 (Python、Clojure など) で実装されたアプリケーションもあります。
簡単に言えば、MySQL Cluster の上で mnesia を実行します。MySQL Cluster は大規模なデータ セットを処理でき、データベースは 50GB 以上まで拡張できます。Erlang/OTPアプリケーションを強化する mnesia があります。JavaとPHPは、JSON と XML を交換フォーマットとして使用して、調整されたREST (最近はThrift ) API を介して mnesia からデータにアクセスします。
データ アクセス層は、必要に応じて Mnesia のデータと MySQL Cluster の古い出荷データへのアクセスを抽象化しています。Mnesia は基本的に、Erlang/OTP アプリケーションを強化するためにここに存在します。データで一杯になると、それを MYSQL Cluster に投入します。データ アクセス層は、すべてのアプリケーションに代わって、抽象化された API で mnesia と MySQL の両方のデータにアクセスできます。
ここで言えることは、Mnesia が私たちにとって最良の選択肢だったということです。テーブルは高度に断片化およびインデックス化されており、クエリは非常にうまく機能し、データベースはトンネル経由で接続された 2 つの場所に複製されています。
以前は、テーブル サイズの制限により、mnesia ができるだけ多くのレコードを処理できないのではないかと懸念していました。しかし、このステートメントは間違っていることがわかりました。適切なチューニング (断片化) により、当社の mnesia データベースは、年間平均約 2 億 5000 万のレコードを保持しています。
Erlang の複雑なデータ構造と、Mnesia がそれを変更せずに飲み込むことができるという事実から恩恵を受けています。Erlang/OTP アプリケーションは、レガシー言語の他のすべてのアプリの中で最も効率的であり、私たちのシステムでは、すべてを Erlang/OTP テクノロジに移行することを計画しています。Erlang から、MySQL Cluster のデータにシームレスにアクセスし、そのサーバーに対してクエリを非常に素晴らしく実行します。実際、Erlang/OTP は (Erlang) の大量の同時実行性により、MySQL サーバー リソースを完全に使用できると推測しました。
Mnesia は非常にうまく機能しています。Mnesia は、そのスリリングなパフォーマンスにより、データベースに対する見方を完全に変えました。Solaris サーバーの CPU コアは、ピーク時に平均約 48% の使用率で使用されています。
mnesia をチェックすることをお勧めします。それは、ディストリビューションまたはレプリケーションのニーズの多くに答えてくれるかもしれません。
高可用性の調査を行っているときに、多くのソリューションに出くわしましたが、おそらく私たちの場合はより書き込み集中型のシステムでしたが、1 秒あたりのトランザクション数が多いため、DRBD クラスターが NDB クラスターよりも優れていることがわかりました。
Mysql レプリケーションは、読み取りスレーブとして使用するか、災害復旧の場合に使用できるバックアップ マシンを提供できます。
DRBD が提供するトランザクション管理のさまざまなモードを使用すると、ネットワークを介したデバイス レベルのデータ レプリケーションによるパフォーマンスの低下を抑えることができます。障害が発生した場合にトランザクションを失うことのない信頼できるシステムの場合は、C モードを使用し、それ以外の場合は B を使用します。
http://www.techiegyan.com/?p=132で DRBD クラスターをセットアップする際に学んだことをいくつか挙げてみました。
レプリケーション専用の接続で非常にうまく機能します。つまり、drbd レプリケーションのためだけに両方のマシンで個別の高速インターフェイスを予約します。Heartbeat は、IP アドレス、パーティション、drbd、および mysql など、すべてのサービスを 1 つずつ使用してクラスタを適切に制御できます。
DRBDのMaster-Master構成はまだ発見していません。成功したら更新します。
ありがとう。
私はそれらを使用していませんが、ドキュメントから、最大の負荷がデータベースからの読み取りである場合は、レプリケーションが推奨されるソリューションであると言えます。
「メモリ内」の制限により、約 50Gb のデータに MySQL クラスターを使用できないため、DRBD と Linux Heartbeatを使用しています。
これは、データベース/ログ/構成の同期を維持する 2 つ (またはそれ以上) のボックス間の RAID アレイのようなものです (ただし、一度に「ライブ」にできるサーバーは 1 つだけです)。フェールオーバーは自動で、同じ IP アドレスを使用し、mysql の再起動と同じくらい迅速であるため、これは私たちにとって良い解決策です。
MySQL クラスターは奇妙な野獣であり、評価するたびに、パフォーマンスが非常に悪いか、信頼性が低いかのいずれかでした。
セットアップは非常に複雑です (少なくとも 3 つのノード、場合によってはそれ以上のノードが必要です)。また、クライアントをフェイルオーバーさせるための規定がないため、自分で行う必要があります (または、プロキシとして機能する他のものを使用するなど)。
これは、主キーで自動ハッシュ パーティショニングを行い、書き込みのスケーリングを可能にし、単一障害点がないため、非常に賢いです。
しかし、それが設計された非常に特別な目的のケースにより適していると本当に思います. ほとんどの場合、パフォーマンスまたは機能のいずれにおいても、別のデータベース エンジン (InnoDB など) を置き換えることはできません。