Read Replicas zur Skalierung von Lesezugriffen

Read Replicas sind Kopien Ihrer primären RDS-Instance, die Aktualisierungen über asynchrone Replikation empfangen. Im Gegensatz zur Multi-AZ-Standby-Instance sind Read Replicas für SELECT-Abfragen zugänglich. Dadurch können Sie Lesezugriffe verteilen und die primäre Datenbank entlasten.

Read Replicas werden für MySQL, PostgreSQL, MariaDB, Oracle (mit Active Data Guard) und alle Aurora-Editionen unterstützt. Sie können bis zu 15 Read Replicas für Aurora MySQL und Aurora PostgreSQL sowie bis zu 5 für standardmäßiges RDS MySQL/PostgreSQL verwenden.

Zum Erstellen einer Read Replica müssen für Ihre Quell-Instance automatisierte Backups aktiviert sein (Aufbewahrungsfrist größer als 0). AWS erstellt einen Snapshot der primären Instance, stellt ihn in einer neuen DB-Instance wieder her und richtet die asynchrone Replikation von der primären Instance ein.

Jede Read Replica erhält einen eigenen DNS-Endpunkt. Ihre Anwendung muss so aktualisiert werden, dass sie Lesezugriffe an die Endpunkte der Replikas sendet. Connection Pooler oder Anwendungs-Frameworks mit Lese-/Schreibaufteilung können SELECT-Abfragen automatisch an Replikas weiterleiten.

Da die Replikation asynchron erfolgt, können Read Replicas abhängig vom Schreibvolumen einige Millisekunden bis mehrere Sekunden hinter der primären Instance zurückliegen. Dies wird als Replikationsverzögerung bezeichnet. Sie können sie über die CloudWatch-Metrik ReplicaLag überwachen.

Anwendungen müssen so entworfen sein, dass sie beim Lesen aus Replikas mit letztendlicher Konsistenz umgehen können. Nach dem Einfügen eines Datensatzes kann eine sofortige Abfrage von einer Replica beispielsweise die neue Zeile noch nicht zurückgeben. Für Read-after-Write-Konsistenz muss dieser Lesezugriff wieder an die primäre Instance geleitet werden.

RDS unterstützt das Erstellen von Read Replicas in einer anderen AWS-Region und ermöglicht dadurch globale Skalierbarkeit für Lesezugriffe sowie Notfallwiederherstellung. Die regionsübergreifende Replikation verwendet das öffentliche Internet oder AWS Global Accelerator. Aufgrund der Netzwerklatenz ist die Replikationsverzögerung höher als innerhalb einer Region.

Regionsübergreifende Replikas sind nützlich, wenn Sie Lesezugriffe näher bei Benutzern in einer anderen geografischen Region bereitstellen möchten, eine einsatzbereite DR-Kopie in einer anderen Region benötigen, die hochgestuft werden kann, oder analytische Abfragen aus der Produktion auslagern möchten.

Durch das Hochstufen einer Read Replica wird die Replikationsverbindung getrennt und die Replica zu einer unabhängigen, beschreibbaren primären DB-Instance. Dies wird in Szenarien zur Notfallwiederherstellung verwendet, wenn die ursprüngliche primäre Instance nicht verfügbar ist, oder wenn Sie die Replica auf eine andere Engine-Version aktualisieren und als neue primäre Instance verwenden möchten.

Das Hochstufen ist nicht umkehrbar—nach der Hochstufung kann die Instance nicht mehr als Replica verwendet werden. Stellen Sie vor dem Hochstufen sicher, dass die Replica möglichst aktuell ist (minimale Verzögerung), um den Datenverlust zu minimieren. Aktualisieren Sie nach dem Hochstufen die Verbindungszeichenfolge Ihrer Anwendung auf den Endpunkt der neuen primären Instance.

In der SAA-C03-Prüfung ist die Unterscheidung zwischen Read Replicas und Multi-AZ entscheidend:

• Wenn das Szenario verbesserte Leseleistung oder Skalierung von Lesezugriffen verlangt → Read Replicas
• Wenn das Szenario automatisches Failover oder hohe Verfügbarkeit verlangt → Multi-AZ
• Wenn das Szenario beides verlangt → Multi-AZ für die primäre Instance plus Read Replicas

Denken Sie außerdem daran: Multi-AZ-Standby-Instances bedienen KEINE Lesezugriffe; Read Replicas bieten KEIN automatisches Failover (bei Nicht-Aurora-Replikas müssen Sie sie manuell hochstufen).

Aurora behandelt Read Replicas anders als standardmäßiges RDS. Aurora verwendet eine gemeinsam genutzte, verteilte Speicherebene, sodass Replikas auf dieselben zugrunde liegenden Datenseiten wie die primäre Instance zugreifen. Dadurch weisen Aurora-Replikas eine minimale Replikationsverzögerung (typischerweise unter 100 ms) auf und können jeweils Lesezugriffe bedienen.

Aurora stellt einen Reader Endpoint bereit, der Verbindungen auf alle verfügbaren Replica-Instances verteilt. Ihre Anwendung verbindet sich mit dem Reader Endpoint, und Aurora verteilt die Lesezugriffe automatisch. Wenn eine Replica ausfällt, wird sie aus dem Reader-Pool entfernt, ohne den Endpunkt zu beeinträchtigen.

Wenn in Aurora die primäre (Writer-)Instance ausfällt, stuft Aurora eine der Read Replicas automatisch zur primären Instance hoch—in ungefähr 30 Sekunden und damit deutlich schneller als ein Multi-AZ-Failover bei standardmäßigem RDS. Die hochgestufte Replica akzeptiert sofort Schreibzugriffe über den Cluster Writer Endpoint.

Aurora unterstützt Failover-Prioritätsstufen (0–15), sodass Sie steuern können, welche Replica zuerst hochgestuft wird. Weisen Sie Replikas auf größeren Instance-Klassen oder in bevorzugten AZs eine höhere Priorität (Stufe 0) zu.

Eine typische Architektur zur Skalierung von Lesezugriffen leitet den Datenverkehr über einen Application Load Balancer oder die Anwendungslogik:

• Alle Schreibvorgänge (INSERT, UPDATE, DELETE) → Primärer DB-Endpunkt
• Alle Lesevorgänge (SELECT) → Endpunkte der Read Replicas oder Aurora Reader Endpoint
• Session-Cache und Ergebniscache → ElastiCache (reduziert Lesezugriffe auf Replikas zusätzlich)

Für extrem umfangreiche Analyseabfragen sollten Sie erwägen, eine Replica hochzustufen oder Auroras Funktion für parallele Abfragen zu verwenden, um die Berechnung auf die Speicherebene zu verlagern und Auswirkungen auf den Produktionscluster zu vermeiden.

Zu den wichtigsten CloudWatch-Metriken für Read Replicas gehören:

• ReplicaLag — Sekunden hinter der primären Instance; alarmieren Sie, wenn dieser Wert unerwartet ansteigt
• ReadIOPS — stellt sicher, dass der Speicher der Replica mit der Abfragelast Schritt hält
• DatabaseConnections — stellt sicher, dass die Replica nicht durch Verbindungen ausgelastet ist
• CPUUtilization — eine hohe CPU-Auslastung der Replica weist auf Optimierungsbedarf bei Abfragen hin

RDS Performance Insights ist für Read Replicas verfügbar und zeigt die wichtigsten SQL-Anweisungen, die den größten Anteil der Datenbankzeit verbrauchen. Dadurch können Sie kostenintensive Leseabfragen erkennen und optimieren.

Häufige Anwendungsfälle für RDS Read Replicas in der SAA-C03-Prüfung:

• Berichte und Analysen: Führen Sie umfangreiche SELECT-Abfragen auf einer Replica aus, um die Produktionsschreibvorgänge nicht zu verlangsamen
• Geografische Verteilung: Regionsübergreifende Replikas bedienen Benutzer auf anderen Kontinenten mit geringerer Latenz
• Notfallwiederherstellung: Eine regionsübergreifende Replica kann hochgestuft werden, wenn die primäre Region ausfällt
• Entwicklung und Tests: Stufen Sie eine Replica hoch, um eine Testumgebung mit einer aktuellen Kopie der Produktionsdaten zu erstellen

Read Replicas sind kein Ersatz für Backups—halten Sie automatisierte Backups und manuelle Snapshots stets unabhängig voneinander vor.

Testen Sie Ihr Verständnis der AWS-Solutions-Architect-Konzepte (SAA-C03) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: Read Replicas verwenden asynchrone Replikation, um Lesezugriffe zu verteilen, Replikationsverzögerung bedeutet, dass Replikas geringfügig hinter der primären Instance zurückliegen können, und Aurora-Replikas weisen eine minimale Verzögerung auf und unterstützen automatisches Hochstufen. Regionsübergreifende Replikas bieten sowohl globale Skalierbarkeit für Lesezugriffe als auch eine Option zur Notfallwiederherstellung. Als Nächstes sehen wir uns die RDS-Sicherheit mit Verschlüsselung und Parametergruppen an.