Amazon SOA-C02: Datenbanken und Caching — Lernleitfaden

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Teil des AWS SysOps Administrator Associate SOA-C02 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Datenbanken und Caching gehören zu den zentralen operativen Aufgaben eines SysOps-Administrators: Sie bieten persistenten Speicher, Verfügbarkeit und Lesevorgänge mit geringer Latenz für Anwendungen. Dieser Bereich umfasst den Betrieb von verwalteten relationalen Datenbanken (RDS und Aurora), die Skalierung der Lese-/Schreibkapazität, das Replikations- und Failover-Verhalten sowie die Nutzung von ElastiCache zur Reduzierung der DB-Last. Die richtige Konfiguration von Backups, Parametergruppen, Überwachung und Cache-Invalidierungsmustern verhindert Datenverluste und reduziert Betriebsstörungen.

RDS- und Aurora-Betrieb, Backups und Multi-AZ

RDS (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server) und Amazon Aurora (MySQL- und PostgreSQL-kompatibel) sind verwaltete relationale Engines mit unterschiedlichen Betriebssemantiken. Multi-AZ für RDS erstellt einen synchronen Standby in einer anderen AZ – verwaltet von AWS, mit automatischem Failover innerhalb von Minuten, ohne manuelle Heraufstufung, und der Standby ist nicht für Lesevorgänge zugänglich. Aurora trennt Writer- und Reader-Endpunkte: Der Writer ist ein Cluster-Endpunkt, der von einer primären Instanz unterstützt wird, und Aurora verwendet verteilten Speicher, der automatisch über AZs hinweg repliziert wird und in der Regel schneller ein Failover durchführen kann als RDS, da der Speicher gemeinsam genutzt wird.

Konfigurieren Sie Backups und Aufbewahrung mit:

Automatisierte Backups: Aktivieren Sie diese mit einer Aufbewahrungsfrist (z. B.

undefined

). Diese ermöglichen eine Point-in-Time-Recovery (PITR) zu jeder Sekunde innerhalb des Aufbewahrungsfensters für unterstützte Engines.

Manuelle Snapshots:

undefined

(oder

undefined

für Aurora), um einen aufbewahrten Snapshot zu erstellen; Snapshots bleiben bestehen, bis Sie sie löschen.

PITR-Wiederherstellung:

undefined

für RDS oder

undefined

und anschließendes Erstellen von Instanzen für Aurora.

Entscheidungskriterien:

Verwenden Sie Multi-AZ für Hochverfügbarkeit und automatisches Failover, wenn die Schreibverfügbarkeit kritisch ist und Lesevorgänge auf dem Standby nicht erforderlich sind.
Verwenden Sie Aurora (geclusterter Speicher), wenn Sie hohe IOPS, schnelles Failover und automatische Speicherskalierung benötigen.
Verwenden Sie Read Replicas für die Skalierung von Lesevorgängen und die regionsübergreifende Notfallwiederherstellung (sie sind asynchron und können heraufgestuft werden).

Operative CLI-Beispiele:

Multi-AZ aktivieren:

undefined

Automatisierten Snapshot erstellen:

undefined

PITR wiederherstellen:

undefined

Read Replicas, Failover und Replikationsstrategien

Read Replicas sind asynchrone Kopien (RDS- oder Aurora-Reader), die hauptsächlich zur Skalierung des Leseverkehrs und zur Auslagerung von Berichten verwendet werden. Sie verursachen eine Replikationsverzögerung (überwachen Sie die Metrik ReplicaLag) und sind nicht für starke Konsistenz geeignet. Read Replicas können zu eigenständigen DB-Instanzen heraufgestuft werden, um die Notfallwiederherstellung zu unterstützen.

Replikationsstrategien und -optionen:

Synchron (RDS Multi-AZ Standby) – Garantie für keine Datenabweichung, keine Lesekapazität auf dem Standby.
Asynchrone Read Replicas – Skalierung von Lesevorgängen, Ermöglichung regionsübergreifender Kopien, Risiko von Replikationsverzögerungen und potenziellem Datenverlust beim Failover.
Aurora-Reader – bieten geclusterte Lese-Endpunkte, Failover mit geringer Latenz durch Umleitung des Endpunkts und automatischen Lastausgleich des Reader-Endpunkts.

Betriebsmuster:

Read Replica erstellen:

undefined

Replica heraufstufen:

undefined

Überwachung: CloudWatch DatabaseConnections, ReplicaLag, ReadIOPS, WriteIOPS und Performance Insights, um zu entscheiden, wann Replicas hinzugefügt oder entfernt werden sollen.

Entscheidungskriterien:

Wenn Sie HA für Schreibvorgänge benötigen, wählen Sie Multi-AZ. Wenn Sie Lesedurchsatz und die Auslagerung von Analysen benötigen, wählen Sie Read Replicas oder Aurora-Reader.
Für regionsübergreifendes DR erstellen Sie Read Replicas in der Zielregion und ziehen Sie die automatisierte Kopie von Snapshots oder DMS für die Migration in Betracht.

Caching mit ElastiCache und Cache-Invalidierung

ElastiCache bietet Redis und Memcached, um die DB-Last und Latenz zu reduzieren. Wählen Sie Redis, wenn Sie Persistenz, Replikation, Datenstrukturen und Hochverfügbarkeit mit Multi-AZ und automatischem Failover benötigen. Wählen Sie Memcached für einfaches horizontales Caching, bei dem Sharding und Multithread-Leistung Priorität haben.

Wichtige Konfigurationen und Muster:

Redis-Cluster mit Replicas und Multi-AZ erstellen:

undefined

Verwenden Sie den aktivierten Cluster-Modus für Redis, um Shards zu skalieren; Memcached erfordert clientseitiges Hashing für das Sharding.
Eviction-Richtlinien (Entfernungsrichtlinien): volatile-lru, allkeys-lru, noeviction – passen Sie diese an, je nachdem, ob Sie nur abgelaufene Schlüssel oder beliebige Schlüssel entfernen möchten, wenn der Speicher voll ist.
Überwachen Sie CacheHits und CacheMisses, um die Cache-Trefferquote zu berechnen: hit_ratio = CacheHits / (CacheHits + CacheMisses). Streben Sie eine hohe Trefferquote an, um DB-Lesevorgänge zu reduzieren.

Strategien zur Cache-Invalidierung:

Cache-aside: Die Anwendung prüft zuerst den Cache, bei einem Fehlschlag (Miss) liest sie aus der DB und füllt den Cache; bei Schreibvorgängen wird der Cache explizit abgelaufen oder gelöscht.
Write-through/Write-behind: Schreibvorgänge im Cache werden an die DB weitergegeben; Write-behind fasst DB-Schreibvorgänge in Batches zusammen (erhöht die Komplexität).
Time-to-live (TTL): Setzen Sie konservative TTLs für Daten, die veraltet sein dürfen; kombinieren Sie dies mit Cache-Versionierung oder Invalidierungsschlüsseln für Schemaänderungen oder Masseninvalidierungen.
Verwenden Sie Redis Pub/Sub oder Lambda-Events, um Anwendungsinstanzen bei Bedarf über eine verteilte Invalidierung zu benachrichtigen.

Datenbank-Parametergruppen, Skalierung und Überwachung

Parametergruppen steuern Engine-spezifische Einstellungen (z. B. max_connections, innodb_buffer_pool_size). RDS verwendet DB-Parametergruppen für Instanzen und DB-Cluster-Parametergruppen für Aurora. Änderungen an einigen Parametern erfordern einen Neustart (Anwendung bei ausstehendem Neustart), andere werden sofort wirksam.

Verwaltungsmuster:

Parametergruppe erstellen und ändern: aws rds create-db-parameter-group –db-parameter-group-name pg1 –db-parameter-group-family mysql8.0 –description “custom”; dann aws rds modify-db-parameter-group –db-parameter-group-name pg1 –parameters “ParameterName=max_connections,ParameterValue=500,ApplyMethod=immediate”
Instanzklasse skalieren: aws rds modify-db-instance –db-instance-identifier mydb –db-instance-class db.r5.large –apply-immediately (oder während des Wartungsfensters, um einen Neustart zu vermeiden).
Speicher-Autoscaling: für unterstützte Engine-Typen aktivieren; Aurora skaliert den Speicher automatisch.

Überwachungs- und Skalierungssignale:

CloudWatch (FreeableMemory, CPUUtilization, DatabaseConnections, WriteLatency, ReadLatency, DiskQueueDepth) und Performance Insights für langsame SQL-Abfragen und Top-Warteereignisse verwenden.
Erweiterte Überwachung (Enhanced Monitoring) aktivieren und Granularität festlegen (z. B. 1s zur Fehlerbehebung).
RDS Proxy verwenden, um das Verbindungspooling zu verwalten und Verbindungsstürme bei serverlosen oder hochgradig nebenläufigen Anwendungen zu reduzieren.

Sicherungs-/Wiederherstellungsverfahren und Überlegungen zur Migration

Backups und Wiederherstellungen müssen explizit durchgeführt und getestet werden. Automatisierte Backups ermöglichen eine PITR innerhalb der Aufbewahrungsfrist; manuelle Snapshots bleiben bis zur Löschung erhalten und können regionsübergreifend sowie mit anderen KMS-Schlüsseln kopiert werden. Geben Sie bei der Wiederherstellung die Region und den Zeitstempel explizit an.

Gängige Wiederherstellungsbefehle:

Wiederherstellung zu einem bestimmten Zeitpunkt (RDS): aws rds restore-db-instance-to-point-in-time –source-db-instance-identifier mydb –target-db-instance-identifier mydb-restore –use-latest-restorable-time / oder –restore-time angeben
Snapshot wiederherstellen (regionsübergreifend): Zuerst copy-db-snapshot in die Zielregion ausführen, dann wiederherstellen.

Überlegungen zur Migration:

AWS DMS für Migrationen mit minimaler Ausfallzeit (heterogen/homogen). DMS unterstützt die fortlaufende Replikation; stellen Sie die korrekten Einstellungen der Quell-Engine sicher (binlog für MySQL aktiviert).
Logische Migration (mysqldump, pg_dump) für einfache Exporte; physische Wiederherstellung von Snapshots für große Datenmengen.
Zeichensätze, Unterschiede in den Parametergruppen und KMS-Schlüssel für verschlüsselte Snapshots validieren.

Häufige Fallstricke und Entscheidungskriterien

Wiederherstellung von Backups in der falschen Region oder zum falschen Zeitpunkt: Vor der Wiederherstellung immer –region und –restore-time überprüfen; kopierten Snapshot in der Zielregion verwenden und Wiederherstellungen in einer Staging-Umgebung testen.
Annahme, dass Read Replicas Hochverfügbarkeit bieten: Denken Sie daran, dass Replicas asynchron sind; verwenden Sie Multi-AZ oder Aurora für Schreib-HA und synchrone Replikation.
Übersehen der Cache-Invalidierung: Entwerfen Sie TTLs, versionierte Schlüssel oder eine ereignisgesteuerte Invalidierung; vermeiden Sie es, sich für die Korrektheit ausschließlich auf kurze TTLs zu verlassen.
Automatisierte Backups oder Aufbewahrungsfrist nicht korrekt aktivieren: backup-retention-period >0 setzen und PITR durch Test-Wiederherstellungen validieren; sicherstellen, dass KMS-Schlüssel in der Zielregion für die Snapshot-Kopie verfügbar sind.
Ändern von Parametergruppen ohne Neustart: ApplyMethod prüfen; Neustarts für Parameter, die einen Neustart erfordern, in Wartungsfenstern planen, um unerwartete Ausfallzeiten zu vermeiden.
Skalierung ohne Verbindungsmanagement: Die Erhöhung der Instanzklasse ohne Verwendung von RDS Proxy oder Verbindungspooling löst möglicherweise keine Verbindungsstürme; implementieren Sie Pooling, um viele kurzlebige Verbindungen zu verwalten.

Praktisches Problem: Anwendungsfallszenario

Acme Retail betreibt eine primäre MySQL-RDS-Instanz mit hohem Lesetraffic und gelegentlichen Analyse-Spitzen. Sie haben mit Replica-Lag während der nächtlichen ETL-Prozesse zu kämpfen und beobachten eine hohe Verbindungsfluktuation, die CPU-Spitzen verursacht.

Eine zusätzliche Read-Replica-Gruppe für Analysen aktivieren, die von den Anwendungs-Lesern isoliert ist, und sie für DR in einer anderen AZ oder Region platzieren.
Replica-Überwachung (Metrik ReplicaLag) konfigurieren und eine Autoscaling-Logik hinzufügen, um weitere Reader hinzuzufügen, wenn der Lag oder die ReadLatency Schwellenwerte überschreitet.
RDS Proxy vor der Anwendung bereitstellen, um Verbindungen zu multiplexen und die Verbindungsfluktuation zu reduzieren; max_connections in der Parametergruppe entsprechend anpassen.
Analyse-Jobs auf die Analyse-Replica verlagern und Cache-Aside-Caching über ElastiCache Redis mit passenden TTLs einsetzen, um wiederholte Abfragen zu reduzieren.
Failover- und Wiederherstellungsverfahren testen: eine PITR-Wiederherstellung auf einer Staging-Instanz durchführen und die Schritte zur Heraufstufung der Replica validieren.

Dieser Ansatz trennt Lese-Workloads, reduziert den Verbindungsdruck auf die primäre Instanz und nutzt Caching, um das Leseaufkommen der Datenbank zu senken. Er folgt den AWS Best Practices, indem er Lese-Skalierung, Verbindungspooling und getestete Sicherungs-/Wiederherstellungsprozesse kombiniert, um Verfügbarkeit und betriebliche Ausfallsicherheit zu gewährleisten.

← Rechenleistung und Auto Scaling · Alle Domänen · Serverless und Anwendungsintegration →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →