Firma uruchamia aplikację lokalną, której bazą danych jest MySQL. Firma migruje aplikację do AWS, aby poprawić elastyczność i dostępność. Produkcyjna baza danych doświadcza intensywnej aktywności odczytu podczas normalnej pracy. Co 4 godziny zespół programistów pobiera pełny eksport produkcyjnej bazy danych, aby zapełnić bazę danych stagingową; podczas tego eksportu użytkownicy doświadczają niedopuszczalnych opóźnień, a zespół programistów nie może korzystać ze środowiska stagingowego, dopóki eksport się nie zakończy. Architekt rozwiązań musi zarekomendować architekturę zastępczą, która eliminuje opóźnienia aplikacji i pozwala zespołowi programistów korzystać ze środowiska stagingowego bez opóźnień. Które rozwiązanie spełnia te wymagania?

Prawidłowa odpowiedź to użycie Amazon Aurora MySQL z replikami Multi-AZ dla środowiska produkcyjnego i klonowania bazy danych do tworzenia środowiska stagingowego. Aurora Multi-AZ zapewnia wysoką dostępność i skalowalność odczytu. Klonowanie bazy danych Aurora tworzy kopię bazy danych w ciągu kilku minut, bez wpływu na wydajność bazy danych źródłowej, co eliminuje opóźnienia podczas eksportu i pozwala zespołowi deweloperów na natychmiastowe korzystanie ze środowiska stagingowego. Pozostałe opcje są nieprawidłowe, ponieważ: Użycie mysqldump do zapełniania bazy danych stagingowej spowodowałoby nadal opóźnienia w środowisku produkcyjnym, ponieważ jest to operacja intensywnie obciążająca bazę danych. Użycie Amazon RDS for MySQL, nawet z replikami odczytu i Multi-AZ, nie oferuje tak szybkiego i bezproblemowego klonowania jak Aurora, co jest kluczowe dla eliminacji opóźnień podczas tworzenia środowiska stagingowego. Instancja standby w RDS służy do wysokiej dostępności, a nie do tworzenia środowiska stagingowego.