Migrowanie lokalnego programu MySQL do usługi Azure Database for MySQL: ocena

Artykuł
08/15/2024

DOTYCZY: Azure Database for MySQL — pojedynczy serwer usługi Azure Database for MySQL — serwer elastyczny

Wymagania wstępne

Omówienie

Przed przejściem bezpośrednio do migracji obciążenia MySQL należy wykonać pewną ilość należytej staranności. Obejmuje to analizowanie danych, środowiska hostingu i obciążeń aplikacji w celu sprawdzenia, czy strefa docelowa platformy Azure jest poprawnie skonfigurowana i przygotowana do hostowania obciążeń, które wkrótce mają zostać zmigrowane.

Ograniczenia

Usługa Azure Database for MySQL jest w pełni obsługiwaną wersją programu MySQL Community Edition działającą jako platforma jako usługa. Jednak podczas wstępnej oceny należy zapoznać się z pewnymi ograniczeniami.

Najważniejsze z nich są:

Obsługa aparatu magazynu tylko dla InnoDB i Memory
Ograniczona obsługa Privilege (DBA, SUPER, DEFINER)
Wyłączone instrukcje manipulowania danymi (SELECT ... INTO OUTFILE, LOAD DATA INFILE)
Automatyczna znacząca migracja bazy danych (od 5.6 do 5.7, od 5.7 do 8.0)
W przypadku korzystania z funkcji zdefiniowanych przez użytkownika (UDF) serwera MySQL jedyną realną opcją hostingu jest hostowana na platformie Azure maszyny wirtualne, ponieważ nie ma możliwości przekazywania so składnika lub dll do usługi Azure Database for MySQL.

Wiele innych elementów to aspekty operacyjne, z którymi administratorzy powinni zapoznać się w ramach zarządzania cyklem życia obciążenia danych operacyjnych. Ten przewodnik zawiera omówienie wielu z tych aspektów operacyjnych w sekcji Post Migration Management.

Wersje programu MySQL

MySQL ma bogatą historię od 1995 roku. Od tego czasu przekształciła się w powszechnie używany system zarządzania bazami danych. Usługa Azure Database for MySQL rozpoczęła pracę z obsługą programu MySQL w wersji 5.6 i nadal działa w wersji 5.7 i ostatnio 8.0. Aby uzyskać najnowsze informacje na temat obsługi wersji usługi Azure Database for MySQL, zapoznaj się z tematem Obsługiwane wersje serwera usługi Azure Database for MySQL. W sekcji Post Migration Management przejrzymy sposób stosowania uaktualnień (takich jak 5.7.20 do 5.7.21) do wystąpień programu MySQL na platformie Azure.

Uwaga

Skok z 5.x do 8.0 był w dużej mierze spowodowany nabyciem Oracle MySQL. Aby dowiedzieć się więcej na temat historii bazy danych MySQL, przejdź do strony typu wiki MySQL.

Znajomość źródłowej wersji programu MySQL jest niezbędna. Aplikacje korzystające z systemu mogą używać obiektów bazy danych i funkcji specyficznych dla tej wersji. Migracja bazy danych do niższej wersji może spowodować problemy ze zgodnością i utratę funkcjonalności. Zaleca się również, aby dane i wystąpienie aplikacji zostały dokładnie przetestowane przed migracją do nowszej wersji, ponieważ wprowadzone funkcje mogą spowodować przerwanie aplikacji.

Przykłady, które mogą mieć wpływ na ścieżkę migracji i wersję:

5.6: Kolumna TIMESTAMP w celu poprawnego przechowywania milisekund i wyszukiwania pełnotekstowego
5.7: Obsługa natywnego typu danych JSON
8.0: Obsługa funkcji tabel DDL i JSON w magazynie dokumentów NoSQL, niepodzielnych i awaryjnych

Uwaga

Program MySQL 5.6 traci ogólne wsparcie w lutym 2021 r. Obciążenia MySQL muszą być migrowane do programu MySQL w wersji 5.7 lub nowszej.

Aby sprawdzić wersję serwera MySQL:

SHOW VARIABLES LIKE "%version%";

Aparaty magazynu bazy danych

Usługa Azure Database for MySQL obsługuje tylko aparaty magazynu bazy danych InnoDB i Pamięci . Inne aparaty magazynujące, takie jak MyISAM, muszą zostać zmigrowane do obsługiwanego aparatu magazynu. Różnice między usługami MyISAM i InnoDB to funkcje operacyjne i dane wyjściowe wydajności. Tabele wyższego poziomu i struktura schematu zwykle nie zmieniają się między aparatami, ale typy kolumn indeksu i tabeli mogą ulec zmianie ze względów magazynowania i wydajności. Chociaż usługa InnoDB ma duże rozmiary plików danych, te szczegóły magazynu są zarządzane przez usługę Azure Database for MySQL.

Migrowanie z usługi MyISAM do bazy danych InnoDB

Baza danych i tabele MyISAM muszą zostać przekonwertowane na tabele InnoDB. Po konwersji aplikacje powinny być testowane pod kątem zgodności i wydajności. W większości przypadków testowanie wymaga ponownego utworzenia tabeli i zmiany docelowego aparatu magazynu za pomocą instrukcji DDL. Jest mało prawdopodobne, aby ta zmiana była wykonywana podczas migracji, ponieważ występuje podczas tworzenia schematu w obiekcie docelowym platformy Azure. Aby uzyskać więcej informacji, zapoznaj się z dokumentacją dotyczącą konwertowania tabel w witrynie internetowej MySQL.

Aby znaleźć przydatne informacje o tabeli, użyj tego zapytania:

    SELECT
        tab.table_schema,
        tab.table_name,
        tab.engine as engine_type,
        tab.auto_increment,
        tab.table_rows,
        tab.create_time,
        tab.update_time,
        tco.constraint_type
    FROM information_schema.tables tab
    LEFT JOIN information_schema.table_constraints tco
        ON (tab.table_schema = tco.table_schema
            AND tab.table_name = tco.table_name
            )
    WHERE
        tab.table_schema NOT IN ('mysql', 'information_schema', 'performance_
schema', 'sys')
        AND tab.table_type = 'BASE TABLE';

Uwaga

Uruchamianie zapytania względem INFORMATION_SCHEMA w wielu bazach danych może mieć wpływ na wydajność. Uruchamianie w okresach niskiego użycia.

Aby przekonwertować tabelę z usługi MyISAM na innoDB, uruchom następujące polecenie:

ALTER TABLE {table\_name} ENGINE=InnoDB;

Uwaga

Takie podejście konwersji powoduje zablokowanie tabeli, a wszystkie aplikacje mogą poczekać na zakończenie operacji. Blokowanie tabeli sprawia, że baza danych jest wyświetlana w trybie offline przez krótki okres.

Zamiast tego tabelę można utworzyć przy użyciu tej samej struktury, ale z innym aparatem magazynu. Po utworzeniu skopiuj wiersze do nowej tabeli:

INSERT INTO {table\_name} SELECT * FROM {myisam\_table} ORDER BY {primary\_key\_columns}

Uwaga

Aby ta metoda powiodła się, należy usunąć oryginalną tabelę, a następnie zmienić nazwę nowej tabeli. To zadanie powoduje krótki okres przestoju.

Dane i obiekty bazy danych

Dane są jednym ze składników migracji bazy danych. Aby zapewnić niezawodne działanie aplikacji, należy przeprowadzić migrację i zweryfikować obiekty pomocnicze bazy danych.

Oto lista elementów, które należy utworzyć przed i po migracji:

Tabele (schemat)
Klucze podstawowe, klucze obce
Indeksy
Funkcje
Procedury
Wyzwalacze
Widoki

Funkcje zdefiniowane przez użytkownika

Program MySQL umożliwia użycie funkcji wywołujących kod zewnętrzny. Niestety nie można migrować obciążeń danych korzystających z funkcji zdefiniowanych przez użytkownika (UDF) z kodem zewnętrznym do usługi Azure Database for MySQL. Dzieje się tak, ponieważ nie można przekazać kodu dll wymaganej funkcji MySQL na serwer platformy Azure.

Uruchom następujące zapytanie, aby znaleźć wszystkie funkcje zdefiniowane przez użytkownika, które mogą być zainstalowane:

SELECT * FROM mysql.func;

Systemy źródłowe

Ilość przygotowania migracji może się różnić w zależności od systemu źródłowego i jego lokalizacji. Oprócz obiektów bazy danych należy wziąć pod uwagę sposób pobierania danych z systemu źródłowego do systemu docelowego. Migrowanie danych może stać się trudne, gdy zapory i inne składniki sieciowe znajdują się między źródłem a obiektem docelowym.

Ponadto przenoszenie danych przez Internet może być wolniejsze niż używanie dedykowanych obwodów na platformę Azure. W związku z tym podczas przenoszenia wielu gigabajtów, terabajtów i petabajtów danych rozważ skonfigurowanie połączenia usługi ExpressRoute między siecią źródłową a siecią platformy Azure.

Jeśli usługa ExpressRoute jest już obecna, prawdopodobnie połączenie jest używane przez inne aplikacje. Przeprowadzenie migracji przez istniejącą trasę może spowodować obciążenie przepływności sieci i potencjalnie spowodować znaczne osiągnięcie wydajności zarówno dla migracji, jak i innych aplikacji korzystających z sieci.

Na koniec należy ocenić miejsce na dysku. Podczas eksportowania dużej bazy danych należy wziąć pod uwagę rozmiar danych. Upewnij się, że system, w którym działa narzędzie, a ostatecznie lokalizacja eksportu ma wystarczającą ilość miejsca na dysku, aby wykonać operację eksportowania.

Dostawcy usług w chmurze

Migracja baz danych od dostawców usług w chmurze, takich jak Amazon Web Services (AWS), może wymagać dodatkowego kroku konfiguracji sieci w celu uzyskania dostępu do wystąpień MySQL hostowanych w chmurze. Narzędzia migracji, takie jak Usługi migracji danych, wymagają dostępu spoza zakresów adresów IP i mogą zostać zablokowane w inny sposób.

Lokalne

Podobnie jak dostawcy usług w chmurze, jeśli obciążenie danych MySQL znajduje się za zaporami lub innymi warstwami zabezpieczeń sieci, należy utworzyć ścieżkę między wystąpieniem lokalnym i usługą Azure Database for MySQL.

Narzędzia

Wiele narzędzi i metod może służyć do oceny obciążeń i środowisk danych MySQL. Każde narzędzie udostępnia inny zestaw funkcji i funkcji oceny i migracji. W ramach tego przewodnika zapoznamy się z najczęściej używanymi narzędziami do oceny obciążeń danych MySQL.

Azure Migrate

Chociaż usługa Azure Migrate nie obsługuje bezpośrednio migrowania obciążeń bazy danych MySQL, może być używana, gdy administratorzy nie są pewni, co użytkownicy i aplikacje zużywają dane, niezależnie od tego, czy są hostowane na maszynie wirtualnej, czy sprzętowej. Analizę zależności można przeprowadzić, instalując i uruchamiając agenta monitorowania na maszynie obsługującej obciążenie MySQL. Agent zbiera informacje w określonym okresie, na przykład miesiąc. Dane zależności można analizować w celu znalezienia nieznanych połączeń z bazą danych. Dane połączenia mogą pomóc w zidentyfikowaniu właścicieli aplikacji, którzy muszą zostać powiadomieni o oczekującej migracji.

Oprócz analizy zależności aplikacji i danych łączności użytkowników usługa Azure Migrate może również służyć do analizowania serwerów funkcji Hyper-V, VMware lub serwerów fizycznych w celu zapewnienia wzorców wykorzystania obciążeń bazy danych, aby ułatwić sugerowanie odpowiedniego środowiska docelowego.

Telgraf dla systemu Linux

Obciążenia systemu Linux mogą używać programu Microsoft Monitoring Agent (MMA) do zbierania danych na maszynach wirtualnych i fizycznych. Ponadto rozważ użycie agenta Telegraf i jego szerokiej gamy wtyczek w celu zebrania metryk wydajności.

Warstwy usług

Mając informacje o ocenie (procesor CPU, pamięć, magazyn itp.), następnym wyborem użytkownika migracji jest podjęcie decyzji o tym, z której warstwy cenowej usługi Azure Database for MySQL zacząć korzystać.

Obecnie istnieją trzy warstwy:

Podstawowa: Obciążenia wymagające lekkiej wydajności obliczeniowej i operacji we/wy.
Ogólnego przeznaczenia: większość obciążeń biznesowych wymagających zrównoważonych zasobów obliczeniowych i pamięci ze skalowalną przepływnością operacji we/wy.
Zoptymalizowane pod kątem pamięci: obciążenia bazy danych o wysokiej wydajności wymagające wydajności w pamięci w celu szybszego przetwarzania transakcji i większej współbieżności.

Na decyzję warstwy mogą mieć wpływ wymagania celu czasu odzyskiwania i celu punktu odzyskiwania obciążenia danych. Jeśli obciążenie danych wymaga ponad 4 TB miejsca do magazynowania, wymagany jest dodatkowy krok. Przejrzyj i wybierz region obsługujący maksymalnie 16 TB miejsca do magazynowania.

Zazwyczaj podejmowanie decyzji koncentruje się na potrzebach magazynu i operacji we/wy na sekundę lub operacji wejścia/wyjścia na sekundę. W związku z tym system docelowy zawsze potrzebuje co najmniej tyle miejsca do magazynowania, co w systemie źródłowym. Ponadto, ponieważ operacje we/wy na sekundę są przydzielane 3/GB, ważne jest, aby dopasować operacje we/wy na sekundę do końcowego rozmiaru magazynu.

Czynników	Warstwa
Podstawowa	Maszyna programowa, nie ma potrzeby wysokiej wydajności z mniej niż 1 TB miejsca do magazynowania.
Ogólnego przeznaczenia	Wymaga większej liczby operacji we/wy na sekundę niż warstwa podstawowa, ale w przypadku magazynu mniejszego niż 16 TB i mniej niż 4 GB pamięci.
Zoptymalizowane pod kątem pamięci	Obciążenia danych wykorzystujące wysoką pamięć lub wysoką pamięć podręczną i konfigurację serwera związanego z buforem, takie jak wysoka współbieżność innodb_buffer_pool_instances, duże rozmiary obiektów BLOB, systemy z wieloma kopiami replikacji.

Koszty

Po dokonaniu oceny całych obciążeń danych WWI MySQL WWI ustalili, że potrzebują co najmniej 4 rdzeni wirtualnych i 20 GB pamięci oraz co najmniej 100 GB miejsca do magazynowania z pojemnością operacji we/wy na sekundę wynoszącą 450 operacji we/wy na sekundę. Ze względu na wymaganie dotyczące 450 operacji we/wy na sekundę muszą przydzielić co najmniej 150 GB magazynu ze względu na metodę alokacji operacji we/wy na sekundę usługi Azure Database for MySQL. Ponadto wymagają co najmniej 100% aprowizowanego magazynu serwera jako magazynu kopii zapasowych i jednej repliki do odczytu. Nie przewidują ruchu wychodzącego przekraczającego 5 GB.

Korzystając z kalkulatora cen usługi Azure Database for MySQL, WWI była w stanie określić koszty wystąpienia usługi Azure Database for MySQL. Od 9/2020 r. łączne koszty posiadania (TCO) są wyświetlane w poniższej tabeli dla bazy danych konferencji WWI.

Zasób	opis	Ilość	Koszt
Obliczenia (ogólnego przeznaczenia)	4 rdzenie wirtualne, 20 GB	1 @ $0.351/hr	$3074.76 / yr
Storage	5 GB	12 x 150 @ 0,115 USD	207 USD / yr
Tworzenie kopii zapasowych	Do 100% aprowizowanego magazynu	Brak dodatkowych kosztów do 100% aprowizowanego magazynu serwera	0,00 USD / yr
Replika do odczytu	Replika 1-sekundowego regionu	obliczenia i magazyn	$3281.76 / yr
Sieciowe	< Ruch wychodzący 5 GB/miesiąc	Bezpłatna
Łącznie			$6563.52 / yr

Po przejrzeniu początkowych kosztów dyrektor ds. systemów informatycznych WWI potwierdził, że są na platformie Azure przez dłuższy niż 3 lata. Postanowili użyć 3-letnich wystąpień rezerwowych , aby zaoszczędzić dodatkowe ~$4K/yr.

Zasób	opis	Ilość	Koszt
Obliczenia (ogólnego przeznaczenia)	4 rdzenie wirtualne	1 @ $0.1375/hr	$1204.5 / yr
Storage	5 GB	12 x 150 @ 0,115 USD	207 USD / yr
Tworzenie kopii zapasowych	Do 100% aprowizowanego magazynu	Brak dodatkowych kosztów do 100% aprowizowanego magazynu serwera	0,00 USD / yr
Sieciowe	< Ruch wychodzący 5 GB/miesiąc	Bezpłatna
Replika do odczytu	Replika 1-sekundowego regionu	obliczenia i magazyn	1411,5 USD / yr
Łącznie			$2823 / yr

Jak pokazano w powyższej tabeli, kopie zapasowe, ruch wychodzący sieci i wszystkie repliki do odczytu muszą być brane pod uwagę całkowity koszt posiadania (TCO). W miarę dodawania większej liczby baz danych wygenerowany ruch magazynu i sieci byłby jedynym czynnikiem, który należy wziąć pod uwagę.

Uwaga

Powyższe szacunki nie obejmują żadnych kosztów usługi ExpressRoute, aplikacja systemu Azure Gateway, Azure Load Balancer ani App Service dla warstw aplikacji.

Powyższe ceny mogą ulec zmianie w dowolnym momencie i różnią się w zależności od regionu.

Implikacje aplikacji

Podczas przechodzenia do usługi Azure Database for MySQL konwersja na komunikację opartą na protokole SSL (Secure Sockets Layer) prawdopodobnie będzie jedną z najważniejszych zmian w aplikacjach. Protokół SSL jest domyślnie włączony w usłudze Azure Database for MySQL i prawdopodobnie lokalna aplikacja i obciążenie danych nie jest skonfigurowane do nawiązywania połączenia z usługą MySQL przy użyciu protokołu SSL. Po włączeniu użycie protokołu SSL dodaje dodatkowe obciążenie związane z przetwarzaniem i powinno być monitorowane.

Uwaga

Mimo że protokół SSL jest domyślnie włączony, można go wyłączyć.

Postępuj zgodnie z działaniami w temacie Konfigurowanie łączności SSL w aplikacji, aby bezpiecznie nawiązać połączenie z usługą Azure Database for MySQL , aby ponownie skonfigurować aplikację w celu obsługi tej silnej ścieżki uwierzytelniania.

Na koniec zmodyfikuj nazwę serwera w aplikacji parametry połączenia lub przełącz dns, aby wskazywał nowy serwer usługi Azure Database for MySQL.

Scenariusz ii wojny światowej

WWI rozpoczęła ocenę, zbierając informacje o ich infrastrukturze danych MySQL, jak pokazano w poniższej tabeli.

Nazwisko	Lokalizacja źródłowa	Aparat bazy danych	Rozmiar	Liczba operacji we/wy na sekundę	Wersja	Właściciel	Przestój
WwwDB	AWS (PaaS)	InnoDB	1 GB	150	5.7	Dział marketingu	1 godz.
BlogDB	AWS (PaaS)	InnoDB	1 GB	100	5.7	Dział marketingu	4 godziny
Baza danych ConferenceDB	Lokalne	InnoDB	5 GB	50	5,5	Dział sprzedaży	4 godziny
CustomerDB	Lokalne	InnoDB	10 GB	75	5,5	Dział sprzedaży	2 godz.
SalesDB	Lokalne	InnoDB	20 GB	75	5,5	Dział sprzedaży	1 godz.

Każdy właściciel bazy danych skontaktował się w celu określenia akceptowalnego okresu przestoju. Wybrana metoda planowania i migracji została oparta na akceptowalnym przestoju bazy danych.

W pierwszej fazie WWI koncentrowała się wyłącznie na bazie danych ConferenceDB. Zespół potrzebował środowiska migracji, aby ułatwić kontynuowanie migracji obciążeń danych. Baza danych ConferenceDB została wybrana z powodu prostej struktury bazy danych i dużego akceptowalnego przestoju. Po zmigrowaniu bazy danych zespół skupił się na migrowaniu aplikacji do bezpiecznej strefy docelowej platformy Azure.

Lista kontrolna oceny

Testowanie obciążenia działa pomyślnie w systemie docelowym.
Upewnij się, że na potrzeby migracji znajdują się odpowiednie składniki sieciowe.
Zapoznaj się z wymaganiami dotyczącymi zasobów obciążenia danych.
Szacowanie całkowitych kosztów.
Zapoznaj się z wymaganiami dotyczącymi przestojów.
Przygotuj się do wprowadzania zmian aplikacji.

Następny krok

Planowanie

Udostępnij za pośrednictwem

Migrowanie lokalnego programu MySQL do usługi Azure Database for MySQL: ocena

Wymagania wstępne

Omówienie

Ograniczenia

Wersje programu MySQL

Aparaty magazynu bazy danych

Migrowanie z usługi MyISAM do bazy danych InnoDB

Dane i obiekty bazy danych

Funkcje zdefiniowane przez użytkownika

Systemy źródłowe

Dostawcy usług w chmurze

Lokalne

Narzędzia

Azure Migrate

Telgraf dla systemu Linux

Warstwy usług

Koszty

Implikacje aplikacji

Scenariusz ii wojny światowej

Lista kontrolna oceny

Następny krok

Opinia

Dodatkowe zasoby