Vergleich von RDS und EC2 für die Verwaltung von MySQL oder MariaDB auf AWS

RDS ist eine Database as a Service (DBaaS), die Ihre Datenbanken in der AWS-Cloud automatisch konfiguriert und verwaltet. Der Benutzer hat im Vergleich zum Ausführen von MySQL direkt auf der Elastic Compute Cloud (EC2) nur begrenzte Befugnisse über bestimmte Konfigurationen. Aber RDS ist ein praktischer Dienst, solange Sie mit den angebotenen Instanzen und Konfigurationen leben können.

Amazon RDS unterstützt derzeit verschiedene MySQL- und MariaDB-Versionen sowie die MySQL-kompatible Amazon Aurora DB-Engine. Es unterstützt die Replikation, aber wie Sie es von einer vordefinierten Webkonsole erwarten können, gibt es einige Einschränkungen.

Bei der Verwendung von RDS gibt es einige Kompromisse. Diese können sich nicht nur auf die Art und Weise auswirken, wie Sie Ihre Datenbankinstanzen verwalten und bereitstellen, sondern auch auf wichtige Dinge wie Leistung, Sicherheit und Hochverfügbarkeit.

In diesem Blog werfen wir einen Blick auf die Unterschiede zwischen der Verwendung von RDS und der Ausführung von MySQL auf EC2, wobei wir uns auf die Replikation konzentrieren. Wie wir sehen werden, ist die Entscheidung zwischen dem Hosten von MySQL auf einer EC2-Instance oder der Verwendung von Amazon RDS keine leichte Aufgabe.

Tradeoffs der RDS-Plattform

Die größte Datenbankgröße, die AWS hosten kann, hängt von Ihrer Quellumgebung, der Datenzuweisung in Ihrer Quelldatenbank und der Auslastung Ihres Systems ab.

AWS ist in Regionen aufgeteilt. Jedes AWS-Konto hat pro Region Beschränkungen für die Anzahl der AWS-Ressourcen, die erstellt werden können. Sobald ein Limit für eine Ressource erreicht wurde, schlagen weitere Aufrufe zum Erstellen dieser Ressource fehl.

Für Amazon RDS-MySQL-DB-Instances beschränkt das maximal bereitgestellte Speicherlimit die Größe einer Tabelle auf eine maximale Größe von 6 TB, wenn InnoDB-Tablespaces für Dateien pro Tabelle verwendet werden.

Die Datei-pro-Tabelle-Funktion von InnoDB ist etwas, das Sie in Betracht ziehen sollten, auch wenn Sie keine große Datenbank in die Cloud migrieren möchten. Möglicherweise stellen Sie fest, dass einige vorhandene DB-Instances eine Untergrenze haben. Beispielsweise haben MySQL-DB-Instances, die vor April 2014 erstellt wurden, eine Datei- und Tabellengrößenbeschränkung von 2 TB. Diese Dateigrößenbeschränkung von 2 TB gilt auch für DB-Instances oder Read Replicas, die aus DB-Snapshots erstellt wurden, die vor April 2014 erstellt wurden.

Einer der Hauptunterschiede, der sich auf die Art und Weise auswirkt, wie Sie die Datenbankreplikation einrichten und verwalten, ist das Fehlen von SUPER-Benutzern. Um diese Einschränkung zu beheben, hat Amazon gespeicherte Prozeduren eingeführt, die sich um verschiedene DBA-Aufgaben kümmern. Nachfolgend finden Sie die wichtigsten Verfahren zum Verwalten der MySQL-RDS-Replikation.

Replikationsfehler überspringen:

CALL mysql.rds_skip_repl_error;

Replikation stoppen:

CALL mysql.rds_stop_replication;

Replikation starten

CALL mysql.rds_start_replication;

Konfiguriert eine RDS-Instance als Read Replica einer MySQL-Instance, die außerhalb von AWS ausgeführt wird.

CALL mysql.rds_set_external_master;

Konfiguriert eine MySQL-Instanz so um, dass sie kein Read Replica einer MySQL-Instanz mehr ist, die außerhalb von AWS ausgeführt wird.

CALL mysql.rds_reset_external_master;

Importiert ein Zertifikat. Dies ist erforderlich, um die SSL-Kommunikation und die verschlüsselte Replikation zu ermöglichen.

CALL mysql.rds_import_binlog_ssl_material;

Entfernt ein Zertifikat.

CALL mysql.rds_remove_binlog_ssl_material;

Ändert die Logposition des Replikations-Masters an den Anfang des nächsten Binärlogs auf dem Master.

CALL mysql.rds_next_master_log;

Während gespeicherte Prozeduren eine Reihe von Aufgaben erledigen, ist dies eine gewisse Lernkurve. Das Fehlen der SUPER-Berechtigung kann auch zu Problemen bei der Verwendung der externen Replikationsüberwachung führen.

Amazon RDS unterstützt derzeit Folgendes nicht:

• Globale Transaktions-IDs
• Transportierbarer Tabellenbereich
• Authentifizierungs-Plugin
• Passwortstärke-Plugin
• Replikationsfilter
• Halbsynchrone Replikation

Last but not least - Zugriff auf die Shell. Amazon RDS erlaubt keinen direkten Hostzugriff auf eine DB-Instance über Telnet, Secure Shell (SSH) oder Windows Remote Desktop Connection (RDP). Sie können den Client weiterhin auf einem Anwendungshost verwenden, um sich über Standardtools wie mysql client mit der DB zu verbinden.

Es gibt weitere Einschränkungen, wie in der RDS-Dokumentation beschrieben.

Hohe Verfügbarkeit mit MySQL auf EC2

Zur Automatisierung von Bereitstellungs- und Verwaltungs-/Wartungsaufgaben (unter Beibehaltung der Kontrolle) ist es möglich, ClusterControl zu verwenden. Genau wie bei RDS haben Sie den Komfort, ein Datenbank-Setup in wenigen Minuten über eine GUI bereitzustellen. Das Hinzufügen von Knoten, das Planen von Backups, das Durchführen von Failovern usw. kann ebenfalls bequem über die GUI erfolgen. Es gibt Optionen, MySQL direkt auf EC2 zu betreiben und so die Kontrolle über die eigenen Hochverfügbarkeitsoptionen zu behalten. Wenn Sie diesen Weg gehen, ist es wichtig zu verstehen, wie Sie die verschiedenen AWS-Funktionen nutzen können, die Ihnen zur Verfügung stehen. Sehen Sie sich unbedingt unser Whitepaper „DIY Cloud Database“ an.

Bereitstellung

ClusterControl kann die Bereitstellung verschiedener hochverfügbarer Datenbank-Setups automatisieren – von der Master-Slave-Replikation bis hin zu Multi-Master-Clustern. Alle wichtigen MySQL-Varianten werden unterstützt – Oracle MySQL, MariaDB und Percona Server. Es ist eine anfängliche Einrichtung der VPC/Sicherheitsgruppe erforderlich, die im Whitepaper „DIY Cloud Database“ ausführlich beschrieben wird. Beachten Sie, dass ähnliche Konzepte gelten, unabhängig davon, ob es sich um AWS, Google Cloud oder Azure handelt

Galera Cluster ist eine gute Alternative, wenn Sie einen hochverfügbaren MySQL-Dienst bereitstellen. Es hat sich als glaubwürdiger Ersatz für traditionelle MySQL-Master-Slave-Architekturen etabliert, obwohl es kein Drop-in-Ersatz ist. Die meisten Anwendungen können immer noch angepasst werden, um darauf zu laufen. Es ist möglich, verschiedene Segmente für Datenbanken zu definieren, die sich über mehrere AWS-Regionen erstrecken.

Es ist möglich, eine „hybride Replikation“ einzurichten, indem die synchrone Replikation innerhalb eines Galera-Clusters und die asynchrone Replikation zwischen dem Cluster und einem oder mehreren Slaves kombiniert werden. Optionen wie das Verzögern des Slaves geben den Daten ein zusätzliches Maß an Schutz.

Proxy-Schicht

Um Hochverfügbarkeit zu erreichen, reicht es nicht aus, ein hochverfügbares Setup bereitzustellen. Die Anwendungen müssen irgendwie wissen, welche Knoten funktionieren und welche nicht. Änderungen in der Topologie, z. das Verschieben eines Masters auf einen anderen Host, müssen ebenfalls irgendwie weitergegeben werden, um Fehler in der Anwendungsschicht zu vermeiden. ClusterControl unterstützt die Bereitstellung von Proxys wie HAProxy, MaxScale und ProxySQL. Für HAProxy und ProxySQL gibt es zusätzliche Optionen zum Bereitstellen redundanter Instanzen mit Keepalived und VirtualIP.

Regionsübergreifendes Replikat

Amazon RDS bietet Read Replica-Services. Regionsübergreifende Replikate geben Ihnen die Möglichkeit, Lesevorgänge zu skalieren, da AWS seine Dienste in einer Reihe von Rechenzentren auf der ganzen Welt anbietet. Alle Lesereplikate sind zugänglich und können zum Lesen in maximal fünf Regionen verwendet werden. Diese Knoten sind unabhängig und können in Ihrem Upgrade-Pfad verwendet oder zu eigenständigen Datenbanken hochgestuft werden.

Darüber hinaus bietet Amazon Multi-AZ-Bereitstellungen basierend auf DRBD, synchroner Festplattenreplikation. Wie unterscheidet es sich von Read Replicas? Der Hauptunterschied besteht darin, dass nur die Datenbank-Engine auf der primären Instanz aktiv ist, was zu anderen architektonischen Variationen führt.

Im Gegensatz zu Lesereplikaten erfolgen Versions-Upgrades der Datenbank-Engine auf der primären Datenbank. Ein weiterer Unterschied besteht darin, dass AWS RDS mit DRBD automatisch ein Failover durchführt, während Read Replicas (mit asynchroner Replikation) manuelle Vorgänge von Ihnen erfordern.

Multi-AZ-Failover auf RDS verwendet eine DNS-Änderung, um auf die Standby-Instanz zu verweisen, laut Amazon sollte dies während des Failovers innerhalb von 60 bis 120 Sekunden geschehen. Da der Standby dieselben Speicherdaten wie der primäre verwendet, wird es wahrscheinlich eine Transaktions-/Protokollwiederherstellung geben. Größere Datenbanken können viel Zeit für die InnoDB-Wiederherstellung aufwenden, also berücksichtigen Sie dies bitte in Ihrem DR-Plan und Ihrer RTO-Berechnung.

Dies ist natürlich mit zusätzlichen Kosten verbunden. Schauen wir uns ein einfaches Beispiel an. Die Kosten für den db.t2.medium-Host mit 2vCPU und 4 GB RAM betragen 185,98 USD pro Monat. Der Preis verdoppelt sich, wenn Sie die Multizone (MZ)-Replik auf 370,98 UDB aktivieren. Der Preis variiert je nach Region, verdoppelt sich jedoch in MZ.

Um dasselbe mit EC2 zu erreichen, können Sie Ihre virtuellen Maschinen in verschiedenen Regionen bereitstellen. Jede AWS-Region ist völlig unabhängig. Die Einstellung der AWS-Region kann in der Konsole geändert werden, indem die Umgebungsvariable EC2_REGION festgelegt wird, oder sie kann überschrieben werden, indem der Parameter --region mit der AWS-Befehlszeilenschnittstelle verwendet wird. Wenn Ihr Serversatz bereit ist, können Sie ClusterControl verwenden, um Ihre Replikation bereitzustellen und zu überwachen. Sie können die Replikation auch manuell über die Konsole mit Standardbefehlen einrichten.

Technologieübergreifende Replikation

Es ist möglich, die Replikation zwischen einer Amazon RDS-MySQL- oder MariaDB-DB-Instance und einer MySQL- oder MariaDB-Instance außerhalb von Amazon RDS einzurichten. Dies erfolgt mithilfe der standardmäßigen Replikationsmethode in mysql über Binärprotokolle. Um Binärprotokolle zu aktivieren, müssen Sie die my.cnf-Konfiguration ändern. Ohne Zugriff auf die Shell wurde diese Aufgabe in RDS unmöglich. Das geschieht auf nicht so offensichtliche Weise. Sie haben zwei Möglichkeiten. Eine besteht darin, Backups zu aktivieren – legen Sie automatische Backups auf Ihrer Amazon RDS-DB-Instance mit einer Aufbewahrung auf höher als 0 fest. Oder aktivieren Sie die Replikation auf einen vorgefertigten Slave-Server. Beide Aufgaben aktivieren binäre Protokolle, die Sie später für Ihre Replikation verwenden können.

Behalten Sie die Binlogs in Ihrer Masterinstanz bei, bis Sie überprüft haben, dass sie auf das Replikat angewendet wurden. Diese Wartung stellt sicher, dass Sie Ihre Masterinstanz im Falle eines Ausfalls wiederherstellen können.

Ein weiteres Hindernis können Berechtigungen sein. Die zum Starten der Replikation auf einer Amazon RDS-DB-Instance erforderlichen Berechtigungen sind eingeschränkt und stehen Ihrem Amazon RDS-Master-Benutzer nicht zur Verfügung. Aus diesem Grund müssen Sie die Amazon RDS-Befehle mysql.rds_set_external_master und mysql.rds_start_replication verwenden, um die Replikation zwischen Ihrer Live-Datenbank und Ihrer Amazon RDS-Datenbank einzurichten.

Überwachen Sie Failover-Ereignisse für die Amazon RDS-Instance, die Ihr Replikat ist. Wenn ein Failover auftritt, wird die DB-Instance, die Ihr Replikat ist, möglicherweise auf einem neuen Host mit einer anderen Netzwerkadresse neu erstellt. Informationen zur Überwachung von Failover-Ereignissen finden Sie unter Verwenden der Amazon RDS-Ereignisbenachrichtigung.

Im folgenden Beispiel sehen wir, wie die Replikation von RDS zu einer externen DB aktiviert wird, die sich auf einer EC2-Instanz befindet.
Sie sollten Binärprotokolle aktiviert haben, wir verwenden hier einen RDS-Slave.

Geben Sie die Anzahl der Stunden an, für die Binärprotokolle aufbewahrt werden sollen.

mysql -h RDS_MASTER -u<username> -u<password>
call mysql.rds_set_configuration('binlog retention hours', 7);

Erstellen Sie auf RDS MASTER einen Replikationsbenutzer mit den folgenden Befehlen:

CREATE USER 'repl'@'ec2DBslave' IDENTIFIED BY 's3cr3tp4SSw0rd';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'ec2DBslave';

Führen Sie auf RDS SLAVE die Befehle aus:

mysql -u<username> -u<password> -h RDS_SLAVE
call mysql.rds_stop_replication;
SHOW SLAVE STATUS;  Exec_Master_Log_Pos, Relay_Master_Log_File.

Führen Sie auf RDS SLAVE mysqldump mit dem folgenden Format aus:

mysqldump -u<username> -u<password> -h RDS_SLAVE --routines --triggers --single-transaction --databases DB1 DB2 DB3 > mysqldump.sql

Importieren Sie den DB-Dump in eine externe Datenbank:

mysql -u<username> -u<password> -h ec2DBslave
tee import_database.log;
source mysqldump.sql;

CHANGE MASTER TO 
 MASTER_HOST='RDS_MASTER', 
 MASTER_USER='repl',
 MASTER_PASSWORD='s3cr3tp4SSw0rd',
 MASTER_LOG_FILE='<Relay_Master_Log_File>',
 MASTER_LOG_POS=<Exec_Master_Log_Pos>;

Erstellen Sie einen Replikationsfilter, um Tabellen zu ignorieren, die von AWS nur auf RDS erstellt wurden

CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE = ('mysql.rds\_%');

Replikation starten

START SLAVE;

Replikationsstatus überprüfen

SHOW SLAVE STATUS;

Das war es fürs Erste. Die Verwaltung von MySQL auf AWS ist ein großes Thema. Teilen Sie uns Ihre Gedanken im Kommentarbereich unten mit.