AWS RDS: Read Replicas für Datenbanken aktivieren

Relationale Daten­banken skalieren nor­maler­weise nicht hori­zontal, wenn man vom Multi-AZ-Feature absieht, einer speziellen Eigen­schaft von AWS-RDS-Instanzen. Anders hingegen ist die Lage bei Read-Replikaten. Das Feature stellt eine Art von horizon­talem Cluster dar, der einzig einer Erhöhung der Lese-Performance dient.

Mulit-AZ wird mit Hilfe von AWS-Technologien (Instanz-Snapshots) auf der Ressource-Ebene realisiert und ändert nichts an den prinzipiellen Ein­schränkungen, die der Betrieb von relationalen Daten­banken, egal ob auf Basis von physischen, virtuellen oder Cloud-basierten Servern, mit sich bringt.

Read Replicas

Bei Read-Replikaten handelt es sich grundsätzlich um eine Eigenschaft der jeweiligen DB-Engine. Mit ihnen ist es sehr einfach möglich, lese­intensive Datenbank-Workloads über die Kapazitäts­grenzen einer einzelnen DB-Instance hinaus zu skalieren.

Jeder Nutzer kann ein Read-Replikat einer bestimmten Quell-DB-Instance mit Hilfe der AWS Management Console oder der RDS-API sowie der AWS-Befehls­zeilen­schnitt­stelle erstellen. Nach dem Erzeugen von Read-Replikaten werden Datenbank­aktualisierungen an der Quell-DB-Instance auch für die Read Replica übernommen.

Nutzer können je nach DB-Engine mehrere Read Replicas für eine gegebene Quell-DB-Instance erstellen und den Lesedaten­verkehr seiner Anwendung auf diese verteilen. Read-Replikate arbeiten generell asynchron, mit der Folge, dass zum Beispiel Updates erst dann in das Replikat übernommen werden, nachdem sie in der Quell-DB-Instance eingespielt wurden.

Laut AWS kann die Ver­zögerung bei der Replizierung durchaus erheblichen Schwankungen unterliegen. Read Replicas bieten demnach nicht die Vorteile in puncto Daten­beständigkeit wie Multi-AZ-Bereit­stellungen, dafür aber bei der Verfüg­barkeit sowie der Erhöhung der Lese­leistung.

Read Replicas verbessern auch nicht die Leistung bei Schreib­vorgängen. Allerdings lassen sich Multi-AZ-Bereit­stellungen und Read Replicas problemlos miteinander kombinieren, um in den Genuss der Vorteile von beiden Lösungen zu kommen.

Die Bereitstellung mehrerer Read Replicas für eine existierende Quell-DB-Instance ist in mehreren Szenarien sinnvoll:

• Der Anwender muss die Rechen- oder I/O-Leistung einer einzelnen DB Instance bei Datenbank-Workloads mit extensiven Lesevor­gängen skalieren. In diesem Fall lässt sich der Read-Traffic gut durch eine oder mehrere Lese-Replikate leiten.
• Lese-Replikate erfüllen zudem ihren Zweck, wenn die Quell-DB-Instance nicht verfügbar ist oder keine I/O-Anforderungen mehr bearbeiten kann. Das kann bei geplanten Wartungs­arbeiten der Fall sein oder im Kontext von I/O-Einschränkungen für Backups. Allerdings muss dann in Betracht gezogen werden, dass die Daten in der Read Replica möglicher­weise veraltet sind.
• Auch in Reporting- und Data-Warehouse-Szenarien kann es mitunter sinnvoll sein, Lese­anforderungen nicht über die primäre Produktions-DB-Instance laufen zu lassen.

Einschalten von Read-Replikaten

Vor dem Hinzu­fügen von Read-Replikaten unter MySQL oder MariaDB muss man zunächst das Feature automatische Backups auf der gewünschten Quell-DB-Instance aktivieren, indem man den Auf­bewahrungs­zeitraum für Backups auf einen Wert größer 0 setzt.

Hier funktionieren Read Replicas im Gegensatz zu PostgresQL nur, wenn die automatischen Backups aktiviert bleiben. Konkret erstellt man Lese-Replikats durch Spezifizieren eines SourceDB­Instance­Identifier als Read Replica.

Der SourceDB­Instance­Identifier ist die Kennung der Quell-DB-Instanz, aus der die Daten repliziert werden sollen. Wie bei einer standard­mäßigen DB Instance kann man auch hier Availability Zone, DB Instance-Klasse und das bevorzugte Wartungs­fenster festlegen.

Die Engine-Version (zum Beispiel PostgreSQL 9.3.5) und die Speicher­zuweisung einer Read Replica erbt diese allerdings von der Quell-DB-Instance.

Hat man das Erstellen einer Read Replica im Menü Instance actions => Create read replica oder Create Aurora Read Replica angestoßen, dann legt Amazon RDS zunächst einen Snapshot der Quell-DB-Instance an und beginnt dann mit der Replizierung.

Das hat eine kurze Aussetzung des I/O-Datenverkehrs der Quell-DB-Instance zur Folge. Diese dauert in der Regel nicht länger als eine Minute und kann vermieden werden, wenn es sich bei der DB-Instance um eine Multi-AZ-Bereitstellung handelt (Kombination).

Read-Replikate in AWS nach Datenbank-Engine

• Amazon Aurora: Alle Aurora-DB-Cluster unterstützen (bis zu 15) Read-Replicas
• Amazon RDS for MySQL: DB-Instanzen mit MySQL Version 5.5 oder neuer. Allerdings müssen Automatische Backups auf der Quell-DB-Instance für Read Replica-Vorgänge aktiviert sein und bleiben. Auto­matische Backups auf dem Replikat werden nur unter MySQL 5.6 und höher unterstützt.
• Amazon RDS for PostgreSQL: DB-Instanzen mit PostgreSQL Version 9.3.5 oder neuer erlauben das Erstellen von Read Replicas. Bestehende PostgreSQL-Instanzen müssen ggf. auf Version 9.3.5 aktualisiert werden, um die Vorteile von Amazon RDS Read Replicas nutzen zu können.
• Amazon RDS für MariaDB: Alle DB-Instances unterstützen die Erstellung von Read Replicas. Allerdings müssen automatische Backups auf der Quell-DB-Instance für Read Replica-Vorgänge aktiviert sein und bleiben.