マスター-スレーブ-スレーブのレプリケーション: マスターが書き込みのボトルネックになる

マスター-スレーブ-スレーブのレプリケーション: マスターが書き込みのボトルネックになる

MySQL データベースには約 2TB のデータがあります。

マスター-スレーブ-スレーブのレプリケーションを実行しています。データベースを使用するアプリケーションは、2 つのスレーブのうちの 1 つでのみ読み取り (SELECT) クエリを実行し、マスターで書き込み (DELETE/INSERT/UPDATE) クエリを実行します。アプリケーションは、書き込みよりも読み取りをはるかに多く実行します。

読み取り (SELECT) クエリに問題がある場合は、別のスレーブ データベースを追加して、アプリケーションに別のスレーブがあることを伝えるだけで済みます。そのため、拡張性も高くなります...

現在、マスターは書き込みのために約 40% のディスク IO を実行しています。

そこで、将来的にデータベースをどのように拡張するかを考えています。ある日、マスターが過負荷になるからです。

そこにはどんな解決策があるのでしょうか?

おそらく MySQL クラスターでしょうか? その場合、データベースを NDB に切り替える際に落とし穴や制限はありますか?

よろしくお願いします... :)

答え1

MySQL のスケーリングには万能の答えはありません。一般的なヒントをいくつか紹介します。

  • できる限り「対角線」にスケールします。つまり、コモディティ ハードウェアで実行できる限り、単一の MySQL サーバー上に維持します。これはおそらく、2 つのクアッドコア CPU、64 GB 以上の RAM、8 ディスク RAID 10 以上を意味します。「コモディティ ハードウェア」の上限は、毎年高速化しています。

  • Brad Fitzpatrick の LiveJournal のスケーリングに関するプレゼンテーションをご覧ください。LAMP のスケーリングに関する限り、これらはほぼ定番です。このプレゼンテーションの25~26ページMySQL レプリケーションで最終的に直面する問題がわかります。書き込みによって、利用可能なすべてのディスク I/O が消費されます。

  • 読む "高性能MySQL「本当に良い本です多くの高負荷のMySQLインストールを経験した著者

  • 可能な限り、シャーディング(複数の MySQL サーバーにデータを分散すること)を避けてください。シャーディングを開始すると、リレーショナル データベースのメリットのほとんどが失われ、開発が遅くなります。シャーディングを実行する必要がある場合は、代わりに、Riak、Cassandra、HBase、MongoDB などの組み込みマルチ サーバー モデルを備えた NoSQL データ ストアの使用を検討してください。理想的には、MySQL と NoSQL の間で「機能的パーティション分割」を行い、RDBMS によく適合するあまり頻繁に使用されないデータには MySQL を使用し続け、MySQL データと結合する必要のない「頻繁に使用される」データには NoSQL エンジンを使用します。

おそらく MySQL クラスターでしょうか? その場合、データベースを NDB に切り替える際に落とし穴や制限はありますか?

で "ウェブオペレーション「Baron Schwartz による MySQL に関する章があります。彼は、Web サイト環境での MySQL Cluster / NDB の使用に対して、ほぼ「ノー」と言っています。引用: 「...結合や GROUP BY クエリのパフォーマンスは良くありませんが、Web アプリケーションにはそれらが必要です。」

答え2

MySQL クラスタリングは、データベースを複数のマシンに分散されたフラグメントに分割することで、書き込みのスケーラビリティを向上させます。ただし、複数のフラグメントからデータを取得する複雑なクエリの速度は大幅に低下します。これがアプリケーションのパフォーマンスに与える影響は、ユーザーのみが判断できます。

クラスタリング エンジンに任せるのではなく、手動でデータのシャーディングを行うことを検討してください。より多くの構成が必要になりますが、アプリケーションがデータベースをどのように使用するかを理解している場合は、ほとんどのクエリが 1 つのシャードにのみアクセスできるようにするシャーディング スキームを考案できる可能性があります。

答え3

MySQL レプリケーションはシングル スレッドであるため、レプリケーションはマスターの容量によって制限されるのではなく、マスターに遅れずについていくことができず同期が取れなくなるスレーブによって制限される可能性があることに留意してください。この記事より:

レプリケーション再生プロセスはレプリカ上の単一スレッドで実行されるため、多くの更新が同時に発生しているプラ​​イマリ上の中程度の書き込み負荷にも追いつく見込みがありません。

答え4

情報自体をクラスタ化することを検討できます。可能であれば、書き込みを消費するテーブルを異なるサーバー間で分離します。

関連情報