web-dev-qa-db-ja.com

Amazon RDS for MySQLとAmazon EC2インスタンスにMySQLをインストールする

仕事では、Amazon EC2ですべてのウェブサーバーをホストし、通常、Apacheウェブサーバーと同じボックスにインストールされたMySQLデータベースを使用し、localhostで通信しました。現在、システムの1つのために、データベースを独自のサーバーに移行する必要があります。 Amazon RDS を使用するか、新しい Amazon EC2 ボックスを起動してMySQLをインストールするという2つのソリューションから選択できます。

EC2と同じ会社が提供する専用データベースサービスであるRDSは、明らかに優れているオプションである必要があるようです。ただし、2つのオプションの価格を見ると( http://aws.Amazon.com/ec2/pricing および http://aws.Amazon.com/rdsを参照)/pricing )RDSサーバーのコストは、同じ仕様のボックスのEC2サーバーのほぼ2倍のようです。

私は自分でバックアップを処理でき、EC2はRDSと同じようにインスタンスをスケールアップできるため、EC2の代わりにRDSを使用する理由がまったくわかりません。しかし、私はおそらく何か大きなものを見逃しているようです。なぜなら、私が正しければ、誰もRDSを使用しないからです。正確には何が欠けているのですか、また独自のデータベースをEC2インスタンスにインストールするよりもRDSの利点は何ですか?

31
Mark Amery

私は一般的にAWSの大ファンですが、RDSはそれほどではありません。

@RolandoMySQLDBAが指摘したいくつかのかなり良い点があります。

EC2上のMySQLと比較してRDSで私が目にする唯一の利点は、ポイントアンドクリックスナップショット、クローン、およびポイントインタイムリカバリを実行できることですが、これらは、制御と柔軟性の喪失を補うにはほとんど十分ではありません。最も確かに価格が高くなることを正当化しないでください。 RDSはいくつかの点で魅力的ですが、すべての可動部分に到達できないため、最終的に修正できないものを最終的に信頼することはできません。

SUPER特権を持たないのは好きではありません。エラーログを追跡できないのが嫌いです。データベースサーバーで "top"または "iostat"を実行して、コアとドライブが負荷をどのように楽しんでいるかを確認できないのが嫌です。フェデレーテッドストレージエンジンにアクセスできないのは嫌です。リードレプリカとして活用できないホットスタンバイ(マルチAZ)バックアップマスターマシンにお金を払うという考えは好きではありません。確かに、MySQLをRDBMS-in-a-boxとして正常にパッケージ化して販売するために、これらの制約をすべて整える必要がある理由は完全に合理的です。唯一のことは、RDBMS-in-a-boxは一連のない問題(「== --- ==」)を「解決」します...方法、新しい問題を引き起こしています。

しかし、RDSを使用する私にとって絶対的な問題は、バイナリログとレプリケーションへのアクセスの完全な欠如です。 Binlogは、特に行ベースの場合、軽度の障害に対しては素晴らしい回復ツールですが、アクセスできない場合は役に立ちません。オフィスのオンプレミスサーバーをRDSの運用データベースの読み取りレプリカとして構成しませんか? RDSに存在するデータに思いがけない事態が発生した場合、ローカルバックアップを取得してレポートを作成し、災害復旧のために準備しておく必要がありますか?それは同時に明白で素晴らしいアイデアです。

申し訳ありませんが、レプリケーションに直接アクセスできません。確かに、リードレプリカの支払いは可能ですが、他のRDSインスタンスと同じです。私の本の価値命題ではありません。

更新:RDS for MySQL 5.6の1つの重要な変更

ser-Defined Functions のサポートの欠如、 を使用できないことなど、さまざまな理由により、RDSを実行するのではなく、自分のサーバー(EC2でも)を実行することを好みます。 Federated Storage Engine 、そして 1つの追加接続 を使用できないため、緊急アクセスに使用できます...ただし...

Amazonは、MySQL 5.6 for RDSに大幅な変更を加えました。これにより、私の大きな異論の1つを排除できます。おそらく最大の異論です。バイナリログにアクセスできるようになり、RDS以外のインスタンスをスレーブとして実行したり、他のユーティリティをbinlogストリームを読み取るサーバー。

http://docs.aws.Amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Exporting.NonRDSRepl.html

公式には、ドキュメントは、ライブマイグレーションを実行する目的でスレーブをセットアップできるように、これを公開していることを示しています。mysqldumpを使用して、既存のRDSインスタンスから外部の将来のマスターサーバーを同期し、接続します。アプリケーションが新しいマスターに移行されるまで、レプリケーションストリームを介して更新のライブフィードを取得するために、スレーブとしてRDSに送信します。あなた...私には、それは合理的に思えます。

これは確認されました 最近のウェビナーで 、56:45頃に始まる会話:

「無期限に複製された状態を維持できます...

「...複製を維持する責任がある限り...」

「それが必要な場合でも、継続的なレプリケーションを妨げるものではありません。」

この新しい機能は、FEDERATEDやその他の機能をほとんどまたはまったく使用しない、一般向けのWebサイトを裏付けているMySQLインスタンスでRDSを使用することに全面的な反対を払​​うのに十分でした。

ですから、私はまだそれを支持していませんが、バイナリログのライブストリームがあると、最終的にはリアルタイムでデータを制御できるようになり、トランザクションが発生しないようにする責任があるので、私は反対しません。壊滅的な停止で失われたのは、私が戻ってきたからです。なぜなら、私はDBAとして、自分がコントロールできるようになっているからです。第三者のベンダーに指を向けたり、訴訟を起こしたりしても、それがブラックボックス内のブラックホールに消えても、失われたデータは返されません。

経営陣はRDSの「アイデア」を気に入っており、コストの違いに異議を唱えていないため、RDSを背後に持つすべての新しいWebサイトを立ち上げています。

ポイントアンドクリックのポイントインタイムリカバリは、RDSの優れた機能です。既存のマシンを変更または中断することはありません。代わりに、以前のバックアップを使用して、まったく新しいインスタンスを起動します選択した特定の時点に最も近い時点で、必要なバイナリログを適用して、新しいマシンを指定した時点に進めます。

これに関連しますが、反対の方向では、同様の戦略を使用してライブMySQLデータベースをRDSに移行することも可能です... RDSマスターを接続できます(通常、これは新しくデプロイされたものです)インスタンス)既存のシステムのスレーブとして、移行時にRDSインスタンスにデータのライブバージョンが存在するようにします。 5.6でのみ機能する外部レプリケーション用のRDSバイナリログへのアクセスとは異なり、 内部レプリケーションはRDSでサポートされています 5.5.33および5.6.13から始まります。

20

DBサーバーのスケールアウトが not your cup of tea の場合、Amazon RDSはすべてのベルとホイッスルが付属しているため、使用しても問題ありません。中程度のHA、バックアップ、およびスケールアウトを単に望んでいる人は、大きな利益を得ます。

反対に、ハードウェアをスケールアップする場合は、RDSでは問題外です。 MySQLの機能をスケールアップしたい場合はどうなりますか?残念ながら、それは多くの面で問題とはなりません。

たとえば、7つのRDSサーバーモデルすべてで2つのフィールドが制限されていることをご存知ですか?

これらの2つのオプションについて、次の表に注意してください。

_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 (Command Line Interface)を使用して目的のオプションを変更する必要があります。次に、これを実行して、新しいオプションをインポートする必要があります。

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

単一の変数を更新するAPIを使用し、RDSインスタンスを強制的に再起動して変更を実装しますか?これは、1つのオプションを選択するのが非常に困難なプロセスです。

MySQLをスケールアップする場合は、EC2を使用してください。次に、あなたがいつもやっていることに慣れているように、_my.cnf_を好みに合わせて調整できます。

11
RolandoMySQLDBA