Porównanie RDS i EC2 do zarządzania MySQL lub MariaDB na AWS

RDS to baza danych jako usługa (DBaaS), która automatycznie konfiguruje i utrzymuje bazy danych w chmurze AWS. Użytkownik ma ograniczoną władzę nad określonymi konfiguracjami w porównaniu do uruchamiania MySQL bezpośrednio w Elastic Compute Cloud (EC2). Ale RDS to wygodna usługa, o ile możesz żyć z instancjami i konfiguracjami, które oferuje.

Amazon RDS obecnie obsługuje różne wersje MySQL i MariaDB, a także zgodny z MySQL silnik Amazon Aurora DB. Obsługuje replikację, ale jak można się spodziewać po predefiniowanej konsoli internetowej, istnieją pewne ograniczenia.

Korzystanie z RDS wiąże się z pewnymi kompromisami. Mogą one wpływać nie tylko na sposób, w jaki zarządzasz instancjami baz danych i udostępnianie ich, ale także na kluczowe rzeczy, takie jak wydajność, bezpieczeństwo i wysoka dostępność.

W tym blogu przyjrzymy się różnicom między używaniem RDS a uruchomieniem MySQL na EC2, z naciskiem na replikację. Jak zobaczymy, decyzja między hostowaniem MySQL na instancji EC2 a korzystaniem z Amazon RDS nie jest łatwym zadaniem.

Kompromisy dotyczące platformy RDS

Największy rozmiar bazy danych, jaką może hostować AWS, zależy od środowiska źródłowego, alokacji danych w źródłowej bazie danych i obciążenia systemu.

AWS jest podzielony na regiony. Każde konto AWS ma limity, na region, dotyczące liczby zasobów AWS, które można utworzyć. Po osiągnięciu limitu zasobu dodatkowe wywołania w celu utworzenia tego zasobu zakończą się niepowodzeniem.

W przypadku instancji Amazon RDS MySQL DB maksymalny alokowany limit pamięci ogranicza rozmiar tabeli do maksymalnego rozmiaru 6 TB podczas korzystania z obszarów tabel InnoDB file-per-table.

Funkcja InnoDB file-per-table to coś, co powinieneś rozważyć, nawet jeśli nie chcesz migrować dużej bazy danych do chmury. Możesz zauważyć, że niektóre istniejące instancje DB mają niższy limit. Na przykład instancje MySQL DB utworzone przed kwietniem 2014 r. mają limit rozmiaru plików i tabel wynoszący 2 TB. Ten limit rozmiaru pliku wynoszący 2 TB dotyczy również instancji DB lub replik do odczytu utworzonych z migawek DB wykonanych przed kwietniem 2014 r.

Jedną z kluczowych różnic wpływających na sposób konfiguracji i utrzymania replikacji bazy danych jest brak SUPER użytkownika. Aby rozwiązać ten problem, Amazon wprowadził procedury składowane, które zajmują się różnymi zadaniami DBA. Poniżej znajdują się kluczowe procedury zarządzania replikacją MySQL RDS.

Pomiń błąd replikacji:

CALL mysql.rds_skip_repl_error;

Zatrzymaj replikację:

CALL mysql.rds_stop_replication;

Rozpocznij replikację

CALL mysql.rds_start_replication;

Konfiguruje instancję RDS jako replikę do odczytu instancji MySQL działającej poza AWS.

CALL mysql.rds_set_external_master;

Ponownie konfiguruje instancję MySQL, aby nie była już repliką do odczytu instancji MySQL działającej poza AWS.

CALL mysql.rds_reset_external_master;

Importuje certyfikat. Jest to potrzebne, aby umożliwić komunikację SSL i szyfrowaną replikację.

CALL mysql.rds_import_binlog_ssl_material;

Usuwa certyfikat.

CALL mysql.rds_remove_binlog_ssl_material;

Zmienia pozycję dziennika głównego replikacji na początek następnego dziennika binarnego w systemie głównym.

CALL mysql.rds_next_master_log;

Podczas gdy procedury składowane zajmują się wieloma zadaniami, jest to trochę krzywa uczenia się. Brak uprawnień SUPER może również powodować problemy w korzystaniu z zewnętrznego monitorowania replikacji.

Amazon RDS nie obsługuje obecnie:

• Globalne identyfikatory transakcji
• Przenośna przestrzeń stołowa
• Wtyczka uwierzytelniania
• Wtyczka siły hasła
• Filtry replikacji
• Replikacja półsynchroniczna

Last but not least - dostęp do powłoki. Amazon RDS nie zezwala na bezpośredni dostęp hosta do instancji bazy danych przez Telnet, Secure Shell (SSH) lub Windows Remote Desktop Connection (RDP). Nadal możesz używać klienta na hoście aplikacji do łączenia się z bazą danych za pomocą standardowych narzędzi, takich jak klient mysql.

Istnieją inne ograniczenia opisane w dokumentacji RDS.

Wysoka dostępność dzięki MySQL w EC2

Aby zautomatyzować zadania wdrażania i zarządzania/konserwacji (przy zachowaniu kontroli), można użyć ClusterControl. Podobnie jak w przypadku RDS, masz wygodę wdrożenia konfiguracji bazy danych w kilka minut za pomocą graficznego interfejsu użytkownika. Dodawanie węzłów, planowanie kopii zapasowych, przełączanie awaryjne itp. można również wygodnie wykonać za pomocą GUI. Istnieją opcje obsługi MySQL bezpośrednio w EC2, a tym samym zachowania kontroli nad opcjami wysokiej dostępności. Idąc tą drogą, ważne jest, aby zrozumieć, jak wykorzystać różne funkcje AWS, które są do Twojej dyspozycji. Sprawdź naszą białą księgę „DIY Cloud Database”.

Wdrożenie

ClusterControl może zautomatyzować wdrażanie różnych konfiguracji baz danych o wysokiej dostępności — od replikacji master-slave po klastry z wieloma masterami. Obsługiwane są wszystkie główne odmiany MySQL - Oracle MySQL, MariaDB i Percona Server. Wymagana jest początkowa konfiguracja VPC/grupy bezpieczeństwa, które są dobrze opisane w białej księdze DIY Cloud Database. Pamiętaj, że obowiązują podobne koncepcje, niezależnie od tego, czy jest to AWS, Google Cloud czy Azure

Galera Cluster to dobra alternatywa do rozważenia podczas wdrażania wysoce dostępnej usługi MySQL. Jest wiarygodnym zamiennikiem tradycyjnych architektur typu master-slave MySQL, chociaż nie jest zamiennikiem typu drop-in. Większość aplikacji można nadal dostosować do działania na nim. Możliwe jest zdefiniowanie różnych segmentów dla baz danych, które obejmują wiele regionów AWS.

Możliwe jest skonfigurowanie „replikacji hybrydowej” poprzez połączenie replikacji synchronicznej w ramach klastra Galera i replikacji asynchronicznej między klastrem a jednym lub większą liczbą urządzeń podrzędnych. Opcje takie jak opóźnienie niewolnika zapewniają dodatkowy poziom ochrony danych.

Warstwa proxy

Aby osiągnąć wysoką dostępność, wdrożenie konfiguracji o wysokiej dostępności nie wystarczy. Aplikacje muszą jakoś wiedzieć, które węzły działają, a które nie. Zmiany w topologii, m.in. przeniesienie mastera na inny host, również trzeba je jakoś propagować, aby uniknąć błędów w warstwie aplikacji. ClusterControl obsługuje wdrożenia serwerów proxy, takich jak HAProxy, MaxScale i ProxySQL. W przypadku HAProxy i ProxySQL istnieją dodatkowe opcje wdrażania nadmiarowych instancji z Keepalived i VirtualIP.

Replika międzyregionalna

Amazon RDS zapewnia usługi replikacji odczytu. Repliki międzyregionalne dają możliwość skalowania odczytów, ponieważ AWS ma swoje usługi w wielu centrach danych na całym świecie. Wszystkie repliki do odczytu są dostępne i można ich używać do odczytu w maksymalnie pięciu regionach. Te węzły są niezależne i mogą być używane w ścieżce aktualizacji lub mogą być promowane do samodzielnych baz danych.

Oprócz tego Amazon oferuje wdrożenia Multi-AZ oparte na DRBD, synchronicznej replikacji dysków. Czym różni się od Read Replicas? Główna różnica polega na tym, że aktywny jest tylko silnik bazy danych w podstawowej instancji, co prowadzi do innych zmian architektonicznych.

W przeciwieństwie do replik do odczytu, uaktualnienia wersji silnika bazy danych mają miejsce na podstawowym. Kolejną różnicą jest to, że AWS RDS przełączy się automatycznie w tryb awaryjny z DRBD, podczas gdy repliki do odczytu (przy użyciu replikacji asynchronicznej) będą wymagały od Ciebie ręcznych operacji.

Przełączanie awaryjne Multi-AZ na RDS wykorzystuje zmianę DNS w celu wskazania instancji rezerwowej, według Amazon powinno to nastąpić w ciągu 60-120 sekund podczas przełączania awaryjnego. Ponieważ rezerwa korzysta z tych samych danych, co pamięć podstawowa, prawdopodobnie nastąpi odzyskiwanie transakcji/dziennika. Większe bazy danych mogą spędzać znaczną ilość czasu na odzyskiwaniu InnoDB, więc weź to pod uwagę w swoim planie DR i obliczeniach RTO.

Oczywiście wiąże się to z dodatkowymi kosztami. Rzućmy okiem na podstawowy przykład. Koszt hosta db.t2.medium z 2vCPU, 4GB pamięci RAM to 185,98 USD miesięcznie, cena podwoi się po włączeniu repliki Multizone (MZ) do 370,98 UDB. Cena będzie się różnić w zależności od regionu, ale podwoi się w MZ.

Aby osiągnąć to samo dzięki EC2, możesz wdrożyć swoje maszyny wirtualne w różnych regionach. Każdy region AWS jest całkowicie niezależny. Ustawienie regionu AWS można zmienić w konsoli, ustawiając zmienną środowiskową EC2_REGION, lub można je zastąpić za pomocą parametru --region z interfejsem wiersza poleceń AWS. Gdy zestaw serwerów jest gotowy, możesz użyć ClusterControl do wdrożenia i monitorowania replikacji. Możesz także ręcznie skonfigurować replikację za pomocą konsoli, używając standardowych poleceń.

Replikacja między technologiami

Możliwe jest skonfigurowanie replikacji między instancją Amazon RDS MySQL lub MariaDB DB a instancją MySQL lub MariaDB zewnętrzną względem Amazon RDS. Odbywa się to za pomocą standardowej metody replikacji w mysql, poprzez logi binarne. Aby włączyć logi binarne, musisz zmodyfikować konfigurację my.cnf. Bez dostępu do powłoki to zadanie stało się niemożliwe w RDS. Odbywa się to w nie tak oczywisty sposób. Masz dwie opcje. Jednym z nich jest włączenie kopii zapasowych — ustaw automatyczne kopie zapasowe na swojej instancji Amazon RDS DB z retencją wyższą niż 0. Lub włącz replikację na wstępnie zbudowanym serwerze podrzędnym. Oba zadania umożliwią włączenie dzienników binarnych, które można później wykorzystać do replikacji.

Przechowuj dzienniki binarne w instancji głównej, dopóki nie upewnisz się, że zostały one zastosowane w replice. Ta konserwacja zapewnia możliwość przywrócenia instancji głównej w przypadku awarii.

Kolejną przeszkodą mogą być uprawnienia. Uprawnienia wymagane do rozpoczęcia replikacji w instancji Amazon RDS DB są ograniczone i niedostępne dla użytkownika głównego Amazon RDS. Z tego powodu należy użyć poleceń Amazon RDS mysql.rds_set_external_master i mysql.rds_start_replication, aby skonfigurować replikację między bieżącą bazą danych a bazą danych Amazon RDS.

Monitoruj zdarzenia przełączania awaryjnego dla instancji Amazon RDS, która jest Twoją repliką. Jeśli nastąpi przełączenie awaryjne, instancja bazy danych, która jest twoją repliką, może zostać odtworzona na nowym hoście z innym adresem sieciowym. Aby uzyskać informacje na temat monitorowania zdarzeń przełączania awaryjnego, zobacz Korzystanie z powiadomień o zdarzeniach Amazon RDS.

W poniższym przykładzie zobaczymy, jak włączyć replikację z RDS do zewnętrznej bazy danych znajdującej się na instancji EC2.
Powinieneś mieć włączone logi binarne, używamy tutaj urządzenia podrzędnego RDS.

Określ liczbę godzin przechowywania dzienników binarnych.

mysql -h RDS_MASTER -u<username> -u<password>
call mysql.rds_set_configuration('binlog retention hours', 7);

W RDS MASTER utwórz użytkownika replikacji za pomocą następujących poleceń:

CREATE USER 'repl'@'ec2DBslave' IDENTIFIED BY 's3cr3tp4SSw0rd';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'ec2DBslave';

Na RDS SLAVE uruchom polecenia:

mysql -u<username> -u<password> -h RDS_SLAVE
call mysql.rds_stop_replication;
SHOW SLAVE STATUS;  Exec_Master_Log_Pos, Relay_Master_Log_File.

Na RDS SLAVE uruchom mysqldump w następującym formacie:

mysqldump -u<username> -u<password> -h RDS_SLAVE --routines --triggers --single-transaction --databases DB1 DB2 DB3 > mysqldump.sql

Zaimportuj zrzut bazy danych do zewnętrznej bazy danych:

mysql -u<username> -u<password> -h ec2DBslave
tee import_database.log;
source mysqldump.sql;

CHANGE MASTER TO 
 MASTER_HOST='RDS_MASTER', 
 MASTER_USER='repl',
 MASTER_PASSWORD='s3cr3tp4SSw0rd',
 MASTER_LOG_FILE='<Relay_Master_Log_File>',
 MASTER_LOG_POS=<Exec_Master_Log_Pos>;

Utwórz filtr replikacji, aby ignorować tabele utworzone przez AWS tylko w RDS

CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE = ('mysql.rds\_%');

Rozpocznij replikację

START SLAVE;

Sprawdź stan replikacji

SHOW SLAVE STATUS;

Na razie to wszystko. Zarządzanie MySQL na AWS to duży temat. Podziel się z nami swoimi przemyśleniami w sekcji komentarzy poniżej.