Odzyskiwanie po awarii w chmurze dla MariaDB i MySQL

MySQL ma długą tradycję w replikacji geograficznej. Dystrybucja klastrów do zdalnych centrów danych zmniejsza skutki opóźnień geograficznych, przenosząc dane bliżej użytkownika. Zapewnia również możliwość odzyskiwania po awarii. Ze względu na znaczne koszty powielania sprzętu w osobnej witrynie, niewiele firm było w przeszłości na to stać. Innym kosztem jest wykwalifikowany personel, który jest w stanie zaprojektować, wdrożyć i utrzymywać wyrafinowane środowisko wielu centrów danych.

Dzięki rewolucji automatyzacji Cloud i DevOps, rozproszone centrum danych nigdy nie było bardziej dostępne dla mas. Dostawcy usług w chmurze zwiększają zakres oferowanych przez siebie usług po lepszej cenie. Można budować środowiska hybrydowe typu cross-cloud z danymi rozsianymi po całym świecie. Można tworzyć elastyczne i skalowalne plany DR, aby podejść do szerokiego zakresu scenariuszy zakłóceń. W niektórych przypadkach może to być po prostu kopia zapasowa przechowywana poza siedzibą firmy. W innych przypadkach może to być kopia 1 do 1 środowiska produkcyjnego działającego gdzie indziej.

W tym blogu przyjrzymy się niektórym z tych przypadków i omówimy typowe scenariusze.

Przechowywanie kopii zapasowych w chmurze

Plan DR to ogólny termin opisujący proces odzyskiwania zakłóconych systemów IT i innych krytycznych zasobów używanych przez organizację. Backup jest podstawową metodą osiągnięcia tego celu. Gdy kopia zapasowa znajduje się w tym samym centrum danych, co serwery produkcyjne, ryzykujesz, że wszystkie dane mogą zostać usunięte w przypadku utraty tego centrum danych. Aby tego uniknąć, powinieneś mieć zasady tworzenia kopii w innej fizycznej lokalizacji. Nadal dobrą praktyką jest przechowywanie kopii zapasowej na dysku, aby skrócić czas potrzebny na przywrócenie. W większości przypadków podstawowa kopia zapasowa będzie przechowywana w tym samym centrum danych (aby zminimalizować czas przywracania), ale powinieneś mieć również kopię zapasową, której można użyć do przywrócenia procedur biznesowych, gdy podstawowe centrum danych nie działa.

ClusterControl umożliwia bezproblemową integrację między środowiskiem bazy danych a chmurą. Zapewnia opcje migracji danych do chmury. Oferujemy pełną kombinację kopii zapasowych baz danych dla Amazon Web Services (AWS), Google Cloud Services lub Microsoft Azure. Kopie zapasowe można teraz wykonywać, planować, pobierać i przywracać bezpośrednio od wybranego dostawcy chmury. Ta zdolność zapewnia zwiększoną nadmiarowość, lepsze opcje odzyskiwania po awarii oraz korzyści zarówno pod względem wydajności, jak i oszczędności.

Pierwszym krokiem do skonfigurowania „kopii zapasowej na wypadek awarii centrum danych” jest podanie poświadczeń dla operatora chmury. Tutaj możesz wybierać spośród wielu dostawców. Rzućmy okiem na proces skonfigurowany dla najpopularniejszego operatora chmury - AWS.

Wszystko, czego potrzebujesz, to identyfikator klucza AWS i sekret regionu, w którym chcesz przechowywać kopię zapasową. Możesz to uzyskać z konsoli AWS. Możesz wykonać kilka kroków, aby to uzyskać.

1. Użyj adresu e-mail i hasła konta AWS, aby zalogować się do konsoli zarządzania AWS jako użytkownik root konta AWS.
2. Na stronie IAM Dashboard wybierz nazwę swojego konta na pasku nawigacyjnym, a następnie wybierz Moje dane uwierzytelniające .
3. Jeśli zobaczysz ostrzeżenie o dostępie do danych uwierzytelniających dla Twojego konta AWS, wybierz Przejdź do danych uwierzytelniających .
4. Rozwiń sekcję Klucze dostępu (identyfikator klucza dostępu i tajny klucz dostępu).
5. Wybierz Utwórz nowy klucz dostępu . Następnie wybierz Pobierz plik klucza aby zapisać identyfikator klucza dostępu i tajny klucz dostępu do pliku na komputerze. Po zamknięciu okna dialogowego nie będzie można ponownie odzyskać tego tajnego klucza dostępu.

Gdy wszystko jest ustawione, możesz dostosować harmonogram tworzenia kopii zapasowych i włączyć opcję tworzenia kopii zapasowych w chmurze. Aby zmniejszyć ruch w sieci, upewnij się, że włączona jest kompresja danych. Sprawia, że ​​kopie zapasowe są mniejsze i minimalizuje czas potrzebny na przesłanie. Inną dobrą praktyką jest szyfrowanie kopii zapasowej. ClusterControl automatycznie tworzy klucz i używa go, jeśli zdecydujesz się go przywrócić. Zaawansowane zasady tworzenia kopii zapasowych powinny mieć różne czasy przechowywania kopii zapasowych przechowywanych na serwerach w tym samym centrum danych i kopii zapasowych przechowywanych w innej fizycznej lokalizacji. Powinieneś ustawić dłuższy okres przechowywania dla kopii zapasowych w chmurze i krótszy okres dla kopii zapasowych przechowywanych w pobliżu środowiska produkcyjnego, ponieważ prawdopodobieństwo przywrócenia spada wraz z czasem życia kopii zapasowej.

Rozszerz swój klaster dzięki replikacji asynchronicznej

Galera z replikacją asynchroniczną może być doskonałym rozwiązaniem do budowy aktywnego węzła DR w zdalnym centrum danych. Istnieje kilka dobrych powodów, aby dołączyć asynchroniczne urządzenie podrzędne do klastra Galera. Długotrwałe zapytania typu OLAP w węźle Galera mogą spowolnić cały klaster. Dzięki opcji stosowania opóźnienia opóźniona replikacja może uchronić Cię przed błędami ludzkimi, więc wszystkie te złote wejścia nie zostaną natychmiast zastosowane w węźle zapasowym.

W ClusterControl rozszerzanie grupy węzłów Galera za pomocą replikacji asynchronicznej odbywa się za pomocą jednostronicowego kreatora. Musisz podać niezbędne informacje o swoim przyszłym lub istniejącym serwerze podrzędnym. Urządzenie podrzędne zostanie skonfigurowane z istniejącej kopii zapasowej lub świeżo przesłanego XtraBackup z urządzenia nadrzędnego do urządzenia podrzędnego.

Systemy równoważenia obciążenia w wielu centrach danych

Systemy równoważenia obciążenia są kluczowym elementem wysokiej dostępności baz danych MySQL i MariaDB. Nie wystarczy mieć klaster obejmujący wiele centrów danych. Nadal potrzebujesz swoich usług, aby uzyskać do nich dostęp. Awaria systemu równoważenia obciążenia, który jest dostępny w jednym centrum danych, spowoduje, że całe Twoje środowisko stanie się nieosiągalne.

Jedną z popularnych metod ukrywania przed aplikacją złożoności warstwy bazy danych jest użycie proxy. Serwery proxy działają jako punkt wejścia do baz danych, śledzą stan węzłów bazy danych i powinny zawsze kierować ruch tylko do dostępnych węzłów. ClusterControl ułatwia wdrażanie i konfigurowanie kilku różnych technologii równoważenia obciążenia dla MySQL i MariaDB, w tym ProxySQL, HAProxy, z interfejsem graficznym typu „wskaż i kliknij”.

Pozwala również na uczynienie tego komponentu redundantnym, dodając na nim keepalived. Aby systemy równoważenia obciążenia nie były pojedynczym punktem awarii, należy skonfigurować dwie identyczne (jedną aktywną i jedną w innym kontrolerze domeny jako rezerwową) instancje HAProxy, ProxySQL lub MariaDB Maxscale i użyć Keepalived do uruchomienia protokołu nadmiarowości routerów wirtualnych (VRRP) między ich. VRRP udostępnia wirtualny adres IP aktywnemu modułowi równoważenia obciążenia i przesyła wirtualny adres IP do rezerwowego HAProxy w przypadku awarii. Jest to bezproblemowe, ponieważ dwie instancje proxy nie wymagają stanu współdzielenia.

Oczywiście jest wiele rzeczy do rozważenia, aby Twoje bazy danych były odporne na awarie centrum danych.
Właściwe planowanie i automatyzacja sprawią, że to zadziała! Miłego klastrowania!