Multi-AZ i automatyczne kopie zapasowe

Multi-AZ to funkcja wysokiej dostępności RDS, która automatycznie tworzy synchroniczną replikę zapasową w innej strefie dostępności w tym samym regionie. AWS zarządza replikacją w sposób niewidoczny dla użytkownika — łączą się Państwo za pomocą pojedynczego punktu końcowego DNS, a RDS kieruje ruch do instancji głównej.

Jeśli instancja główna ulegnie awarii z powodu problemów sprzętowych, sieciowych lub systemu operacyjnego, RDS automatycznie przełączy ruch na replikę zapasową w ciągu około 60–120 sekund. Aplikacja ponownie nawiązuje połączenie z użyciem tego samego punktu końcowego DNS, który wskazuje teraz adres IP repliki zapasowej.

Multi-AZ można włączyć podczas tworzenia instancji RDS lub przez zmodyfikowanie istniejącej instancji. Podczas włączania tej funkcji dla działającej instancji AWS wykonuje migawkę instancji głównej, odtwarza ją w drugiej strefie dostępności, a następnie synchronizuje przy użyciu natywnej replikacji silnika. Proces ten może spowodować krótkotrwałe wstrzymanie operacji wejścia/wyjścia na instancji głównej, dlatego należy zaplanować go w okresie małego ruchu lub zaakceptować termin wyznaczony przez okno konserwacji.

Multi-AZ jest obsługiwane przez wszystkie silniki RDS, w tym MySQL, PostgreSQL, MariaDB, Oracle i SQL Server, i nie wymaga żadnych zmian na poziomie aplikacji.

Podczas przełączania awaryjnego RDS aktualizuje rekord CNAME DNS punktu końcowego bazy danych, aby w ciągu około 60 sekund wskazywał replikę zapasową. Aplikacja musi ponownie nawiązać połączenie po wykryciu zerwania połączenia TCP. Aby ograniczyć opóźnienia ponownego łączenia:

• należy używać krótkiego czasu TTL DNS (zwykle RDS ustawia go już na 5 sekund)
• należy zaimplementować w logice połączeń wykładnicze zwiększanie odstępów między próbami wraz z ponawianiem
• należy korzystać z narzędzi do puli połączeń, takich jak RDS Proxy, które automatycznie ponawiają połączenie

Przełączanie awaryjne można również wywołać ręcznie na potrzeby konserwacji lub zmiany klasy instancji, co przy włączonym Multi-AZ umożliwia aktualizacje przy niemal zerowym przestoju.

Częstym źródłem pomyłek na egzaminie jest rozróżnienie między Multi-AZ (dostępność) a Read Replicas (skalowalność). Najważniejsze różnice:

• Replika zapasowa Multi-AZ: replikacja synchroniczna, nie obsługuje ruchu odczytu, automatyczne przełączanie awaryjne, ten sam region
• Read Replica: replikacja asynchroniczna, obsługuje ruch odczytu, brak automatycznego przełączania awaryjnego, może znajdować się w innym regionie

Multi-AZ nie zwiększa wydajności odczytu — replika zapasowa jest niedostępna dla zapytań. Aby jednocześnie zwiększyć dostępność i skalować odczyty, należy użyć Multi-AZ dla instancji głównej oraz osobno dodać Read Replicas.

RDS automatycznie tworzy codzienne pełne migawki bazy danych i przechwytuje dzienniki transakcji co 5 minut. Razem funkcje te umożliwiają odzyskiwanie do określonego punktu w czasie (PITR) dla dowolnej sekundy w okresie przechowywania kopii zapasowych. Bazę danych można odtworzyć do stanu z dowolnego momentu w tym okresie.

Automatyczne kopie zapasowe są domyślnie włączone i można je przechowywać od 1 do 35 dni. Ustawienie okresu przechowywania na 0 wyłącza automatyczne kopie zapasowe (oraz PITR). Okno tworzenia kopii zapasowych to 30-minutowy przedział, który można wskazać samodzielnie lub pozwolić, aby AWS wybrał go poza godzinami szczytu.

Okno kopii zapasowej to czas, w którym wykonywane są codzienne migawki. W tym oknie operacje wejścia/wyjścia pamięci masowej mogą zostać na krótko wstrzymane w przypadku wdrożeń Single-AZ. Wdrożenia Multi-AZ wykonują migawkę z instancji rezerwowej, eliminując wpływ na operacje wejścia/wyjścia instancji podstawowej.

Okno konserwacji to oddzielny cotygodniowy okres, w którym AWS stosuje poprawki systemu operacyjnego, pomniejsze aktualizacje silnika i modyfikacje instancji. Najlepszą praktyką jest ustawienie obu okien na okresy małego ruchu oraz zadbanie o to, aby się nie pokrywały.

Aby przywrócić dane do określonego punktu w czasie, RDS najpierw przywraca najnowszą codzienną migawkę, a następnie odtwarza dzienniki transakcji do żądanego znacznika czasu. Wynikiem jest nowa instancja DB — PITR nigdy nie nadpisuje instancji źródłowej, zapewniając bezpieczną ścieżkę odzyskiwania, która nie przerywa działania środowiska produkcyjnego.

Gdy przywrócona instancja będzie dostępna, należy zaktualizować parametry połączenia aplikacji tak, aby wskazywały nowy punkt końcowy, zweryfikować integralność danych, a następnie usunąć oryginalną instancję, jeśli odzyskiwanie było zamierzone. Typowy czas przywracania jest proporcjonalny do rozmiaru bazy danych i ilości dzienników od czasu wykonania ostatniej migawki.

Oprócz automatycznych kopii zapasowych można w dowolnym momencie wykonywać ręczne migawki. W przeciwieństwie do automatycznych kopii zapasowych ręczne migawki nie podlegają okresowi przechowywania — pozostają dostępne do momentu ich jawnego usunięcia.

Ręczne migawki są idealne do zapisania stanu przed dużą migracją schematu, aktualizacją aplikacji lub na koniec cyklu rozliczeniowego w celu archiwizacji zgodnej z wymaganiami. Można również udostępniać ręczne migawki innym kontom AWS albo kopiować je między regionami na potrzeby odzyskiwania po awarii.

Automatyczne lub ręczne migawki można kopiować do innego regionu AWS na potrzeby odzyskiwania po awarii. Kopia jest pełną migawką przechowywaną w infrastrukturze S3 regionu docelowego. Po skopiowaniu można przywrócić nową instancję RDS w tym regionie, jeśli region podstawowy stanie się niedostępny.

Kopie migawek mogą być szyfrowane w miejscu docelowym nawet wtedy, gdy źródło nie jest szyfrowane, i odwrotnie. Kopiowanie między regionami wiąże się z kosztami transferu danych. Do automatyzacji okresowego kopiowania migawek między regionami należy użyć AWS Backup lub funkcji Lambda wyzwalanej przez EventBridge.

Amazon RDS Proxy znajduje się między aplikacją a RDS i zarządza pulą połączeń z bazą danych. Jest to szczególnie przydatne w przypadku funkcji Lambda, które mogą otwierać tysiące krótkotrwałych połączeń i wyczerpywać limit połączeń bazy danych. RDS Proxy multipleksuje połączenia, dzięki czemu baza danych obsługuje znacznie mniej aktywnych połączeń.

Podczas przełączenia awaryjnego Multi-AZ RDS Proxy utrzymuje połączenia aplikacji i ponownie ustanawia połączenie z bazą danych z nową instancją podstawową, skracając czas ponownego łączenia aplikacji z minut do sekund. RDS Proxy integruje się również z Secrets Manager, aby umożliwiać rotację danych uwierzytelniających bez przestoju aplikacji.

RDS oferuje obecnie dwie opcje Multi-AZ: Multi-AZ DB Instance (klasyczna, z jedną instancją rezerwową) oraz Multi-AZ DB Cluster (dwie instancje rezerwowe z możliwością odczytu, w różnych strefach AZ). Tryb klastra korzysta z replikacji półsynchronicznej i umożliwia obsługę ruchu odczytu przez instancje rezerwowe, zapewniając wyższą dostępność i skalowalność odczytu bez konieczności używania oddzielnych replik odczytu.

Na egzaminie SAA-C03 najczęściej sprawdzana jest klasyczna opcja Multi-AZ DB Instance. Należy pamiętać: Multi-AZ Cluster to nowsza opcja, w której instancje rezerwowe mogą obsługiwać odczyty, podczas gdy klasyczna instancja rezerwowa nie może tego robić.

Sprawdź swoją znajomość zagadnień AWS Solutions Architect (SAA-C03) omówionych w tej lekcji.

W tej lekcji dowiedział się Pan / dowiedziała się Pani, że: Multi-AZ zapewnia synchroniczną replikację do instancji rezerwowej z automatycznym przełączeniem awaryjnym w ciągu 60–120 sekund, automatyczne kopie zapasowe umożliwiają PITR do dowolnej sekundy w okresie przechowywania (1–35 dni), a ręczne migawki są przechowywane bezterminowo i można je kopiować między regionami na potrzeby DR. Następnie omówimy repliki odczytu służące do rozdzielania ruchu odczytu i zwiększania przepustowości odczytu.