MySQLサーバーを自動スケーリングする方法は？

トラフィックが急増しているサイトを運営しています。そのため、この場合、自動スケーリングソリューションは非常に有益です。現在、Webサーバーは水平方向に自動スケーリングできますが、ボトルネックはMySQLサーバーにあります。

• 私はAmazon RDSマルチAZを試してみましたが、12 GBのデータベースをアップグレードするには、数分のダウンタイムで15分程度かかります。ある特定の瞬間にトラフィックの急増が起こることをすでに知っていたとき、それは多くの助けとなりました。
• Xeroundも検討しました。このサイズのデータ​​ベースでは非常にコストがかかりますが、これはおそらく最良のソリューションです。とにかく、データベースをEUに置くことを法的に必要とするため、これは選択肢ではありません。
• 私はScalrについて読みましたが、それが役立つかどうか、またどのように役立つかはわかりません。
• 多くのクラウドホスティングプロバイダーが垂直スケーリングソリューションを提供し、ダウンタイムがゼロであると考えています（Xenハイパーバイザーを使用している限り、それが本当に可能かどうかはわかりません）。それは解決策になるかもしれませんが、ダウンタイムがないのか、MySQL構成（およびOS上の他の多くのこと）がダウンタイムなしでもアップグレードできるのかと思います。
• MySQLスレーブサーバーを試しましたが、まったく役に立ちませんでした。
• memcacheを使用していますが、これは非常に役立ちますが、それだけでは不十分です。読み取りのためだけでなく、書き込みのためにアップグレードする必要があります。

助言がありますか？前もって感謝します

実際、より簡単な解決策は、スタックにMemcachedを追加して、DBの負荷を節約することです。これは負荷を大幅に節約でき、サーバーをすばやく立ち上げる（難易度が低い）問題を解決し、MySQLの高速同期を計算する（難易度がはるかに高い）よりもはるかに簡単です。

http://toblender.com/?s=memcached

書き込みが多すぎるという問題を解決するための最も一般的な修正は、サーバーにメモリを追加する（より大きなワーキングセットをRAMに保持できる）、より高速なディスクにDBを配置する（SSDは優れたソリューションですが、コストがかかる）、またはシャーディングです。 （これは、追加のサーバーと複雑さで高価です）。

DBの書き込み負荷を軽減する別の方法は、頻繁に変更されるデータを処理するためにインメモリデータストア（Redisなど）を組み込み、必要に応じて定期的に変更をメインDBに書き戻すことです。

スタートポロジの使用を検討する必要があります

これが私が提案しているものです

• 1つの書き込みマスター（別名WM）
• 1つの配布マスター（別名DM）
• Five（5）Read Slave Server（aka RSS）

このようなトポロジを準備する

ステップ01：これらの一般的なオプションで5 RSSをセットアップする

[mysqld]
skip-innodb
key_buffer_size=1G

これにより、すべてのテーブルがMyISAMストレージエンジンとしてロードされて作成されます。

ステップ02：DMとすべてのRSサーバーのセットアップ

• mysqldumpは、WMからschemadumpファイルへのすべてのテーブルのスキーマを
• schemadumpファイルをDMと5つすべてのRSSにロードします
• tblname ROW_FORMAT=Fixed;RSSのすべてのテーブルでALTER TABLE を実行する
• tblname ENGINE=BLACKHOLE;DMのすべてのテーブルでALTER TABLE を実行します
• mysqldumpデータのみ（--no-create-infoを使用）をデータダンプに
• 5つすべてのRSSにデータダンプをロードする

ステップ03：DMから5つすべてのRSSへのレプリケーションのセットアップ

ステップ04：WMからDMへのレプリケーションのセットアップ

セットアップの終わり

読み取り/書き込みメカニズムの仕組みは次のとおりです

• すべての書き込み（INSERT、UPDATE、DELETE）はWMで発生します
• SQLはDMのバイナリログに記録されます（DMには実際のデータはありません）
• 各RSSはDMへの読み取りスレーブです
• すべての読み取りはRSSで行われます

これが問題です...

• 最初に読み取りにRSS 1-4を使用する
• 5番目のRSSを使用して他のRSSを起動する
  • service mysql stop5番目のRSSで実行します
  • 別のRSSをスピンアップ
  • 5番目のRSSの/ var / lib / mysqlおよび/etc/my.cnfを新しくスピンアップしたRSSにコピーします
  • service mysql stop5番目のRSSで実行します
  • service mysql stop新しいRSSで実行します

RSS＃5を使用して、新しいサーバーを何度も起動できます。

補足として、XEROUNDはInnoDBまたはBLACKHOLEストレージエンジンをサポートしていないため、WMまたはDMには使用しないでください。

これらのアイデアがお役に立てば幸いです。

Innodbを使用する場合は、Galeraが管理するMysqlマルチマスターを検討する必要があります。mysqlマルチマスターの設定が簡単になり、「セミ」自動スケーリングが簡単になります。

これがあなたまたはあなたの会社が書いているアプリケーションである場合、そのアプリケーションの分割（パーティション化）設計への移行を検討できます。ただし、シャーディングは複雑になる可能性があります。ここにあなたを始めるためのリンクがあります。

私は、割り当てられた適切なメモリなどのように、mysql構成ファイルを「調整」したと想定しています。

これはあなたが管理するラックにありますか、それともクラウドにありますか？12GBは、使用可能なディスクのサイズに比べて非常に小さいデータベースです。小さなSLC SSDのRAID1またはRAID10アレイに配置すると、書き込みレイテンシがなくなります。

インテル311シリーズの20ギガバイトSLC SSD（$ 120、それぞれ）が見事に仕事をするでしょう。

データベースが大きい場合、データベースをZFS SANサーバーのiSCSIターゲットに移動し（Nexenta、OpenIndiana、FreeNASなどを使用してコモディティサーバーハードウェア上に構築）、同様のSSDのミラーを設定することで、同様に素晴らしい結果を得ることができます。 ZIL書き込みキャッシュ。最も特殊な状況を除いて、ギガビットイーサネットはデータベースiSCSIトラフィックを移動するのに十分です。