Jako najpopularniejsza baza danych o otwartym kodzie źródłowym, MySQL został wdrożony w wielu miejscach, od małych start-upów po bardzo duże organizacje. Przypadki użycia różnią się od prostych aplikacji internetowych po środowiska o znaczeniu krytycznym z wymaganiami dotyczącymi dostępności na poziomie 99,999%. MySQL po prostu wykonuje swoją pracę i jest łatwy w obsłudze.
Chociaż MySQL jest stosunkowo łatwy w zarządzaniu, nie działa samodzielnie. Istnieje pewien narzut związany z zarządzaniem – oprogramowanie musi być łatane od czasu do czasu, baza danych musi być monitorowana pod kątem awarii lub anomalii w wydajności lub bezpieczeństwie, awarie muszą być obsługiwane i odzyskiwane, kopie zapasowe muszą być zarządzane. lista jest długa. Nie powinno więc dziwić, że najwięksi dostawcy usług chmurowych oferują publiczne usługi DBaaS oparte na MySQL.
Trzej dostawcy usług w chmurze, którzy oferują MySQL jako usługę, to :
- Amazon Web Service z RDS dla MySQL
- Google Compute Engine z CloudSQL dla MySQL
- Microsoft Azure, Microsoft Azure MySQL
W tym blogu porównamy rozwiązania tych dostawców chmury.
Wersja i łatki MySQL
Najnowsza wersja MySQL dostępna w Amazon Web Services (AWS) to MySQL 8.0.20, która jest dość zbliżona do najnowszej wersji oficjalnego Oracle MySQL (8.0.21 w momencie pismo). Oprócz najnowszej wersji, AWS RDS udostępnia również starszą wersję MySQL (wersja główna 5.5, 5.6 i 5.7), dzięki czemu możesz wdrożyć dokładną wersję, która jest zgodna z Twoją aplikacją.
W Google Cloud Platform (GCP) wersja MySQL obsługiwana w CloudSQL dla MySQL to nadal MySQL 5.6 i 5.7, najnowsza wersja pomocnicza wydania 5.6 to 5.6.42, natomiast w przypadku wersji 5.7 najnowsza wersja podrzędna to 5.7.25.
Baza danych Azure dla MySQL obsługuje wersje 5.6, 5.7, 8.0, niestety nie udostępniają one wersji pomocniczej (lub wersji z poprawkami błędów bazy danych, jak nazywa ją platforma Azure) podczas wdrażania z konsoli. Aby określić wersję twojego serwera MySQL, możesz użyć SELECT VERSION(); polecenie w wierszu MySQL.
Znane problemy i ograniczenia
Istnieje kilka znanych problemów i ograniczeń, które istnieją w bazie danych jako usłudze, podczas gdy nie ma to miejsca w MySQL na miejscu lub w maszynach wirtualnych. W przypadku RDS niektóre ograniczenia to:
- Wtyczka MySQL keyring nie jest obsługiwana.
- Maksymalny rozmiar limitu pamięci dla tabeli to 16 TB podczas korzystania z silnika pamięci masowej InnoDB.
- Istnieją pewne parametry, które wymagają specjalnego uwzględnienia podczas korzystania z RDS, np.:long_query_time, small_case_table_name.
Istnieją pewne ograniczenia i problemy znane w CloudSQL dla MySQL, podzielone na różne kategorie, na przykład:problemy z trwałością i dostępnością danych, problemy z połączeniem instancji, problemy administracyjne oraz problemy z eksportowaniem i importowaniem danych. Każda kategoria ma określone problemy i ograniczenia, niektóre z nich to:
- Długo trwających operacji nie można anulować ani zatrzymać.
- Nazwy instancji nie mogą być używane natychmiast po usunięciu instancji.
- Klauzula DFINER spowoduje niepowodzenie importu.
Baza danych Azure dla MySQL ma pewne ograniczenia i znane problemy związane z uaktualnieniem, uprawnieniami i silnikiem magazynu. Niektóre szczegóły to:
- Większa aktualizacja bazy danych nie jest obecnie obsługiwana. Musisz zrobić zrzut i przywrócić na nowy serwer, aby dokonać poważnej aktualizacji.
- Baza danych Azure dla MySQL obsługuje obecnie silniki przechowywania InnoDB i Memory.
- Systemowa baza danych w bazie danych Azure dla MySQL jest ustawiona na tylko do odczytu. Nie możesz nic zmienić w bazie danych systemu mysql.
Musisz sprawdzić ograniczenia i znane problemy dotyczące MySQL u każdego dostawcy chmury i porównać z wymaganiami, aby zrozumieć, czy ma to wpływ na aplikację.
Kopia zapasowa i przywracanie
Amazon RDS dla MySQL uruchamia automatyczną kopię zapasową zgodnie z harmonogramem, wykonuje migawkę woluminu instancji bazy danych. Domyślny okres przechowywania kopii zapasowych to 7 dni. Co więcej, RDS przesyła dzienniki transakcji dla instancji bazy danych do S3 co 5 minut, aby zachować odzyskiwanie do określonego momentu.
Możesz przywrócić kopię zapasową do określonego punktu w czasie, tworząc nową instancję w okresie przechowywania kopii zapasowej. Możesz wybrać ostatni możliwy do przywrócenia czas, aby przywrócić najpóźniejszy możliwy czas, lub możesz wybrać niestandardowy, aby zdefiniować konkretny czas przywracania danych.
Kopia zapasowa wykonywana w CloudSQL dla MySQL jest przyrostowa. Zawiera tylko zmiany danych po poprzedniej kopii zapasowej. Najstarsza kopia zapasowa jest zbliżona do obecnego rozmiaru bazy danych. Po usunięciu najstarszej kopii zapasowej zwiększa się rozmiar następnej najstarszej kopii zapasowej, dzięki czemu pełna kopia zapasowa nadal istnieje.
Automatyczna kopia zapasowa jest wykonywana codziennie i domyślnie jest zachowywana przez 7 dni. CloudSQL przechowuje dane kopii zapasowych w 2 regionach w celu zapewnienia nadmiarowości. Jeden region może znajdować się w tym samym, w którym działa instancja, a drugi w innym regionie.
Odzyskiwanie punktu w czasie w CloudSQL utworzy nową instancję, ustawienie instancji będzie dziedziczyć ze źródłem instancji. Zanim wykonasz odzyskiwanie do punktu w czasie, upewnij się, że masz już włączone logowanie binarne. Kiedy wykonujesz odzyskiwanie do punktu w czasie, wystarczy wpisać nazwę dziennika binarnego i pozycję odzyskiwania.
Baza danych Azure dla MySQL zawiera kopie zapasowe plików danych i dzienniki transakcji. Sam harmonogram tworzenia kopii zapasowych jest kombinacją pełnej i różnicowej kopii zapasowej dla serwerów o pojemności do 4 TB, podczas gdy tworzenie migawek odbywa się dla maksymalnie 16 TB serwera pamięci masowej.
Pełna kopia zapasowa jest uruchamiana raz w tygodniu, podczas gdy różnicowe kopie zapasowe są wykonywane dwa razy dziennie. Domyślny okres przechowywania kopii zapasowej wynosi 7 dni, ale zawsze możesz skonfigurować przechowywanie do 35 dni.
Istnieją dwa rodzaje przywracania w bazie danych Azure dla MySQL, a mianowicie:
- Przywracanie do określonego punktu w czasie, dostępne jako opcja kopii zapasowej nadmiarowości lub możesz utworzyć nowy serwer w tym samym regionie, co oryginalny serwer, wykorzystując pełną kopię zapasową i dziennik transakcji do przywracania danych.
- Przywracanie geograficzne, dostępne po skonfigurowaniu nadmiarowości geograficznej w opcji przechowywania. Umożliwi to przywrócenie kopii zapasowej w różnych regionach.
Pamiętaj, że ani AWS, Google ani Azure nie pozwalają na pobieranie kopii zapasowych.
Monitorowanie bazy danych
RDS zapewnia integrację monitorowania z CloudWatch, możesz zobaczyć niektóre metryki, takie jak wykorzystanie procesora, połączenia z bazą danych, IOPS zapisu i odczytu IOPS, przepustowość zapisu i odczytu, opóźnienia zapisu i odczytu. Możesz utworzyć alarm, aby wyzwolić alert z CloudWatch, na podstawie niektórych kategorii metryk i po prostu zdefiniuj próg.
Podobnie do RDS, GCP CloudSQL integruje się również ze stackdriver, możesz zobaczyć takie metryki jak:wykorzystanie procesora, wykorzystanie pamięci, aktywne połączenia, transakcje/s, bajty przychodzące/wychodzące, operacje zapisu i odczytu, opóźnienie replikacji .
Baza danych Azure dla MySQL zapewnia pewne metryki, np.; Aktywne połączenia, procent procesora, nieudane połączenie, procent we/wy, procent pamięci, opóźnienie replikacji, procent pamięci, wykorzystana pamięć. Możesz także tworzyć alerty w bazach danych Azure dla MySQL, wybierać metryki i definiować reguły.
Wnioski
Na podstawie 4 kluczowych obszarów; Wersja i poprawki MySQL, znane problemy i ograniczenia, kopie zapasowe i przywracanie, monitorowanie baz danych, moim zdaniem Amazon RDS dla MySQL jest nadal najlepszą bazą danych jako usługa dla MySQL. Zawiera szczegółowe wersje i poprawki, bardzo ograniczone problemy i ograniczenia w porównaniu z innymi. Jest to wygodny sposób uruchamiania MySQL, z zastrzeżeniem, że cena usługi wzrosła w ostatnich latach.
