web-dev-qa-db-ja.com

Perconaデータセンターのスケーリング：セットアップとレプリケーション

私たちのスタートアップはうまくやってきたので、私たちは今あなたがいつもあなたに影響を与えることは決してないと想定していたそれらの問題のいくつかに会っています。

アプリケーションスタックの多くはすでにスケーリングされています。一時情報用の高読み取り/書き込みテーブルを別のPerconaサーバーにオフロードしました。このテーブルは、「Engine = MEMORY」で実行されており、他のセクションをcassandra 集まる。

これで、88％/ 12％の読み取り/書き込み負荷がかかる「リーン」データベースが残りました。この時点で、いくつかの質問があります。

1。スレーブの読み取り

読み取り/書き込みの設定では、いくつか（たとえば2〜3）の読み取りスレーブにより、読み取りマスターの書き込み負荷を最小限に抑える必要があります。読み取りスレーブソリューションのスケーラビリティはどの程度ですか。負荷を2倍または3倍にすると、読み取りスレーブが追加され、読み取りに十分な容量が引き続き提供されますか？私はこの投稿を読みました： マスターあたりのスレーブの数の制限は何ですか？ ただし、スケーラビリティの背景から出てこないので、これはばかげているように見えるかもしれませんが、これはフリーズ可能なソリューションですか？読み取り/スレーブソリューションではなく、シャーディングを推進している人はたくさんいますが、現時点では、アプリケーションの大規模なセクションを書き換えるための読み取り/書き込み負荷の必要性はありません...

2。複数のデータセンターとレプリケーション

さらに、ネットワークラグを減らすために、データセンターが近くにあるさまざまな地理的な場所にサービスを提供することも検討しています（ラグをあまり好きではないモバイルアプリケーションを扱っています）。計画は、よく言及されたセミシンクを使用することです。レプリケーション（参照： MySQL DBを2つのサーバーに分割することは良い考えですか および ハイレイテンシーインターコネクトによって影響を受けるMySQLレプリケーションですか？ ）各データセンターには1つのマスターと複数の読み取りスレーブがあります。繰り返しますが、私の初心者にとって、これがスケーリング時の「ベストプラクティス」の範囲内であるかどうかを知ることに非常に興味があります。

3。ハードウェアと構成

私は過去数週間、ライブシステムのベンチマークに忙しくしており、ポイント1と2に選択したソリューションに関係なく、現在使用しているサーバーはそれ以上長くは機能しない可能性があるという結論に達しました。私は私たちのセットアップについていくつかの考えを得ます：

CPU: Intel(R) Xeon(R) CPU E31275 @ 3.40GHz mit 8 cores (hyperthreading)
RAM: 16GB
Raid 10 with a strip size of 64 KB and controller cache enabled
Software: Percona 5.5
Database size: 83.7GB
Top 5 Tables:
 21302MB  table1
 7656MB  table2
 5477MB  table3
 4352MB  table4
 3663MB  table5

my.cnf設定：

 max_heap_table_size=64M
 tmp_table_size=64M
 default_storage_engine = InnoDB
 innodb_buffer_pool_size = 10G
 innodb_file_per_table   = 1
 innodb_old_blocks_time=1000
 innodb_buffer_pool_instances=10
 innodb_log_file_size=256M
 innodb_flush_method=O_DIRECT
 innodb_read_io_threads=10
 innodb_write_io_threads=10
 join_buffer_size = 67108864 #64M
 expand_fast_index_creation=ON

Percona XtraDB Clusterソリューションに移行すると、私たちの問題の一部が解決されます。レプリケーションの安定性？

これらは非常に理論的な質問がたくさんあることを知っています。私の考えを読んでコメントするために時間を割いてくださった方に感謝します。ヨーロッパの小さなスタートアップとして、私たちは本当に「クラウドに行く」ためのベンチャーキャピタルを本当に持っておらず、私たちは自分自身でより多くのコントロールを持つことを好みます。コンサルタントなどを調べていると、stackexchangeがアイデアを跳ね返すのに最適な場所だと思いました。

mysqlreplicationmysql-5.5perconaxtradb-cluster
6
tnosaj

この場合、実際には2つの選択肢があります

選択＃1：Percona XtraDBクラスター

私は現在それを評価しており、MultiMaster書き込み用に見事に設計されていると思います。 mysqldump（デフォルト）、rsync、およびxtrabackup（推奨）を使用して、新しいクラスターノードを初期化できます。あなたには完全な自由と力があります。これは史上最大の決まり文句かもしれませんが、 優れたパワーを備えている場合、常に優れた責任を負う必要があります（ビデオの19:16-19:25） 。

あなたは最終的に

  • innoDBのメモリ要件とディスク構成のサイジング
  • myISAMのDDL/DMLはGalera書き込みセットレプリケーターライブラリに複製されないことを思い出してください。 GRANTコマンドはストレージエンジンに中立であるため、mysqlスキーマのMyISAMテーブルは問題なく処理されます。 mysql.userに対するDMLは複製されません。
  • 読み取り/書き込み用の新しいクラスターノードのプロビジョニングの追加

選択＃2：Amazon RDS

Amazon RDSは、MySQLデータベースクラウドサービスを簡単にします。 7つのサーバーモデルのいずれかでサーバーを展開するのに、ある程度の時間を費やす必要があります。デフォルトでは、すべてのInnoDBログファイルは128Mです。各サーバーモデルに固有のオプションは次のとおりです。

MODEL      max_connections innodb_buffer_pool_size
---------  --------------- -----------------------
t1.micro   34                326107136 (  311M)
m1-small   125              1179648000 ( 1125M,  1.097G)
m1-large   623              5882511360 ( 5610M,  5.479G)
m1-xlarge  1263            11922309120 (11370M, 11.103G)
m2-xlarge  1441            13605273600 (12975M, 12.671G)
m2-2xlarge 2900            27367833600 (26100M, 25.488G)
m2-4xlarge 5816            54892953600 (52350M, 51.123G)

SUPER特権 が付与されておらず、my.cnfに直接アクセスできません。これを踏まえて、起動時にmy.cnfオプションを変更するには、最初にMySQLベースのDBパラメータオプションリストを作成し、 RDS CLI（コマンドラインインターフェイス） を使用して目的のオプションを変更する必要があります。次に、これを実行して、新しいオプションをインポートする必要があります。

  • カスタムDBパラメータグループを作成します（これをMySettingsと呼びます）
  • RDS CLIをダウンロードし、AWS認証情報で構成ファイルをセットアップする
  • 次を実行します：./rds-modify-db-parameter-group MySettings --parameters "name=whateveroption,value=whatevervalue,method=immediate"
  • DBパラメータオプションリストを使用して変更MySettings
  • MySQL RDSインスタンスを再起動します

データセンターへのスケールアウトについては、リードレプリカを作成するオプションがあります。デフォルトのストレージエンジンはInnoDBであるため、マスターを中断することなくデータをスレーブに同期できるため、リードレプリカの作成がシームレスになります。

サーバーモデルが高いほど、より多くのメモリ、より多くのIOPを使用できます。 Amazon RDSの場合、GREAT POWER COMES GREAT MONEY。となるので、私が述べた決まり文句を忘れないでください。

9
RolandoMySQLDBA

よく@ tnosaj、Read Slavesに関する最初の質問に関して-通常、マスターは5-6スレーブにシームレスに複製できます。ただし、読み取りスレーブが適切に機能しているかどうかを評価することは、使用しているアプリケーションのタイプを知ることが重要です。たとえば、ソーシャルアプリケーションの「いいね」の数は、eコマースサイトとは異なり、リアルタイムで更新する必要はありません。商品が完売した場合は、すぐに更新する必要があります。したがって、このタイプの読み取りスレーブは前者の場合には適していますが、後者の場合には適していません。

2番目の質問については、複数のデータセンターとレプリケーションについて-同じデータセンター内にマスターマスターレプリケーションを実装することがベストプラクティスです。理想的には、専用のクラスターホストで実行する必要があります。複数のデータセンターでマスターマスターレプリケーションを実行することは一般的ではありません。この理由は、マスター/マスターレプリケーション（すべてのクラスターと同様）が提示できる最大の課題は、「スプリットブレイン」と呼ばれる状況であるためです。このような場合、各マスターは切断され、再起動後に独立して動作し始めます。このタイプの「スプリットブレイン」の問題を修復するには、通常、ダウンタイムと手動処理が必要です。 （これをチェックしてください スプリットブレインのWikiページ ）。

それに伴うDBベンダーについては、@ Rolandoで言及されているPercona XtraDBクラスターとRDSに加えて、 Xeround's の提供も確認することをお勧めします（これは、 [〜＃〜] rds [〜＃〜] ）。

0
Lena Weber