Ein Unternehmen betreibt eine On-Premises-Anwendung, die von einer MySQL-Datenbank unterstützt wird. Das Unternehmen migriert die Anwendung zu AWS, um die Elastizität und Verfügbarkeit zu verbessern. Die Produktionsdatenbank weist im Normalbetrieb eine hohe Leseaktivität auf. Alle 4 Stunden zieht das Entwicklungsteam einen vollständigen Export der Produktionsdatenbank, um eine Staging-Datenbank zu füllen; während dieses Exports erfahren Benutzer eine inakzeptable Latenz, und das Entwicklungsteam kann das Staging erst verwenden, wenn der Export abgeschlossen ist. Ein Solutions Architect muss eine Ersatzarchitektur empfehlen, die die Anwendungslatenz eliminiert und es dem Entwicklungsteam ermöglicht, die Staging-Umgebung ohne Verzögerung zu nutzen. Welche Lösung erfüllt diese Anforderungen?

Die korrekte Lösung ist Amazon Aurora MySQL mit Multi-AZ Aurora Replicas für die Produktion und Datenbank-Cloning für die Staging-Datenbank. Aurora Replicas bieten hohe Leseleistung und Multi-AZ sorgt für Hochverfügbarkeit. Datenbank-Cloning in Aurora ist eine schnelle und kostengünstige Methode, um eine vollständige, aber speichereffiziente Kopie einer Datenbank zu erstellen, ohne die Leistung der Produktionsdatenbank zu beeinträchtigen. Dies löst das Problem der Latenz während des Exports und ermöglicht dem Entwicklungsteam den sofortigen Zugriff auf die Staging-Umgebung. Die anderen Optionen sind weniger geeignet: mysqldump verursacht weiterhin Latenz auf der Produktionsdatenbank und ist zeitaufwändig. Die Verwendung der Standby-Instanz einer Multi-AZ RDS-Bereitstellung für Staging ist nicht vorgesehen und würde die Verfügbarkeit der Produktion beeinträchtigen, da die Standby-Instanz nur für Failover gedacht ist. RDS for MySQL bietet nicht die gleiche Leistung und die schnellen Cloning-Fähigkeiten wie Aurora.