Fazy i zagadnienia dotyczące migracji

  • 8 min

Pomyślna migracja równoważy zagadnienia w kilku fazach.

Fazy migracji

Migracje występują w kilku fazach. Najpierw zaplanuj zakres migracji: odnajdywanie i ocenę zasobów bazy danych, wymagania biznesowe, takie jak przestoje i plan powrotu, jeśli migracja nie powiedzie się. Następnie przygotuj migrację, aprowizuj odpowiednie zasoby i skonfiguruj łączność między środowiskami źródłowymi i docelowymi. Po ustawieniu podejścia do migracji zasoby są gotowe, zazwyczaj chcesz przeprowadzić suche uruchomienie w środowisku przejściowym, aby zidentyfikować problemy przed migracją produkcyjną. Na koniec przeprowadź ostateczną migrację i zweryfikuj jej ciągły postęp i pomyślne zakończenie.

Zrzut ekranu przedstawiający fazy migracji.

Ten moduł koncentruje się na fazach przygotowania (2) i ostatecznej migracji (4, 5).

Zagadnienia dotyczące migracji

Należy ocenić wymagania dotyczące przestojów aplikacji, zgodności wersji, sieci i zabezpieczeń, wydajności, kosztów i ciągłości działania.

Zrzut ekranu przedstawiający listę zagadnień dotyczących migracji.

Przestój aplikacji

Jedną z pierwszych kwestii, które należy wziąć pod uwagę, jest to, jak wiele przestojów może obsłużyć twój scenariusz biznesowy. Odpowiedź zdecydowanie ogranicza dostępne opcje migracji.

Najlepszy przestój jest taki, który użytkownicy nie zauważają. W praktyce migracje są złożonymi procedurami, a decyzje dotyczące zagadnień w tym module będą dyktować wymagany przestój. Kompromisy obejmują dostępność w porównaniu z kosztami i ryzykiem migracji. Ze względu na złożoność związaną z ograniczeniem przestoju do minut lub nawet sekund ważne jest przetestowanie założeń i określenie, ile przestojów migracji jest akceptowalne.

Migracja w trybie offline

W przypadku migracji w trybie offline należy zamknąć aplikację, aby przenieść bazę danych. Gwarantuje to, że podczas migracji nie zostaną wprowadzone żadne zmiany w danych. Jednak takie podejście wymaga zamknięcia bazy danych w celu sfinalizowania eksportu danych. Co najmniej przestój będzie trwał tak długo, jak trwa transfer danych. Migracja w trybie offline obejmuje:

  1. Odłączanie wszystkich aplikacji od źródłowej bazy danych.
  2. Eksportowanie zawartości źródłowej bazy danych.
  3. Importowanie danych źródłowych do docelowej bazy danych.
  4. Ponowne łączenie aplikacji z docelową bazą danych po zakończeniu importowania.

Niektóre aplikacje mają zaplanowane okna obsługi w okresach niskiego ruchu. Są to doskonałe czasy na przeprowadzenie migracji w trybie offline.

Migracja przyrostowa w trybie offline zmniejsza przestoje, przenosząc większość danych przed przełączeniem aplikacji w tryb offline. Najpierw zmigruj pełną kopię zapasową bazy danych. Następnie przeprowadź migrację zmian do bazy danych, która wystąpiła od poprzedniej migracji. Gdy czas wymagany do migracji tych nowych zmian mieści się w akceptowalnym przestoju, przełącz aplikację w tryb offline, aby zablokować dane i sfinalizować migrację. Może się okazać, że pojedyncza przyrost migracji wystarczy, aby zmniejszyć czas przestoju o kolejność wielkości lub więcej, zwłaszcza w przypadku baz danych z latami historii. W przypadku dużych i zajętych baz danych może być konieczne przeprowadzenie migracji kilku przyrostów, aby osiągnąć akceptowalny przestój.

Migracje online

Dzięki migracji online można znacznie zmniejszyć lub nawet wyeliminować konieczność przestoju przez replikowanie zmian z serwera źródłowego do serwera docelowego podczas migracji, a następnie przecięcie na serwer docelowy, gdy replikacja jest w pełni zsynchronizowana.

Czasami przestój jest niepożądany lub nawet niedopuszczalny. W takim przypadku nie można "zablokować" stanu bazy danych, wyłączając aplikację. Zamiast tego źródłowa baza danych jest replikowana do docelowej bazy danych podczas normalnych operacji. Gdy element docelowy jest w pełni uwikłany w źródło, aplikacja przecięła docelową bazę danych.

Migracja online wymaga wykonania następujących czynności:

  1. Rozpocznij replikowanie źródłowej bazy danych do docelowej bazy danych.
  2. Gdy docelowa baza danych zostanie przechwycona, zamrozić źródłową bazę danych przez wstrzymanie aplikacji lub wymuszenie niepowodzenia zapisu przez włączenie trybu tylko do odczytu.
  3. Gdy docelowa baza danych jest w 100% uwikłana w zmiany, wyłącz replikację w obiekcie docelowym.
  4. Przekieruj wszystkich klientów do docelowej bazy danych i wznawiaj operacje.
  5. Zamknij starszą źródłową bazę danych.

Porównanie migracji w trybie online i offline

Podczas gdy migracje w trybie offline wymagają przestoju, technika migracji przyrostowej omówiona wcześniej znacznie zmniejsza przestoje. Wiele przyrostów może zmniejszyć ostateczną migrację do dziennej wartości danych lub mniej. Zautomatyzowane usługi, takie jak Azure DMS, minimalizują przestoje, wykonując serię coraz mniejszych migracji. Migracje przyrostowe w trybie offline można również wykonać ręcznie, jeśli ustawienia sieciowe uniemożliwiają automatyzację.

Migracje online koordynują delikatną operację między zespołami baz danych i aplikacji. Aplikacje klienckie muszą być narzędziem, aby bezpiecznie reagować na błędy zapisu, aby uniknąć utraty danych podczas migracji. Klienci muszą również obsługiwać nawiązywanie połączenia z nowym serwerem bazy danych bez przerywania działania użytkownika. Jeśli to narzędzie aplikacji jeszcze nie istnieje, kompilacja może być dość kosztowna.

Zgodność wersji

Większość operacji aplikacji jest zgodna z uaktualnieniami bazy danych MySQL. Jednak w niektórych przypadkach składniki aplikacji lub użycie bazy danych mogą działać tylko z niektórymi wersjami programu MySQL.

Sprawdź, czy wszystkie składniki aplikacji są zgodne z docelową wersją bazy danych. Rozważ oddzielenie uaktualnień wersji od migracji, które przenoszą lub konfigurują ponownie bazę danych. Jeśli na przykład migracja z lokalnego programu MySQL 5.7 do elastycznego serwera usługi Azure Database for MySQL z uruchomionym programem MySQL 8.0 należy rozważyć migrację ze środowiska lokalnego do elastycznego serwera usługi Azure Database for MySQL z uruchomionym programem MySQL 5.7, a następnie uaktualnienie z wersji 5.7 do 8.0 w miejscu.

Sieć i zabezpieczenia

Migracje baz danych wymagają przesyłania danych ze źródłowej bazy danych do miejsca docelowego. Jak to się stanie i jak szybko zależy w dużej mierze od połączenia między dwiema sieciami. Jeśli nie możesz ustanowić połączenia na żywo ze źródła do miejsca docelowego, musisz przenieść pliki danych fizycznych w inny sposób, na przykład za pośrednictwem pośredniej stacji roboczej lub serwera. W takim przypadku upewnij się, że masz wystarczającą ilość miejsca na dysku, aby przechowywać migawki w każdym systemie po drodze.

Ważne jest również, aby wziąć pod uwagę wymagania dotyczące zabezpieczeń podczas migracji. Będziesz potrzebować odpowiedniego uwierzytelniania i uprawnień do źródłowych i docelowych baz danych. Możesz również utworzyć konta usług, aby wykonać niektóre lub wszystkie kroki migracji, a następnie usunąć ich dostęp po zakończeniu.

Niezależnie od tego, czy źródłowa baza danych jest lokalna, czy znajduje się w innym dostawcy usług w chmurze, ustawienia sieciowe zwykle nie zezwalają na połączenia zewnętrzne. Należy skonfigurować sieć tak, aby zezwalała na połączenia z platformą Azure.

Jeśli źródłowa baza danych jest lokalna, a wolumin danych jest duży, przenoszenie terabajtów danych za pośrednictwem zwykłego połączenia internetowego może być niepraktyczne. W tym scenariuszu rozważ skonfigurowanie połączenia usługi Azure ExpressRoute między siecią a platformą Azure.

Nawet jeśli używasz usługi ExpressRoute, połączenie, na którym jest włączone, prawdopodobnie będzie również obsługiwać inny ruch, a oba te połączenia mogą zakłócać wzajemnie. W zależności od rywalizacji wydajność aplikacji i proces migracji może być znaczący.

Wydajność

Migracje baz danych to doskonała okazja do zwiększenia pojemności przez zmianę rozmiaru infrastruktury. Użycie bazy danych może korzystać ze zwiększonego użycia procesora CPU, pamięci RAM lub operacji we/wy.

Przed aprowizowaniem serwera docelowego należy wziąć pod uwagę bieżące użycie bazy danych. Monitoruj metryki wydajności, takie jak użycie procesora CPU, wraz z prognozowanym wzrostem i umowami SLA, aby zdecydować, czy należy przydzielić większy rozmiar obliczeniowy. Z drugiej strony może się okazać, że pojemność jest nadmiernie alokowana, i że obniżanie rozmiaru pozwala zaoszczędzić koszty.

Koszt

Podczas migracji na platformę Azure możesz skorzystać z przezroczystych cen. Korzystając z wybranej jednostki SKU i innych parametrów, takich jak nadmiarowość i wysoka dostępność, kalkulator cen platformy Azure umożliwia oszacowanie kosztów po migracji podczas planowania. Możesz również użyć kalkulatora, aby poinformować o kompromisach, takich jak dostępność i koszt.

Ciągłość działalności biznesowej

Migracje baz danych to dobry moment na zapoznanie się z metrykami i celami ciągłości działania. Zmiana zasad przechowywania kopii zapasowych może być odpowiednia lub przejście na geograficznie nadmiarowe kopie zapasowe lub wysoką dostępność. Rozważ historyczny czas pracy w porównaniu z umową SLA i czasem odzyskiwania po awarii. Migracje zawierają również rzeczywiste przykłady tworzenia nowej bazy danych z plików danych fizycznych, które mogą informować o planach odzyskiwania po awarii.