Zagadnienia dotyczące migracji

  • 24 min

System biznesowy działający lokalnie może mieć architekturę połączoną z innymi usługami działającymi w tym samym środowisku. Ważne jest, aby zrozumieć relacje między systemem, który chcesz migrować, a innymi aplikacjami i usługami używanymi obecnie przez organizację.

W firmie produkującej technologię baza danych dostawcy jest używana do zapewnienia, że składniki są zawsze w magazynie i dostarczane just-in-time do użytku w procesie produkcyjnym. Kontrolery magazynowe używają urządzeń przenośnych do aktualizowania tej bazy danych w miarę przybywania przesyłek, a kupujący używają witryny internetowej do monitorowania poziomów zapasów i identyfikowania najlepszego czasu zamówienia. Menedżerowie używają zestawu raportów krytycznych dla działania firmy do monitorowania procesu i poprawy wydajności. Chcesz mieć pewność, że żaden z tych użytkowników nie ma negatywnego wpływu na migrację na platformę Azure.

W tym miejscu dowiesz się, jak zaplanować i wykonać bezproblemową migrację bazy danych do chmury.

Badanie zależności

W złożonym systemie składnik rzadko działa niezależnie. Zamiast tego wykonuje wywołania do innych procesów i składników. Na przykład bazy danych mogą zależeć od usług katalogowych hostujących konta użytkowników. Czy po przeniesieniu bazy danych do chmury możesz uzyskać dostęp do tej usługi katalogowej? Jeśli nie, jak użytkownicy będą się logują? Jeśli przeoczysz taką zależność, może wystąpić całkowita awaria bazy danych.

Aby ograniczyć ryzyko, sprawdź, czy baza danych zależy od usług, takich jak:

  • Usługi katalogowe, takie jak Active Directory.
  • Inne magazyny podmiotów zabezpieczeń.
  • Inne bazy danych.
  • Internetowe interfejsy API lub inne usługi sieciowe.

Należy również pamiętać, że inne składniki mogą zależeć od bazy danych. Jakie są konsekwencje w przypadku przeniesienia bazy danych bez ponownej konfiguracji składników zależnych? Jeśli na przykład przeniesiesz bazę danych katalogu produktów, a publiczna witryna internetowa zależy od niej, aby określić, jakie produkty mają być prezentowane użytkownikom, czy przeniesienie spowoduje przerwę w działaniu usługi?

Sprawdź, czy którykolwiek z tych typów składników zależy od bazy danych:

  • Witryny internetowe i internetowe interfejsy API.
  • Aplikacje klienckie, takie jak aplikacje mobilne i oprogramowanie klasyczne.
  • Inne bazy danych.
  • Raporty.
  • Magazyny danych.

Aby przeprowadzić te kontrole, porozmawiaj z uczestnikami projektu, administratorami i deweloperami zaangażowanymi w każdą bazę danych i składnik systemu. Zapoznaj się z dokumentacją, jeśli nie masz pewności, że rozumiesz zachowanie systemów, rozważ uruchomienie testów, takich jak przechwytywanie sieci w celu obserwowania zachowania.

Przygotowanie do powrotu

W każdym projekcie migracji zawsze należy przygotować się na awarię. W projekcie migracji bazy danych do chmury najgorszą ostatecznością jest to, że nowa baza danych stanie się niedostępna, a użytkownicy nie mogą wykonywać swoich zadań. Typowym rozwiązaniem jest ograniczenie tego ryzyka, które może mieć duży wpływ na rentowność firmy, planując wycofanie się z oryginalnej, niezmodyfikowanej bazy danych lokalnie.

W przypadku planu rezerwowego należy wziąć pod uwagę następujące kwestie:

  • Jak upewnić się, że możesz wrócić do bazy danych, która jest nietknięta przez nieudaną migrację? Na przykład zdecydowanie zaleca się wykonanie pełnej kopii zapasowej bazy danych tuż przed rozpoczęciem migracji.
  • Jak długo dopuszczalne jest, aby baza danych była w trybie offline, jeśli musisz wrócić?
  • Ile budżetu masz dla planu rezerwowego? Na przykład można sobie pozwolić na replikowanie bazy danych do dedykowanego rezerwowego serwera? Jeśli tak, możesz wyłączyć ten serwer tuż przed migracją. Aby wrócić, należy uruchomić ten serwer. Natychmiast baza danych, której migracja nie ma wpływu na migrację, bez konieczności przywracania jej z kopii zapasowej.

Migracja w trybie offline a online

Aby przeprowadzić migrację bazy danych, masz co najmniej dwie opcje:

Uwaga

Opcja online nie jest obecnie dostępna dla baz danych MySQL w usłudze Data Migration Service.

  • Zatrzymaj system, przetransferuj bazę danych, a następnie skonfiguruj ponownie i uruchom ponownie system, aby użyć nowej bazy danych. Jest to migracja w trybie offline.
  • Zachowaj działanie systemu podczas przenoszenia bazy danych do nowej lokalizacji, przerzucaj transakcje wykonywane względem oryginalnej bazy danych do nowej bazy danych podczas kontynuowania migracji, a następnie przełącz aplikacje w celu nawiązania połączenia z nową bazą danych. Jest to migracja online.

Łatwiej jest przeprowadzić migrację w trybie offline, w której użytkownicy nie mogą zmieniać danych podczas migracji. Jeśli jednak baza danych jest zajęta lub krytyczna dla sukcesu organizacji, może to być niemożliwe.

Migracja w trybie offline

Załóżmy, że baza danych obsługuje zespół analityków, którzy pracują w jednej strefie czasowej w normalnych godzinach pracy. Zespół zwykle nie pracuje w weekendy. Od 18:00 w piątek do 9:00 w niedzielę baza danych nie jest często używana.

W takiej sytuacji można przeprowadzić migrację offline w weekend, wykonując następujące kroki:

  1. Przełącz bazę danych w tryb offline, po zakończeniu wszystkich transakcji w piątek wieczorem.
  2. Wykonaj pełną kopię zapasową lub eksport bazy danych.
  3. Zamknij serwer lokalny i zachowaj go na wypadek konieczności powrotu.
  4. Przywróć bazę danych w docelowym systemie chmury.
  5. Przełącz system docelowy w tryb online.
  6. Skonfiguruj ponownie klientów w celu nawiązania połączenia z bazą danych w chmurze.

W takim przypadku migracja w trybie offline jest możliwa, ponieważ występuje długi okres, gdy przerwa w działaniu usługi ma niewielki wpływ na użytkowników. W tym czasie można wykonać pełną kopię zapasową i przywrócić bazę danych, wiedząc, że nie przegapisz żadnych zmian.

Migracje online

Teraz rozważ inną bazę danych, która obsługuje aplikację sprzedaży. Pracownicy działu sprzedaży są dystrybuowani na całym świecie, a także pracują w weekendy. Nie ma okresu niskiej aktywności, baza danych jest zawsze zajęta, a jeśli baza danych zostanie przełączona do trybu offline przez dłuższy czas, wpłynie to na użytkowników. Aktywność sprzedaży ma krytyczne znaczenie dla działania biznesowego, więc przerwa w działaniu usługi będzie miała bezpośredni wpływ na wyniki organizacji.

W takich przypadkach rozważ przeprowadzenie migracji online. W przypadku migracji online przestój jest ograniczony do czasu przełączenia się do nowej bazy danych. Użyj narzędzia, takiego jak usługa Azure Data Migration Service, aby przeprowadzić migrację online. Migracje online mają następujące różnice w migracjach w trybie offline:

  • Nie przenosisz oryginalnej bazy danych w tryb offline przed wykonaniem kopii zapasowej lub eksportu.
  • Podczas gdy migracja jest w toku, zmiany dotyczą starej bazy danych.
  • Narzędzie migracji gwarantuje, że te zmiany zostaną skopiowane do nowej bazy danych przed przełączeniem. Jest to często osiągane przez ponowne skonfigurowanie starej bazy danych w celu replikowania zmian do nowej bazy danych.

Migracja aplikacji

Jak (i kiedy) po przeprowadzeniu migracji bazy danych należy przeciąć do nowego systemu i zaktualizować aplikacje, aby korzystały z nowej bazy danych? Możesz:

  • Przenieś aplikacje jeden po jednym do nowej bazy danych.
  • Przenoszenie podzbiorów użytkowników.
  • Zastosuj kombinację obu podejść.

Celem jest przeprowadzenie migracji aplikacji na małych etapach, które można łatwo wycofać, jeśli coś pójdzie nie tak. Niezależnie od tego, czy wykonano podejście offline, czy online do migracji bazy danych, nadal powinna istnieć działająca konfiguracja znajdująca się w oryginalnym źródle. Teoretycznie będzie można szybko przełączyć się z powrotem do oryginalnego źródła. Jeśli jednak dane stale się zmieniają, należy rozważyć, gdzie wprowadzono te zmiany.

  • Podczas migracji w trybie offline źródła i miejsca docelowe są niezależne od siebie. Użytkownicy i aplikacje mogą już nie widzieć spójnego widoku danych. W systemie transakcyjnym sytuacja ta może być niedopuszczalna. W takim przypadku należy zachować jakąś formę replikacji dwukierunkowej między bazami danych, podczas gdy oba systemy pozostają aktywne. Alternatywnie, jeśli celem aplikacji jest generowanie raportów miesięcznych lub cotygodniowych, generowanie prognoz sprzedaży lub wykonywanie innych operacji statystycznych, ten brak spójności może nie być tak niepokojący. Takie aplikacje mają "długi widok" danych, a nie zależą od aktualnych danych. W tym ostatnim przypadku aplikacje transakcyjne używają nowej bazy danych, natomiast aplikacje raportowania są przenoszone wolniej.
  • Podczas migracji online nowa baza danych jest synchronizowana ze starym, zwykle przez jakąś formę replikacji. Proces replikacji może być asynchroniczny, więc może wystąpić opóźnienie. Jednak zmiany wprowadzone w danych w nowej bazie danych nie będą propagowane z powrotem do starego, co skutkuje możliwymi konfliktami. Aplikacja działająca względem starej bazy danych może spowodować konfliktową zmianę danych, które zostały zmodyfikowane w nowej bazie danych. Replikacja w sposób ślepy zastąpi zmianę w nowej bazie danych, co spowoduje "utratę aktualizacji".

Podejścia do testowania

Jeśli baza danych odgrywa kluczową rolę w firmie, konsekwencje awarii mogą być rozległe. Aby zwiększyć pewność, że tak się nie stanie, rozważ uruchomienie testów wydajnościowych względem zmigrowanej bazy danych, aby upewnić się, że poradzi sobie z obciążeniami użytkowników, którzy mogą umieścić je i szybko zareagować. Pamiętaj, że mogą występować okresy szczytowej aktywności, gdy popyt jest znacznie wyższy niż normalnie. Upewnij się, że zmigrowany system obsługuje oczekiwane obciążenie.

Zawsze przeprowadzaj testy regresji względem nowej bazy danych przed zezwoleniem na dostęp do użytkowników. Te testy zweryfikują, czy zachowanie i funkcjonalność systemu są poprawne.

Ponadto należy rozważyć uruchomienie "testu moczenia". Test moczenia jest testem obciążeniowym zaprojektowanym w celu sprawdzenia, w jaki sposób system jako całość działa pod ciśnieniem. Test moczenia podkreśla nową bazę danych i określa, czy jest ona stabilna pod dużym zapotrzebowaniem. Test moczenia działa w znacznym czasie, aby zobaczyć, co się stanie, gdy wysokie zapotrzebowanie utrzymuje się.

Po ustaleniu, że nowy system jest stabilny, możesz rozpocząć migrację użytkowników. Może jednak być konieczne dodatkowe zapewnienie, że użytkownicy znajdą nowy system do zaakceptowania. W tym momencie możesz rozważyć "testowanie kanarowe". Test kanarowy w sposób niewidoczny kieruje niewielki podzbiór użytkowników do nowego systemu, ale nie jest świadomy, że uzyskuje do niego dostęp. Jest to forma testu ślepego, która umożliwia znalezienie wszelkich problemów lub problemów z nowym systemem. Monitoruj odpowiedzi od tych użytkowników i wprowadź wymagane zmiany.

Obsługa systemów równoległych

Istnieje kilka powodów, dla których można uruchomić starą lokalną bazę danych równolegle z nową bazą danych w chmurze:

  • Okresy testowania. Jak pokazano w poprzednim temacie, dobrym pomysłem jest uruchomienie testów kanarowych względem zmigrowanej bazy danych w celu oceny jej funkcjonalności, stabilności i pojemności przed użyciem jej do obsługi osób. Utrzymywanie systemu lokalnego równolegle zapewnia szybki sposób przywracania użytkowników do starego systemu, jeśli występują problemy z nowym systemem.

  • Migracje etapowe. Jednym ze sposobów ograniczenia wpływu nieoczekiwanych awarii w środowisku produkcyjnym jest przeniesienie niewielkiej liczby użytkowników do nowego systemu i monitorowanie wyników. Jeśli wszystkie działają bezproblemowo, możesz przenieść inne grupy użytkowników, ponieważ zyskujesz zaufanie do nowej bazy danych. Użytkownicy można przenosić alfabetycznie, według działu, lokalizacji lub roli, dopóki nie będą one znajdować się w nowej bazie danych.

  • Migracje częściowe. Innym podejściem jest segmentowanie migracji nie według użytkownika, ale według obciążenia. Można na przykład zmigrować tabele baz danych, które obsługują zasoby ludzkie, przed tymi, które obsługują sprzedaż.

We wszystkich tych przypadkach występuje okres, w przypadku gdy stara lokalna baza danych działa równolegle z nową bazą danych w chmurze. Należy upewnić się, że zmiany wprowadzone w starej bazie danych są również stosowane do nowej bazy danych i że przepływają w przeciwnym kierunku. Możesz utworzyć skrypt synchronizacji lub użyć narzędzia takiego jak Usługa Azure Data Migration Service.

Jeśli zdecydujesz się zachować równoległe bazy danych i zsynchronizować zmiany, zadaj sobie następujące pytania:

  • Rozwiązywanie konfliktów. Czy prawdopodobnie zmiana wiersza w środowisku lokalnym odbywa się w podobnym czasie do innej zmiany w tym samym wierszu w chmurze? Spowodowałoby to konflikt, w którym nie jest jasne, która zmiana powinna zostać zachowana. Jak można rozwiązać takie konflikty?

  • Ruch sieciowy. Ile ruchu sieciowego zostanie wygenerowany podczas synchronizowania zmian między bazami danych? Czy masz wystarczającą pojemność sieci dla tego ruchu?

  • Opóźnienie. Jeśli istnieje zmiana w jednej z baz danych, jakie opóźnienie (jeśli istnieje) jest akceptowalne, zanim zmiana osiągnie inną bazę danych? Na przykład w katalogu produktów możesz poczekać do dnia, zanim nowe produkty będą widoczne dla wszystkich użytkowników. Jeśli jednak baza danych zawiera krytyczne informacje transakcyjne, takie jak kursy wymiany walut, dane te powinny być synchronizowane znacznie częściej, jeśli nie są natychmiast.

Migracja fragmentów

Migracja częściowa polega na podzieleniu kompletnego systemu na obciążenia i migracji jednego obciążenia naraz.

Wiele baz danych

Złożony system może zawierać wiele baz danych, które obsługują kilka obciążeń. Na przykład zasoby ludzkie mogą używać bazy danych StaffDB , podczas gdy zespół sprzedaży może mieć aplikacje mobilne, które wysyłają zapytania do bazy danych ProductCatalogDB i bazy danych OrdersDB .

Oczywiście możesz przeprowadzić migrację całego systemu bazy danych do chmury w jednym kroku. Może to być prostsze, ponieważ nie trzeba uruchamiać baz danych zarówno lokalnie, jak i w chmurze. Nie musisz brać pod uwagę sposobu komunikowania się tych baz danych podczas migracji. Jednak ryzyko awarii jest wyższe. Pojedynczy problem może mieć wpływ zarówno na zespół kadr, jak i zespół ds. sprzedaży.

Rozważ ograniczenie tych zagrożeń dla średnich i dużych systemów baz danych, wykonując migrację fragmentacyjną, w której jednocześnie przenosisz jedno obciążenie. W tym przykładzie można najpierw rozważyć migrację bazy danych StaffDB , ponieważ problemy związane z niepowodzeniem byłyby ograniczone do zespołu kadr i nie uniemożliwiłyby przyjmowania zamówień. Rozwiązując wszelkie problemy związane z migracją bazy danych StaffDB , dowiesz się, jak korzystać z innych migracji obciążeń.

Następnie można pomyśleć o migracji obciążenia wykazu produktów do chmury. Jeśli to zrobisz, rozważ następujące pytania:

  • Jak upewnić się, że nowo dodane produkty do katalogu są dostępne do zamówienia?
  • Czy musisz zsynchronizować jakiekolwiek dane z bazą danych OrdersDB , która pozostaje lokalna?
  • Jakie opóźnienie jest akceptowalne dla nowych produktów, aby uzyskać dostęp do bazy danych OrdersDB z katalogu produktów?

Migracje fragmentów pojedynczej bazy danych

Nawet jeśli masz tylko jedną bazę danych, która obsługuje wszystkie obciążenia, nadal możesz rozważyć migrację fragmentacyjną. Możesz na przykład podzielić bazę danych na fragmenty w następujący sposób:

  • Tabele, które obsługują operacje kadrowe.
  • Tabele, które obsługują sprzedaż.
  • Tabele obsługujące analizę i raportowanie.

Jeśli najpierw zmigrujesz tabele operacji KADR, każdy problem, który wystąpi tylko na personel działu kadr. Analitycy sprzedaży i danych nadal pracują nad starą bazą danych bez przerwy.

Przed przeprowadzeniem migracji częściowej należy w pełni zrozumieć bazy danych i sposób ich użycia przez aplikacje. Na przykład niektóre tabele w bazie danych mogą obsługiwać zarówno sprzedaż, jak i raportowanie. Oznacza to, że nie można łatwo podzielić obciążeń. Te tabele należy zsynchronizować między bazami danych lokalnych i w chmurze, dopóki wszystkie obciążenia nie zostaną zmigrowane.

Kwestie dotyczące bezpieczeństwa

Bazy danych mogą zawierać poufne dane, takie jak szczegóły produktu, informacje o pracownikach osobistych i szczegóły płatności, więc bezpieczeństwo jest zawsze wysokim priorytetem. Musisz zdecydować, jak chronić te dane podczas migracji i w nowej bazie danych.

Ochrona zapory

W aplikacji połączonej z Internetem serwery baz danych są zwykle chronione przez co najmniej dwie zapory. Pierwsza zapora oddziela Internet od serwerów frontonu — jeśli na przykład te serwery hostuje witryny internetowe lub internetowe interfejsy API. Tylko port TCP 80 powinien być otwarty na zewnętrznej zaporze, ale ten port musi być otwarty dla wszystkich źródłowych adresów IP, z wyjątkiem zablokowanych adresów.

Druga zapora oddziela serwery frontonu od serwerów baz danych. Zaleca się opublikowanie usługi bazy danych na prywatnym numerze portu, który nie jest znany światu zewnętrznemu. W drugiej zaporze otwórz ten numer portu tylko dla adresów IP serwerów frontonu. Takie rozwiązanie zapobiega bezpośredniej komunikacji ze strony złośliwego użytkownika internetowego na serwerach baz danych.

Jeśli planujesz migrację serwerów baz danych do maszyn wirtualnych platformy Azure, użyj sieci wirtualnej z sieciowymi grupami zabezpieczeń w celu replikowania reguł zapory. Jeśli używasz usługi Azure Database for MySQL, Azure Database for MariaDB lub Azure Database for PostgreSQL, możesz utworzyć reguły zapory w celu ochrony bazy danych przy użyciu strony zabezpieczeń Połączenie ion dla serwera w witrynie Azure Portal.

Uwierzytelnianie i autoryzacja

W większości baz danych należy ściśle kontrolować, kto uzyskuje dostęp do danych i modyfikuje je. Ta kontrolka wymaga, aby użytkownicy zostali pozytywnie zidentyfikowani podczas nawiązywania połączenia z bazą danych. Ten proces jest nazywany uwierzytelnianiem i zwykle odbywa się przy użyciu nazwy użytkownika i hasła. Systemy baz danych, takie jak MySQL, MariaDB i PostgreSQL, zapewniają własne mechanizmy uwierzytelniania. Podczas migracji systemów do chmury należy się upewnić, że użytkownicy będą nadal bezpiecznie uwierzytelniani.

Uwaga

Usługi Azure Database for MySQL, Azure Database for MariaDB i Azure Database for PostgreSQL emulują tradycyjne uwierzytelnianie MySQL, MariaDB i PostgreSQL.

Gdy wiesz, kim jest użytkownik, musisz przypisać im uprawnienia do wykonywania zadań, które są częścią zadania podrzędnego. Ten proces jest nazywany autoryzacją.

W przypadku projektu migracji bazy danych należy upewnić się, że użytkownicy są prawidłowo autoryzowani w bazie danych w chmurze:

  1. Dowiedz się, gdzie konta użytkowników są przechowywane w systemie lokalnym. W bazie danych MySQL konta użytkowników są zwykle przechowywane w user tabeli mysql bazy danych, ale można na przykład zintegrować je z kontami użytkowników przechowywanymi w usłudze Active Directory.

  2. Pobierz listę wszystkich kont użytkowników. Na przykład w programie MySQL można użyć następującego polecenia:

    SELECT host, user FROM mysql.user;

  3. Dla każdego konta użytkownika dowiedz się, jaki dostęp ma do bazy danych. Na przykład w programie MySQL można użyć tego polecenia dla dbadmin@on-premises-host konta użytkownika:

    SHOW GRANTS FOR 'dbadmin'@'on-premises-host';

  4. Utwórz ponownie każde konto użytkownika w bazie danych w chmurze. Na przykład w programie MySQL można użyć tego polecenia, aby utworzyć nowe konto:

    CREATE USER 'dbadmin'@'cloud-host'

  5. Autoryzuj każde konto użytkownika do poprawnego poziomu dostępu w bazie danych w chmurze. Na przykład w programie MySQL można użyć tego polecenia, aby umożliwić użytkownikowi dostęp do pełnej bazy danych:

    GRANT USAGE ON *.* TO 'dbadmin'@'cloud-host'

Szyfrowanie

W miarę wysyłania danych przez sieć może zostać przechwycony przez tak zwany atak "man-in-the-middle". Aby temu zapobiec, zarówno usługi Azure Database for MySQL, Azure Database for MariaDB, jak i Azure Database for PostgreSQL obsługują protokół Secure Sockets Layer (SSL) w celu szyfrowania komunikacji. Protokół SSL jest domyślnie wymuszany i zdecydowanie zaleca się, aby nie zmieniać tego ustawienia.

Może być konieczne zmianę ustawień połączenia aplikacji klienckich w celu korzystania z szyfrowania SSL. Omówić ten temat z deweloperami, aby określić zmiany, jeśli istnieją, które są niezbędne.

Monitorowanie i zarządzanie

Częścią planowania migracji bazy danych jest rozważenie, w jaki sposób administratorzy baz danych będą nadal wykonywać swoje zadania po migracji.

Monitorowanie

Lokalni administratorzy baz danych są przyzwyczajeni do regularnego monitorowania w celu wykrycia problemów, takich jak wąskie gardła sprzętu lub rywalizacja o dostęp do sieci. Monitorują one, aby upewnić się, że mogą rozwiązać wszelkie problemy przed wpływem produktywności. Możesz oczekiwać, że każda baza danych, która nie jest regularnie monitorowana, aby rozpocząć rozwiązywanie problemów wcześniej lub później.

Należy podjąć dokładnie takie samo podejście do baz danych w chmurze. Rozwiązywanie problemów w systemie PaaS, takich jak platforma Azure, może być łatwiejsze, ponieważ można dodawać zasoby bez kupowania, konfigurowania i konfigurowania dowolnego sprzętu. Jednak nadal trzeba wykrywać problemy, więc monitorowanie jest wysokim priorytetem wśród codziennych zadań.

Przed migracją baz danych do chmury dowiedz się, jakie narzędzia do monitorowania są obecnie używane przez administratorów. Jeśli te narzędzia są zgodne z proponowanym rozwiązaniem opartym na chmurze, może być konieczne ponowne połączenie ich z migrowanych baz danych. Jeśli nie, należy zbadać alternatywy.

Należy pamiętać, że platforma Azure zawiera zestaw narzędzi do monitorowania wydajności i zbiera szeroką gamę liczników wydajności i danych dzienników. Te dane są wyświetlane przy użyciu pulpitów nawigacyjnych i wykresów w witrynie Azure Portal, konfigurując usługę Azure Monitor. Grafy niestandardowe, tabele i raporty są tworzone specjalnie dla potrzeb administratorów.

Zarządzanie

Administratorzy bazy danych używają preferowanych narzędzi do zmiany schematu i zawartości lokalnej bazy danych. Jeśli korzystają z tych samych narzędzi po migracji, możesz nadal korzystać ze swojej wiedzy. Zacznij od oceny, czy istniejący zestaw narzędzi jest zgodny z proponowaną bazą danych hostowaną w chmurze. Wiele narzędzi będzie zgodnych, ponieważ są one oparte na powszechnie przyjętych standardach, takich jak SQL, ale ważne jest, aby sprawdzić zgodność. Jeśli bieżące narzędzia do zarządzania nie będą działać po migracji, spróbuj zidentyfikować alternatywy dla administratorów.

Platforma Azure obejmuje kilka narzędzi, których można użyć do administrowania bazami danych MySQL, MariaDB i PostgreSQL:

  • Witryna Azure Portal. Ta witryna internetowa ma zaawansowane funkcje używane do konfigurowania, monitorowania i zarządzania bazami danych oraz wszystkich innych zasobów, które można utworzyć w chmurze platformy Azure.

  • Azure PowerShell. Jest to środowisko wykonywania skryptów i język, który ma szeroki zestaw poleceń. Użyj programu PowerShell, który jest dostępny dla środowisk systemu Windows i Linux, aby zautomatyzować złożone zadania administracyjne bazy danych.

  • Interfejs wiersza polecenia platformy Azure. Jest to interfejs wiersza polecenia dla platformy Azure. Służy do zarządzania usługami i zasobami na platformie Azure. Interfejs wiersza polecenia można używać w środowiskach powłoki systemu Windows i Linux oraz z poziomu skryptów powłoki Bash.