MySQLのスケーリングソリューション（レプリケーション、クラスタリング）
https://stackoverflow.com/questions/189903
-
06-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
スタートアップでは、現在、データベースのスケーリングソリューションを検討しています。 MySQLクラスター、レプリケーションおよび< a href = "http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-replication.html" rel = "noreferrer"> MySQLクラスターレプリケーション（ver。5.1.6以降）、これはMySQLクラスターの非同期バージョンです。 MySQLマニュアルでは、クラスタFAQ ですが、どちらを使用するかを確認するのは困難です。
これらのソリューションと長所と短所との違いに精通している人々からのアドバイスを歓迎します。また、それぞれを使用することをお勧めします。
解決
利用可能なオプションについて、たくさん読んでいます。また、高性能MySQL 2ndエディションも手に入れました。これを強くお勧めします。
これは私がまとめたものです：
クラスタリング
一般的な意味でのクラスタリングとは、外部アプリケーションからは1つのサーバーのように見える多くのサーバーに負荷を分散することです。
MySQL NDBクラスター
MySQL NDB Clusterは、同期レプリケーションと自動データパーティショニングを備えた、分散メモリ内のシェアードナッシングストレージエンジンです（すみませんが、High Performanceの本から文字通り借りていますが、非常にうまく配置されています）。一部のアプリケーションでは高パフォーマンスのソリューションになる可能性がありますが、Webアプリケーションは一般にうまく機能しません。
主な問題は、非常に単純なクエリ（1つのテーブルのみに触れる）を超えて、クラスターは一般に複数のノードでデータを検索する必要があり、ネットワーク遅延が忍び込んでクエリの完了時間を大幅に遅らせることです。アプリケーションはクラスターを1つのコンピューターとして扱うため、どのノードからデータを取得するかを判断できません。
さらに、メモリ内の要件は多くの大規模なデータベースでは機能しません。
連続セコイア
これは、MySQLサーバーのミドルウェアとして機能するMySQLの別のクラスタリングソリューションです。同期複製、負荷分散、およびフェイルオーバーを提供します。また、リクエストが常に最新のコピーからデータを取得するようにし、最新のデータを持つノードを自動的に選択します。
いくつかの良いことを読んだことがありますが、全体的にかなり有望に聞こえます。
フェデレーション
フェデレーションはクラスタリングに似ているため、ここでも同様にタグ付けしました。 MySQLは、フェデレーションストレージエンジンを介したフェデレーションを提供します。 NDBクラスターソリューションと同様に、単純なクエリでのみ動作しますが、複雑なクエリではクラスターがさらに悪化します（ネットワークの待ち時間がはるかに長いため）。
レプリケーションと負荷分散
MySQLには、さまざまなサーバーでデータベースの複製を作成するための機能が組み込まれています。これは、サーバー間での負荷の分割、ホットバックアップ、テストサーバーの作成、フェールオーバーなど、多くの目的に使用できます。
レプリケーションの基本的なセットアップでは、1つのマスターサーバーが主に書き込みを処理し、1つ以上のスレーブが読み取りのみを処理します。より高度なバリエーションは、 master-master 構成です。これにより、書き込みを次のようにスケーリングできます。同時に複数のサーバーが書き込みを行うことにより。
各構成には長所と短所がありますが、すべてが共有する問題の1つはレプリケーションラグです。MySQLレプリケーションは非同期であるため、すべてのノードが常に最新のデータを持っているわけではありません。これには、アプリケーションがレプリケーションを認識し、期待どおりに動作するレプリケーション対応クエリを組み込む必要があります。一部のアプリケーションではこれは問題にならないかもしれませんが、常に最新のデータが必要な場合はやや複雑になります。
レプリケーションでは、ノード間で負荷を分割するための負荷分散が必要です。これは、アプリケーションコードのいくつかの変更と同じくらい簡単な場合もあれば、専用のソフトウェアおよびハードウェアソリューションを使用する場合もあります。
シャーディングとパーティショニング
シャーディングは、データベースソリューションのスケーリングによく使用されるアプローチです。データを小さな断片に分割し、それらを異なるサーバーノードに分散します。これには、アプリケーションが必要な情報の場所を知る必要があるため、アプリケーションが効率的に機能するためにデータストレージの変更を認識する必要があります。
Hibernate Shards などのデータシャーディングの処理に役立つ抽象化フレームワークがあります。 Hibernate ORMの拡張
他のヒント
免責事項：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_HOST = 'x.x.x.x'に変更します。 マスターをMASTER_PASSWORD =＆quot; xxxxx＆quot ;;に変更します。
など。
最後に、＆quot; start slave;＆quot;を実行します
スレーブが来て、複製を開始します。甘いハァッ！
これは、2台の空のサーバーで開始することを前提としています。次に、dbをマスターサーバーにダンプできます。そこにロードされると、スレーブにもロードされます。
次のコマンドを実行すると、スレーブのステータスを確認できます：
スレーブステータスの表示\ G
それを楽しんでください。.sooooeasy ...
高可用性の調査中に多くのソリューションに出会いましたが、おそらく書き込み集約型のシステムの場合、1秒あたりのトランザクション数が多いため、DRDBクラスターはNDBクラスターよりも優れていることがわかりました。
Mysql Replicationは、読み取りスレーブとして使用するか、災害復旧の場合に使用できるバックアップマシンを提供できます。
DRBDが提供するトランザクション管理のさまざまなモードを使用すると、ネットワーク上でのデバイスレベルのデータのレプリケーションによるパフォーマンスヒットを減らすことができます。障害が発生した場合にトランザクションが失われない信頼性の高いシステムの場合は、Cモードを使用します。それ以外の場合はBを選択します。
http：/で、DRBDクラスターのセットアップ中に行った学習の一部をリストしようとしました。 /www.techiegyan.com/?p=132
これは、レプリケーション専用の接続で非常にうまく機能します。つまり、drbdレプリケーションのために、両方のマシンで別々の高速インターフェースを予約します。 Heartbeatは、すべてのサービスを1つずつ、つまりIPアドレス、パーティション、drbd、mysqlでクラスターをうまく制御できます。
DRBDのマスター-マスター構成をまだ発見していません。私はその中で成功すると更新します。
ありがとう。
私の見解では、ここでの混乱は私をムネシアに送り返すだけです。断片化、宣言的および実用的なインデックス処理方法、データベースレプリカe.t.cの場所の透過性
セットアップでは、MySQL ClusterとMnesiaの両方を実行します。データは季節的なものです。そのため、しばらくしてから、使用されなくなったデータの記憶喪失を緩和し、MYSQLクラスターにスローします。これにより、健忘症が効率的になります。また、MySQLから直接データを使用するメインストリーム言語（Python、Clojure e.t.c）で実装されたアプリケーションもあります。
一言で言えば、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億5千万件のレコードを保持しています。
Erlangの複雑なデータ構造と、Mnesiaが変更せずにそれを飲み込むことができるという事実の恩恵を受けました。 Erlang / OTPアプリケーションは、レガシー言語の他のすべてのアプリの中で最も効率的であり、私たちのシステムでは、すべてをErlang / OTPテクノロジーに移行することを計画しています。 Erlangからは、MySQL Clusterのデータに見かけなくアクセスし、非常に素晴らしくサーバーにクエリを実行します。実際、Erlang / OTPは（Erlang）大規模な同時実行性のためにMySQLサーバーリソースを完全に使用できると推測しました。
Mnesiaは非常にうまく機能しました。Mnesiaは、スリリングなパフォーマンスのために、データベースの見方を完全に変更しました。 SolarisサーバーのCPUコアは、ピーク時に平均約48％の使用率でビジー状態を維持します。
mnesiaをチェックアウトすることをお勧めします。mnesiaは、ディストリビューションまたはレプリケーションのニーズの多くに答えることができることを知っています。
これらを使用したことはありませんが、ドキュメントからは、最大の負荷がデータベースからの読み取りである場合、レプリケーションが好ましいソリューションであると言えます。
「メモリ内」制限により、ほぼ50GbのデータにMySQLクラスターを使用できないため、 DRBDとlinux Heartbeat を使用しています。
これは、データベース/ログ/構成の同期を保つ2つ（またはそれ以上）のボックス間のRAID配列のようなものです（ただし、一度に「ライブ」にできるのは1つのサーバーのみです）。フェイルオーバーは自動的に行われ、同じIPアドレスを使用し、mysqlの再起動と同じくらい速いため、これは私たちにとって良い解決策です。
MySQLクラスターは奇妙な怪物であり、評価するたびにパフォーマンスが非常に悪いか、信頼性が低くなります。
セットアップは恐ろしく複雑です（少なくとも3つのノードが必要です。おそらくそれ以上です）。また、クライアントにフェイルオーバーさせるためのプロビジョニングがないため、自分でそれを行う必要があります（または、プロキシとして機能するために他の何かを使用するなど）。
書き込みをスケーリングできる主キーで自動ハッシュパーティション分割を行い、単一障害点がないため、非常に賢明です。
しかし、私は本当にそれが設計された非常に特別な目的の場合により適していると思います。ほとんどの場合、パフォーマンスまたは機能のいずれかで別のデータベースエンジン（InnoDBなど）を置き換えることはできません。
