Bei der Arbeit hosten wir alle unsere Webserver auf Amazon EC2 und haben in der Regel MySQL-Datenbanken verwendet, die auf derselben Box wie unser Apache-Webserver installiert sind, und mit ihnen auf kommuniziert localhost. Wir müssen jetzt unsere Datenbank für eines unserer Systeme auf einen eigenen Server migrieren. Ich habe die Wahl zwischen zwei Lösungen: Verwenden Sie Amazon RDS oder starten Sie einfach eine neue Amazon EC2- Box und installieren Sie MySQL darauf.

Da RDS ein dedizierter Datenbankdienst ist, der vom selben Unternehmen wie EC2 bereitgestellt wird, scheint es die offensichtlich bessere Option zu sein. Wenn ich mir jedoch die Preise für die beiden Optionen anschaue (siehe http://aws.amazon.com/ec2/pricing und http://aws.amazon.com/rds/pricing ), scheint ein RDS-Server fast zu kosten doppelt so viel wie ein EC2-Server für eine Box mit den gleichen Spezifikationen.

Da ich in der Lage bin, Backups selbst zu verwalten und EC2 die gleiche Möglichkeit bietet, die Instanz wie RDS zu skalieren, sehe ich überhaupt keinen Grund, RDS anstelle von EC2 zu verwenden. Es scheint, als würde mir wahrscheinlich etwas Großes fehlen, denn wenn ich recht hätte, würde niemand RDS verwenden. Was fehlt mir genau und was sind die Vorteile von RDS gegenüber der Installation Ihrer eigenen Datenbank auf einer EC2-Instanz?

Ich bin im Allgemeinen ein großer AWS-Fan ... aber RDS, nicht so sehr.

@RolandoMySQLDBA hat darauf hingewiesen, dass einige ziemlich gute Punkte dagegen sprechen.

Der einzige Vorteil, den ich in RDS im Vergleich zu MySQL in EC2 sehe, ist die Möglichkeit, Schnappschüsse, Klone und Wiederherstellungen zu erstellen, die jedoch bei weitem nicht ausreichen, um den Verlust an Kontrolle und Flexibilität auszugleichen Rechtfertigen Sie mit Sicherheit nicht, dass der Preis höher ist. RDS ist in mancher Hinsicht sexy, aber Sie können letztendlich nicht vertrauen, was Sie letztendlich nicht reparieren können, weil Sie nicht an alle beweglichen Teile gelangen können.

Ich mag es nicht, kein SUPERPrivileg zu haben. Ich mag es nicht, das Fehlerprotokoll nicht abschließen zu können. Ich mag es nicht, nicht "top" oder "iostat" auf meinem Datenbankserver ausführen zu können, um zu sehen, wie die Kerne und Laufwerke die Last genießen. Ich mag es nicht, keinen Zugriff auf die Verbundspeicher-Engine zu haben. Ich mag den Gedanken nicht, für einen Hot-Standyby-Backup-Master-Rechner (Multi-AZ) zu bezahlen, den ich nicht einmal als Lesereplikat nutzen kann. Sicher, es gibt absolut vernünftige Erklärungen, warum alle diese Einschränkungen vorhanden sein müssen, damit MySQL erfolgreich verpackt und als RDBMS-in-a-Box verkauft werden kann. Die einzige Sache ist, dass RDBMS-in-a-Box eine ganze Reihe von Problemen "löst" , die ich nicht habe ... und sich mir in den Weg stellt und neue Probleme verursacht.

Aber der absolute Deal-Breaker für mich bei RDS ist das völlige Fehlen des Zugriffs auf die Binärprotokolle und die Replikation. Binlogs, insbesondere zeilenbasierte, sind ein fantastisches Wiederherstellungstool für kleinere Katastrophen, aber sie helfen Ihnen nicht, wenn Sie nicht auf sie zugreifen können. Möchten Sie einen lokalen Server in Ihrem Büro als Lesereplikat Ihrer Produktionsdatenbank in RDS konfigurieren? Entnehmen Sie lokalen Backups, haben Sie Berichte für die Notfallwiederherstellung parat, sollte etwas Undenkbares mit Ihren Daten geschehen, die in RDS gespeichert sind? Das ist eine Idee, die offensichtlich und brillant zugleich ist.

Hoppla, leider ist kein direkter Zugriff auf die Replikation verfügbar. Sicher, Sie können für gelesene Replikate bezahlen ... aber nur für andere RDS-Instanzen. Kein Wertversprechen in meinem Buch.

Update: Eine wesentliche Änderung in RDS für MySQL 5.6

Ich ziehe es immer noch meinen eigenen Server (auch in EC2) läuft im Gegensatz RDS für eine Reihe von Gründen, einschließlich der Mangel an Unterstützung für zu laufen Benutzerdefinierte Funktionen , die Unfähigkeit , die verwenden Federated Storage Engine , und die Unfähigkeit zu haben , die eine zusätzlicher Anschluss für den Notfallzugang verfügbar ... jedoch ...

Amazon hat eine wesentliche Änderung in MySQL 5.6 für RDS vorgenommen, mit der einer meiner wichtigsten Einwände beseitigt wird - vielleicht mein größter Einwand: Auf die Binärprotokolle kann jetzt zugegriffen werden, und Sie können eine Nicht-RDS-Instanz als Slave ausführen oder andere Dienstprogramme mit dem verbinden Server, der den Binlog-Stream gelesen hat.

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

Offiziell wird in der Dokumentation angegeben, dass diese Informationen verfügbar gemacht werden, damit Sie einen Slave für die Live-Migration einrichten können. Sie synchronisieren den fremden zukünftigen Masterserver von der vorhandenen RDS-Instanz mithilfe von mysqldumpund verbinden ihn dann als Slave mit RDS Sie können einen Live-Feed mit Updates über den Replikationsdatenstrom abrufen, bis Ihre Anwendung auf den neuen Master migriert wurde. Inoffiziell können Sie dies jedoch fortlaufend tun, sofern Sie nicht erwarten, dass sie Sie unterstützen. scheint mir vernünftig.

Dies wurde kürzlich in einem Webinar in einem Gespräch bestätigt, das gegen 56:45 Uhr beginnt:

"Sie können es auf unbestimmte Zeit in einem replizierten Zustand halten ...

"... solange Sie die Verantwortung für die Pflege der Replikation übernehmen ..."

"Wir hindern Sie nicht daran, eine fortlaufende Replikation durchzuführen, wenn Sie dies wünschen."

Diese neue Funktion genügte mir, um meinen generellen Einwand gegen die Verwendung von RDS in unseren öffentlich zugänglichen MySQL-Instanzen mit Website-Unterstützung zu verwerfen, in denen wir FEDERATEDoder einige der anderen Dinge nicht so häufig oder überhaupt nicht verwenden.

Deshalb bin ich immer noch nicht dafür, aber ich bin nicht länger dagegen, da ich durch einen Live-Stream der Binärprotokolle letztendlich wieder die Kontrolle über die Daten in Echtzeit habe und die Verantwortung dafür habe, dass keine Transaktionen getätigt werden verloren in einem katastrophalen Ausfall ist zurück bei mir, weil ich als DBA wieder die Kontrolle habe - genau so will ich es haben. Wenn Sie einen Drittanbieter beauftragen, mit den Fingern darauf zu zeigen oder eine Klage gegen ihn einzureichen, werden Ihre verlorenen Daten nicht zurückerhalten, wenn sie in einem schwarzen Loch in einer Black Box verschwinden.

Das Management scheint die "Idee" von RDS zu mögen und erhebt keine Einwände gegen den Kostenunterschied. Deshalb starten wir jetzt alle neuen Websites mit RDS dahinter.

Die Point-and-Click-Point-in-Time-Wiederherstellung ist eine nette Funktion in RDS. Sie verändert oder stört Ihren vorhandenen Computer nicht. Stattdessen wird mithilfe der zuvor erstellten Sicherung eine völlig neue Instanz gestartet am nächsten zum ausgewählten Zeitpunkt und wendet dann die erforderlichen Binlogs an, um den neuen Computer auf den von Ihnen angegebenen Zeitpunkt zu verschieben.

In diesem Zusammenhang, aber in der anderen Richtung, ist es jetzt auch möglich, eine ähnliche Strategie zu verwenden, um eine Live-MySQL-Datenbank in RDS zu migrieren. Sie können einen RDS-Master anschließen (wahrscheinlich ist dies in der Regel ein neu implementierter Master) Instanz) als Slave eines vorhandenen Systems, sodass die RDS-Instanz zum Zeitpunkt der Migration die Live-Version der Daten hat. Im Gegensatz zum Zugriff auf die RDS-Binlogs für die ausgehende Replikation, die nur in 5.6 funktioniert, wird die eingehende Replikation in RDS ab 5.5.33 und 5.6.13 unterstützt.

Wenn es nicht Ihre Aufgabe ist, DB-Server zu verkleinern , können Sie Amazon RDS verwenden, da alle Voraussetzungen dafür erfüllt sind. Diejenigen, die einfach nur moderate HA, Backups und Skalierung wünschen, profitieren in hohem Maße.

Auf der anderen Seite kommt dies für RDS nicht in Frage, wenn Sie die Hardware vergrößern möchten. Was ist, wenn Sie die Funktionen von MySQL erweitern möchten? Leider kommt das für viele Aspekte nicht in Frage.

Wussten Sie beispielsweise, dass zwei Felder für alle sieben (7) RDS-Servermodelle begrenzt sind?

• max_connections
• innodb_buffer_pool_size

Beachten Sie die folgende Tabelle zu diesen beiden Optionen:

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)

Sie haben kein SUPER-Privileg und es gibt keinen direkten Zugang zu my.cnf. Vor diesem Hintergrund müssen Sie zum Ändern der my.cnfStartoptionen zunächst eine MySQL-basierte DB-Parameter-Optionsliste erstellen und RDS CLI (Command Line Interface)die gewünschten Optionen mit ändern. Dann müssen Sie dies tun, um die neuen Optionen zu importieren:

• Erstellen Sie eine benutzerdefinierte DB-Parametergruppe (nennen Sie es MySettings)
• Laden Sie RDS CLI herunter und richten Sie eine Konfigurationsdatei mit Ihren AWS-Anmeldeinformationen ein
• Führen Sie Folgendes aus: ./rds-modify-db-parameter-group MySettings --parameters "name=whateveroption,value=whatevervalue,method=immediate"
• Ändern Sie mithilfe der DB-Parameteroptionsliste MySettings
• Starten Sie die MySQL RDS-Instanz neu

Verwenden Sie eine API zum Aktualisieren einer einzelnen Variablen und zum Ausführen eines obligatorischen Neustarts der RDS-Instanz, um die Änderung zu implementieren? Das ist ein ziemlich schmerzhafter Prozess, um eine Option zu finden.

Wenn Sie MySQL skalieren möchten, verwenden Sie bitte EC2. Dann können Sie my.cnfnach Belieben zwitschern , wie Sie es immer getan haben und gewohnt waren.