MySQLのスケーリングソリューション（レプリケーション、クラスタリング）
startup で作業中です。現在、データベースのスケーリングソリューションを検討しています。 MySQL cluster 、 replication 、および MySQL cluster replication （バージョン5.1以降） .6）、これはMySQLクラスターの非同期バージョンです。 MySQLマニュアルでは、 cluster FAQ の違いの一部について説明していますが、どちらを使用するかを確認するのは困難です。
これらのソリューションと長所と短所との違いに精通している人々からのアドバイスを歓迎します。また、それぞれを使用することをお勧めします。
私は利用可能なオプションについて多くの読書をしてきました。また、高性能MySQL 2ndエディションも手に入れました。これを強くお勧めします。
これは私が一緒につなぎ合わせたものです：
クラスタリング
一般的な意味でのクラスタリングとは、外部アプリケーションからは1つのサーバーのように見える多くのサーバーに負荷を分散することです。
MySQL NDBクラスター
MySQL NDB Clusterは、同期レプリケーションと自動データパーティショニングを備えた分散インメモリシェアードナッシングストレージエンジンです（すみませんが、High Performanceの本から文字通り借りていますが、非常にうまく配置されています）。一部のアプリケーションでは高パフォーマンスのソリューションになる可能性がありますが、Webアプリケーションは一般にうまく機能しません。
主な問題は、非常に単純なクエリ（1つのテーブルのみに触れる）を超えて、クラスターは一般に複数のノードでデータを検索する必要があるため、ネットワーク遅延が忍び込んでクエリの完了時間を大幅に遅らせることです。アプリケーションはクラスターを1つのコンピューターとして扱うため、どのノードからデータを取得するかを判断できません。
さらに、メモリ内の要件は、多くの大規模なデータベースでは機能しません。
継続的なセコイア
これは、MySQLサーバーのミドルウェアとして機能する、MySQLの別のクラスタリングソリューションです。同期複製、負荷分散、およびフェイルオーバーを提供します。また、リクエストが常に最新のコピーからデータを取得するようにし、最新のデータを持つノードを自動的に選択します。
私はいくつかの good things を読みましたが、全体的にはかなり有望に聞こえます。
フェデレーション
フェデレーションはクラスタリングに似ているため、ここでも同様にタグ付けしました。 MySQLは、フェデレーションストレージエンジンを介したフェデレーションを提供します。 NDBクラスターソリューションと同様に、単純なクエリでのみ機能しますが、複雑なクエリではクラスターがさらに悪化します（ネットワークレイテンシがはるかに高いため）。
複製と負荷分散
MySQLには、さまざまなサーバーでデータベースの複製を作成するための機能が組み込まれています。これは、サーバー間での負荷の分割、ホットバックアップ、テストサーバーの作成、フェールオーバーなど、多くの目的に使用できます。
レプリケーションの基本的なセットアップには、主に書き込みを処理する1つのマスターサーバーと、読み取りのみを処理する1つ以上のスレーブが含まれます。より高度なバリエーションは、 master-master 構成のバリエーションです。これにより、複数のサーバーが同時に書き込みを行うことにより、書き込みをスケーリングすることもできます。
それぞれの構成には長所と短所がありますが、それらが共有する問題の1つはレプリケーションラグです。MySQLレプリケーションは非同期であるため、すべてのノードが常に最新のデータを持つわけではありません。これには、アプリケーションがレプリケーションを認識し、レプリケーション対応クエリを組み込んで期待どおりに動作することが必要です。一部のアプリケーションではこれは問題にならないかもしれませんが、常に最新のデータが必要な場合は、やや複雑になります。
レプリケーションでは、ノード間で負荷を分割するための負荷分散が必要です。これは、アプリケーションコードの一部の変更と同じくらい簡単な場合もあれば、専用のソフトウェアおよびハードウェアソリューションを使用する場合もあります。
シャーディングとパーティショニング
シャーディングは、データベースソリューションのスケーリングによく使用されるアプローチです。データを小さな断片に分割し、それらを異なるサーバーノードに分散します。このため、アプリケーションは、必要な情報の場所を知る必要があるため、効率的に機能するためにデータストレージの変更を認識する必要があります。
Hibernate Shards 、Hibernate ORMの拡張機能（残念ながらJavaにあります。私はPHPを使用しています）など、データのシャーディングの処理に役立つ抽象化フレームワークがあります。 HiveDB は、シャードのリバランスもサポートする別のソリューションです。
その他
スフィンクス
Sphinx は全文検索エンジンであり、テスト検索以外にも使用できます。多くのクエリでは、MySQLよりもはるかに高速で（特にグループ化と並べ替えの場合）、リモートシステムに並列にクエリを実行して結果を集計できるため、シャーディングでの使用に非常に役立ちます。
一般に、スフィンクスは他のスケーリングソリューションと一緒に使用して、利用可能なハードウェアとインフラストラクチャをさらに取得する必要があります。欠点は、スフィンクスを賢く使用するためにアプリケーションコードが必要であることです。
概要
スケーリングソリューションは、それを必要とするアプリケーションのニーズによって異なります。私たちとほとんどのWebアプリケーションにとって、レプリケーション（おそらくマルチマスター）は、ロードバランサーが負荷を分散する方法であると考えています。特定の問題領域（巨大なテーブル）のシャーディングも、水平方向にスケーリングできるようにするために不可欠です。
また、Continentent Sequoiaにショットを提供し、アプリケーションコードへの変更が最小限で済むため、約束どおりに機能するかどうかを確認します。
免責事項：私はMySQL Clusterを使用したことがないので、聞いたことから始めただけです。
MySQL ClusterはHA（高可用性）ソリューションです。それはすべてメモリ内にあるため高速ですが、本当のセールスポイントは可用性です。単一障害点はありません。一方、レプリケーションでは、マスターがダウンした場合、実際にレプリカに切り替える必要があり、わずかなダウンタイムが発生する場合があります。 （ただし、DRBDソリューションは高可用性を備えた別の選択肢です）
クラスタでは、データベース全体がメモリに収まる必要があります。つまり、クラスター内の各マシンには、データベース全体を格納するのに十分なメモリが必要です。そのため、これは非常に大規模なデータベースに適したソリューションではありません（少なくとも、非常に高価なソリューションです）。
HAが非常に重要でない限り（おそらく読む必要はありません）、価値があるよりも手間（およびお金）が大きいと思います。多くの場合、複製がより良い方法です。
編集：また、クラスターが外部キーを許可せず、範囲スキャンが他のエンジンよりも遅いことも言及し忘れました。 MySQL Clusterの既知の制限 について説明しているリンクを次に示します。
Drupal.orgを管理している人々がどのようにデータベースサーバーを構築したかについて、いくつかの良い議論があります。
どちらも2007年のものであるため、現在はクラスタリングのサポートが強化されている可能性がありますが、当時はレプリケーションを選択していました。
レプリケーションを行うことの素晴らしい点は、簡単だということです。 2つのmysqlボックスをセットアップし、2番目のボックスのserverIDを変更してから、change master toコマンドを使用して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です）
スレーブが接続できるユーザー名とパスワードを設定し、次にmasterをMASTER_Host = 'x.x.x.x'に変更して実行します。マスターをMASTER_PASSWORD = "xxxxx"に変更します。
等々。
最後に、「スレーブを開始」を実行します。
スレーブが来て、複製を開始します。甘いハァッ！
これは、2つの空のサーバーで開始することを前提としています。次に、dbをマスターサーバーにダンプできます。そこにロードされると、スレーブにもロードされます。
以下を実行して、スレーブの状態を確認できます。
スレーブの状態を表示する\ G
それを楽しんでください。
高可用性の調査中に多くのソリューションに遭遇しましたが、おそらく書き込み集中型のシステムの場合は、1秒あたりのトランザクション数が多いため、DRBDクラスターがNDBクラスターよりも優れていることがわかりました。
Mysqlレプリケーションは、読み取りスレーブとして使用するか、災害復旧の場合に使用できるバックアップマシンを提供できます。
DRBDが提供するトランザクション管理のさまざまなモードを使用すると、ネットワークを介したデータのデバイスレベルのレプリケーションによるパフォーマンスヒットを減らすことができます。障害が発生した場合にトランザクションを失わない信頼性の高いシステムの場合は、Cモードを使用し、そうでない場合はBに進みます.
http://www.techiegyan.com/?p=132 でDRBDクラスターのセットアップ中に行った学習の一部をリストしようとしました
レプリケーション専用の接続で非常にうまく機能します。つまり、drbdレプリケーションのために両方のマシンで別々の高速インターフェースを予約します。 Heartbeatは、IPアドレス、パーティション、drbd、mysqlなど、すべてのサービスを1つずつ使用してクラスターを適切に制御できます。
私はまだDRBDのマスター-マスター構成を発見していません。私はその中で成功すると更新します。
ありがとう。
私の見解では、ここでの混乱は私をムネシアに送り返すだけです。断片化、宣言的かつ実用的なインデックス処理方法、データベースレプリカの場所の透過性e.t.c
このセットアップでは、MySQL ClusterとMnesiaの両方を実行します。データは季節的なものです。そのため、しばらくしてから、使用されなくなったデータの記憶喪失を緩和し、MYSQLクラスターにスローします。これにより、健忘症が効率的になります。また、MySQLから直接データを使用するメインストリーム言語（Python、Clojure e.t.c）で実装されたアプリケーションもあります。
簡単に言うと、MySQL Clusterの上でmnesiaを実行します。 MySQL Clusterは大きなデータセットを処理でき、データベースは50GB以上に成長できます。私たちは動力を与えるmnesiaを持っています アーラン/ OTP アプリケーション。 Java そして PHP 調整された上でmnesiaのデータにアクセスする REST （最近 Rif約）JSONおよびXMLを交換フォーマットとして使用するAPI。
データアクセス層は、必要に応じて、MnesiaのデータおよびMySQL Clusterの古い出荷データへのアクセスを抽象化します。 Mnesiaは、基本的にErlang/OTPアプリケーションを強化するためのものであり、データに夢中になったら、それをMYSQL Clusterに投入します。データアクセス層は、すべてのアプリケーションに代わって抽象化されたAPIでmnesiaとMySQLの両方のデータにアクセスできます。
ここで言えることは、Mnesiaが私たちにとって最良の選択肢であったということです。テーブルは非常に断片化され、インデックスが付けられ、クエリは非常によく実行され、データベースは2つの場所に複製され、トンネルで接続されます。
以前、テーブルサイズの制限により、mnesiaができるだけ多くのレコードを処理できない可能性があることを懸念していました。しかし、この記述は間違っていることがわかりました。優れたチューニング（断片化）により、当社のmnesiaデータベースは、年間平均約2億5千万件のレコードを保持しています。
Erlangの複雑なデータ構造と、Mnesiaが変更せずにそれを飲み込むことができるという事実の恩恵を受けました。 Erlang/OTPアプリケーションは、レガシー言語の他のすべてのアプリの中で最も効率的であり、当社のシステムでは、すべてをErlang/OTPテクノロジーに移行することを計画しています。 Erlangから、MySQL Clusterのデータに見かけなくアクセスし、そのサーバーに対して非常に素晴らしくクエリを実行します。実際、（Erlang）大規模な同時実行性のために、MySQLサーバーリソースを完全に使用できるErlang/OTPを推測しました。
Mnesiaは私たちにとって非常にうまく機能しました。Mnesiaはそのスリリングなパフォーマンスのために、データベースの見方を完全に変えました。 SolarisサーバーのCPUコアは、ピーク時に平均で約48％の使用率でビジー状態を維持します。
Mnesiaをチェックアウトすることをお勧めします。mnesiaは、ディストリビューションまたは複製のニーズの多くに答えることができることを知っています。
私はそれらを使用していませんが、ドキュメントから、最大の負荷がデータベースからの読み取りである場合、レプリケーションが好ましいソリューションであると言います。
MySQLクラスターは奇妙な怪物であり、評価するたびにパフォーマンスが非常に悪いか、信頼性が低くなります。
設定するのは恐ろしく複雑です（少なくとも3つのノードが必要です。おそらくそれ以上です）。また、クライアントにフェイルオーバーさせるためのプロビジョニングがないため、それを自分で行う必要があります（または、プロキシとして機能するために他の何かを使用するなど）。
これは、書き込みをスケーリングできる主キーで自動ハッシュパーティション分割を行うため、また単一障害点がないため、非常に巧妙です。
しかし、私はそれが設計された非常に特別な目的の場合により適していると本当に思います。ほとんどの場合、パフォーマンスまたは機能のいずれかで別のデータベースエンジン（InnoDBなど）を置き換えることはできません。
「メモリ内」の制限により、ほぼ50GbのデータにMySQLクラスターを使用できないため、DRBDとlinux Heartbeatを使用しています。
これは、2つ（またはそれ以上）のボックス間のRAID配列のようなもので、データベース/ログ/構成の同期を維持します（ただし、一度に「ライブ」にできるサーバーは1つだけです）。フェイルオーバーは自動で、同じIPアドレスを使用し、mysqlの再起動と同じくらい速いので、これは私たちにとって良い解決策です。