Automatyczne migrowanie w miejscu z usługi Azure Database for MySQL — pojedynczy serwer do serwera elastycznego

DOTYCZY: Azure Database for MySQL — pojedynczy serwer

Ważne

Niektóre wystąpienia pojedynczego serwera mogą wymagać obowiązkowych danych wejściowych w celu pomyślnego automigracji w miejscu. Przejrzyj szczegóły migracji w bloku Migracja w witrynie Azure Portal, aby podać te dane wejściowe. Brak obowiązkowych danych wejściowych 2 dni przed zaplanowaną migracją spowoduje ponowne zaplanowanie migracji do późniejszej daty.

Automatyczna migracja w miejscu z usługi Azure Database for MySQL — pojedynczy serwer do serwera elastycznego to migracja w miejscu inicjowana przez usługę podczas zaplanowanego okna obsługi dla obciążeń bazy danych pojedynczego serwera z włączoną jednostką SKU Podstawowa, Ogólnego przeznaczenia lub Zoptymalizowana pod kątem pamięci oraz bez złożonych funkcji (replika do odczytu, sieć wirtualna, podwójne szyfrowanie infra, punkt końcowy usługi/reguły sieci wirtualnej). Kwalifikujące się serwery są identyfikowane przez usługę i wysyłane jest do nich wcześniejsze powiadomienie zawierające szczegółowe informacje o krokach mających na celu przejrzenie szczegółów migracji.

Migracja w miejscu zapewnia wysoce odporne i samonaprawialne środowisko migracji w trybie offline podczas planowanego okna obsługi z krótszym niż 5 minut przestojów dla jednostki SKU ogólnego przeznaczenia i zoptymalizowanej pod kątem pamięci oraz do 30 minut dla jednostki SKU w warstwie Podstawowa. Używa technologii tworzenia kopii zapasowych i przywracania w celu szybszego czasu migracji. Ta migracja usuwa obciążenie, aby ręcznie przeprowadzić migrację serwera i zapewnić, że możesz skorzystać z zalet serwera elastycznego, w tym lepszych cen i wydajności, szczegółowej kontroli nad konfiguracją bazy danych i niestandardowych okien obsługi. Poniżej opisano kluczowe fazy migracji:

• Docelowy serwer elastyczny jest wdrażany, dziedzicząc wszystkie właściwości i zestaw funkcji (w tym parametry serwera i reguły zapory) ze źródłowego pojedynczego serwera. Źródłowy pojedynczy serwer jest ustawiony na opcję tylko do odczytu, a kopia zapasowa ze źródłowego pojedynczego serwera jest kopiowana do docelowego serwera elastycznego.
• Przełącznik DNS i migracja jednorazowa są wykonywane pomyślnie w ramach planowanego okna obsługi z minimalnym przestojem, co pozwala na konserwację tego samego parametry połączenia po migracji. Aplikacje klienckie bezproblemowo łączą się z docelowym serwerem elastycznym bez konieczności ręcznej aktualizacji sterowanych przez użytkownika. Oprócz obu formatów parametry połączenia (pojedynczy i elastyczny serwer) obsługiwanych na migrowanym serwerze elastycznym oba formaty nazw użytkowników — username@server_name i nazwa użytkownika są również obsługiwane na zmigrowanym serwerze elastycznym.
• Zmigrowany serwer elastyczny jest w trybie online i można go teraz zarządzać za pośrednictwem witryny Azure Portal/interfejsu wiersza polecenia. Zatrzymany pojedynczy serwer zostanie usunięty siedem dni po migracji.

Uwaga

Jeśli wystąpienie pojedynczego serwera ma podstawową jednostkę SKU, zaplanowane wystąpienie zostanie zmigrowane z oknem przestoju do 30 minut. Wystąpienie zostanie zmigrowane do wyższej jednostki SKU ogólnego przeznaczenia w celu zapewnienia pomyślnej migracji i zostanie zmniejszone do jednostki SKU z możliwością zwiększenia wydajności w ciągu 24–48 godzin. Jeśli po migracji do jednostki SKU z możliwością rozszerzenia wystąpień zabraknie środków z powodu dużego obciążenia procesora CPU, rozważ uaktualnienie do jednostki SKU ogólnego przeznaczenia w wystąpieniu serwera elastycznego.

Uwaga

Jeśli wystąpienie pojedynczego serwera ma magazyn ogólnego przeznaczenia w wersji 1, zaplanowane wystąpienie przejdzie dodatkową operację ponownego uruchamiania 12 godzin przed zaplanowanym czasem migracji. Ta operacja ponownego uruchamiania służy do włączenia parametru serwera log_bin wymaganego do uaktualnienia wystąpienia do magazynu ogólnego przeznaczenia w wersji 2 przed przejściem automatycznej migracji w miejscu.

Uprawnienie

Jeśli jesteś właścicielem obciążenia pojedynczego serwera bez złożonych funkcji (replika do odczytu, sieć wirtualna, podwójne szyfrowanie infra, punkt końcowy usługi/reguły sieci wirtualnej), możesz teraz nominować siebie (jeśli nie zostało to jeszcze zaplanowane przez usługę) na potrzeby automigracji, przesyłając szczegóły serwera za pośrednictwem biletu pomocy technicznej platformy Azure.

Aby zapewnić, że serwer niekwalifikowalny kwalifikuje się do automatycznej migracji, wykonaj następujące kroki:

• Wystąpienie pojedynczego serwera powinno być w stanie gotowości i nie powinno być w stanie zatrzymania podczas planowanego okna obsługi w celu przeprowadzenia automigracji.
• Jeśli źródłowy pojedynczy serwer usługi Azure Database for MySQL ma wersję aparatu w wersji 8.x, upewnij się, że uaktualnij sterownik klienta .NET serwera źródłowego do wersji 8.0.32, aby uniknąć niezgodności kodowania po migracji do serwera elastycznego.
• Jeśli źródłowy pojedynczy serwer usługi Azure Database for MySQL ma wersję aparatu w wersji 8.x, upewnij się, że uaktualnij wersję protokołu TLS serwera źródłowego z wersji 1.0 lub 1.1 do protokołu TLS w wersji 1.2 przed migracją, ponieważ starsze wersje protokołu TLS zostały uznane za przestarzałe dla serwera elastycznego.
• Jeśli serwer ma repliki do odczytu, upuść repliki do odczytu. Repliki do odczytu można skonfigurować po automatycznej migracji.
• Jeśli serwer ma włączone punkty końcowe usługi (reguły sieci wirtualnej) lub konfigurację sieci wirtualnej, rozważ usunięcie ich lub przejście do funkcji usługi Private Link w wystąpieniu pojedynczego serwera.
• Jeśli serwer ma włączone podwójne szyfrowanie infrastruktury, rozważ przejście do funkcji Klucz zarządzany przez klienta (CMK) w wystąpieniu pojedynczego serwera.

Konfigurowanie alertów migracji

Serwery kwalifikujące się do automigracji w miejscu są wysyłane z wyprzedzeniem przez usługę.

Poniżej opisano sposoby sprawdzania i konfigurowania powiadomień automigracji:

• Właściciele subskrypcji dla pojedynczych serwerów zaplanowanych na potrzeby automigracji otrzymują powiadomienie e-mail.
• Skonfiguruj alerty dotyczące kondycji usługi, aby otrzymywać harmonogram migracji w miejscu i powiadomienia o postępie za pośrednictwem poczty e-mail/wiadomości SMS, wykonując kroki opisane tutaj.
• Aby wykonać kroki, zapoznaj się z powiadomieniem o migracji w miejscu w witrynie Azure Portal.

Przeglądanie i konfigurowanie harmonogramu i szczegółów migracji

Poniżej opisano sposoby przeglądania harmonogramu migracji po otrzymaniu powiadomienia automatycznego automigracji w miejscu:

Uwaga

Harmonogram migracji jest zablokowany 2 dni przed zaplanowanym oknem migracji, po którym nie będzie można ponownie zaplanować.

• Strona przeglądu pojedynczego serwera dla wystąpienia wyświetla baner portalu z informacjami o harmonogramie migracji.

• W przypadku pojedynczych serwerów zaplanowanych na potrzeby automigracji nowy blok Migracja jest włączony w portalu. Harmonogram migracji można przejrzeć, przechodząc do bloku Migracja wystąpienia pojedynczego serwera.

• Jeśli chcesz odroczyć migrację, możesz odroczyć przez miesiąc w danym momencie, przechodząc do bloku Migracja pojedynczego wystąpienia serwera w witrynie Azure Portal i ponownie konfigurując migrację, wybierając kolejne okno migracji w ciągu miesiąca.

• Jeśli pojedynczy serwer ma jednostkę SKU ogólnego przeznaczenia, możesz włączyć wysoką dostępność podczas przeglądania harmonogramu migracji. Ponieważ wysoka dostępność może być włączona tylko w czasie tworzenia serwera elastycznego MySQL, zdecydowanie zaleca się włączenie tej funkcji podczas przeglądania harmonogramu migracji.

• Jeśli wystąpienie pojedynczego serwera ma co najmniej jeden klucz prywatny, klucz zarządzany przez klienta (CMK) i administrator firmy Microsoft Entra włączone, automatyczna migracja w miejscu wymaga obowiązkowych danych wejściowych dla prywatnych punktów końcowych, cmK i microsoft Entra Admin, które mają zostać zmigrowane z wystąpienia pojedynczego serwera do docelowego wystąpienia serwera elastycznego. Dane wejściowe użytkownika muszą być podane 2 dni przed zaplanowanym oknem migracji. Jeśli dane wejściowe użytkownika nie zostaną podane przed zablokowaniem szczegółów migracji, migracja zostanie ponownie zaplanowana do późniejszego punktu w czasie. Po podaniu wszystkich danych wejściowych upewnij się, że konfiguracja zostanie zapisana w kreatorze automatycznej migracji. Kroki umożliwiające podanie danych wejściowych użytkownika:

  • Przejdź do bloku Migracja wystąpienia pojedynczego serwera i wybierz pozycję Edytuj zaplanowaną migrację.
  • W sekcji Szczegóły automatycznej migracji kliknij przycisk Uwierzytelnij, aby uwierzytelnić i zapisać połączenie interfejsu API usługi ARM w celu przeprowadzenia migracji serwera.
  • Jeśli serwer ma skonfigurowaną usługę Microsoft Entra Admin, możesz podać dane wejściowe w sekcji Microsoft Entra Admin w kreatorze automatycznej migracji:
    • Migrowanie administratora usługi Microsoft Entra dla serwera docelowego wymaga dodania tożsamości do usługi Azure Database for MySQL — serwer elastyczny. Tożsamość wymaga udzielenia następujących uprawnień — User.Read.All, GroupMember.Read.All i Application.Read.All . Wybierz odpowiednią tożsamość zarządzaną przypisaną przez użytkownika i przyznaj odpowiednie uprawnienia, wykonując kroki opisane tutaj.
  • Jeśli serwer ma skonfigurowany klucz zarządzany przez klienta, możesz podać dane wejściowe w sekcji Szyfrowanie danych w kreatorze automatycznej migracji:
    • Migrowanie szyfrowania kluczy zarządzanych przez klienta wymaga dodania tożsamości do usługi Azure Database for MySQL — serwer elastyczny. Wybierz odpowiednią tożsamość zarządzaną przypisaną przez użytkownika. Wymieniony identyfikator klucza/klucz zostanie zmigrowany ze źródła do serwera docelowego i powinien mieć następujące uprawnienia — Get, Wrap Key, Unwrap Key w celu uzyskania dostępu do magazynu kluczy.
  • Jeśli pojedynczy serwer ma prywatne punkty końcowe, wykonaj następujące obowiązkowe kroki podczas przeglądania harmonogramu migracji co najmniej 2 dni przed zaplanowaną migracją:
    • Przejrzyj prywatne punkty końcowe wymienione do zmigrowania. Upewnij się, że są one oznaczone jako Gotowe do migracji. Jeśli są one oznaczone jako niekwalifikowane, wybierz odpowiednią subskrypcję i prywatną strefę DNS.
      • Niestandardowa strefa Prywatna strefa DNS nie jest obsługiwana przez automatyczną migrację. Strefa Prywatna strefa DNS musi być privatelink.mysql.database.azure.com.
      • Metoda zatwierdzania połączeń prywatnych punktów końcowych powinna być ustawiana jako automatyczne zatwierdzanie, a nie ręczne zatwierdzanie. Prywatne punkty końcowe zatwierdzania ręcznego nie są obsługiwane przez automatyczną migrację.
    • Upewnij się, że masz dostęp do roli Współautor na poziomie subskrypcji lub grupy zasobów, aby uniknąć problemów z uprawnieniami podczas uwierzytelniania.
    • Zaznacz pole wyboru potwierdzenia po wykonaniu wymienionych testów wymagań wstępnych dotyczących migrowania prywatnych punktów końcowych.

  Uwaga

  Jeśli obowiązkowe dane wejściowe migracji nie zostaną dostarczone co najmniej 2 dni przed zaplanowaną migracją, migracja zostanie ponownie zaplanowana na późniejszą datę.

  Uwaga

  W przypadku wystąpienia pojedynczego serwera z prywatnymi punktami końcowymi usuń walidację po migracji wystąpienia źródłowego pojedynczego serwera. Jeśli nie zostanie wykonana żadna operacja usuwania serwera, wystąpienie źródłowe będzie utrzymywane do 14 dni po usunięciu przez usługę.

Sprawdzanie wymagań wstępnych dotyczących automigracji w miejscu

Zapoznaj się z następującymi wymaganiami wstępnymi, aby zapewnić pomyślną automigrację w miejscu:

• Wystąpienie pojedynczego serwera powinno być w stanie gotowości i nie powinno być w stanie zatrzymania podczas planowanego okna obsługi w celu przeprowadzenia automigracji.
• Parametry, ustawienia, konfiguracja i reguły zapory wystąpienia pojedynczego serwera nie powinny być aktualizowane w ciągu 2 dni przed zaplanowanym automigration.
• W przypadku wystąpienia pojedynczego serwera z włączonym protokołem SSL upewnij się, że masz wszystkie trzy certyfikaty (BaltimoreCyberTrustRoot, DigiCertGlobalRootG2 główny urząd certyfikacji i główny urząd certyfikacji DigiCertGlobalRootCA) dostępne w zaufanym magazynie głównym. Ponadto, jeśli masz certyfikat przypięty do parametry połączenia utworzyć połączony certyfikat urzędu certyfikacji ze wszystkimi trzema certyfikatami przed zaplanowaną automatyczną migracją w celu zapewnienia ciągłości działania po migracji.
• Aparat MySQL nie gwarantuje żadnej kolejności sortowania, jeśli w zapytaniach nie ma klauzuli "SORT". Po automigracji w miejscu możesz zaobserwować zmianę w kolejności sortowania. Jeśli zachowanie kolejności sortowania ma kluczowe znaczenie, upewnij się, że zapytania są aktualizowane w celu uwzględnienia klauzuli "SORT" przed zaplanowaną automigracji w miejscu.
• Jeśli źródłowy pojedynczy serwer usługi Azure Database for MySQL ma wersję aparatu w wersji 8.x, upewnij się, że uaktualnij sterownik klienta .NET serwera źródłowego do wersji 8.0.32, aby uniknąć niezgodności kodowania po migracji do serwera elastycznego.
• Jeśli źródłowy pojedynczy serwer usługi Azure Database for MySQL ma wersję aparatu w wersji 8.x, upewnij się, że uaktualnij wersję protokołu TLS serwera źródłowego z wersji 1.0 lub 1.1 do protokołu TLS w wersji 1.2 przed migracją, ponieważ starsze wersje protokołu TLS zostały uznane za przestarzałe dla serwera elastycznego.
• Jeśli źródłowy pojedynczy serwer usługi Azure Database for MySQL ma nazwy reguł zapory przekraczające 80 znaków, zmień ich nazwę, aby upewnić się, że długość nazwy jest mniejsza niż 80 znaków. (Długość nazwy reguły zapory obsługiwana na serwerze elastycznym to 80 znaków, natomiast na pojedynczym serwerze dozwolona długość to 12 8 znaków).
• Jeśli źródłowy pojedynczy serwer usługi Azure Database for MySQL korzysta z portów niezdefinicyjnych, takich jak 3308 3309 i 3310, zmień port łączności na 3306, ponieważ wymienione powyżej porty niezdefinicyjne nie są obsługiwane na serwerze elastycznym.

W jaki sposób docelowy serwer elastyczny MySQL jest automatycznie aprowizowany?

Warstwa obliczeniowa i jednostka SKU dla docelowego serwera elastycznego jest aprowizowana na podstawie warstwy cenowej źródłowego pojedynczego serwera i rdzeni wirtualnych na podstawie szczegółów w poniższej tabeli.

Warstwa cenowa serwera pojedynczego	Rdzenie wirtualne serwera pojedynczego	Warstwa serwera elastycznego	Nazwa jednostki SKU serwera elastycznego
Podstawowy	1	Z możliwością zwielokrotnienia wydajności	Standardowa_B1s
Podstawowy	2	Z możliwością zwielokrotnienia wydajności	Standard_B2s
Ogólnego przeznaczenia	2	Ogólnego przeznaczenia	Standard_D2ds_v4
Ogólnego przeznaczenia	100	Ogólnego przeznaczenia	Standard_D4ds_v4
Ogólnego przeznaczenia	8	Ogólnego przeznaczenia	Standard_D8ds_v4
Ogólnego przeznaczenia	16	Ogólnego przeznaczenia	Standard_D16ds_v4
Ogólnego przeznaczenia	32	Ogólnego przeznaczenia	Standard_D32ds_v4
Ogólnego przeznaczenia	64	Ogólnego przeznaczenia	Standard_D64ds_v4
Optymalizacja pod kątem pamięci	100	MemoryOptimized	Standard_E4ds_v4
Optymalizacja pod kątem pamięci	8	MemoryOptimized	Standard_E8ds_v4
Optymalizacja pod kątem pamięci	16	MemoryOptimized	Standard_E16ds_v4
Optymalizacja pod kątem pamięci	32	MemoryOptimized	Standard_E32ds_v4

• Wersja programu MySQL, region, *rozmiar magazynu, subskrypcja i grupa zasobów dla docelowego serwera elastycznego jest taka sama jak w przypadku źródłowego pojedynczego serwera.
• W przypadku pojedynczych serwerów z magazynem mniejszym niż 20 GiB rozmiar magazynu wynosi 20 GiB, ponieważ jest to minimalny limit magazynu w usłudze Azure Database for MySQL — serwer elastyczny.
• Oba formaty nazw użytkowników — username@server_name (pojedynczy serwer) i nazwa użytkownika (serwer elastyczny) są obsługiwane na zmigrowanym serwerze elastycznym.
• Oba formaty parametry połączenia — pojedynczy serwer i serwer elastyczny są obsługiwane na zmigrowanym serwerze elastycznym.
• W przypadku wystąpienia pojedynczego serwera z włączonym magazynem zapytań parametr serwera "slow_query_log" w wystąpieniu docelowym ma wartość WŁĄCZONE, aby zapewnić parzystość funkcji podczas migracji do serwera elastycznego. W przypadku niektórych obciążeń może to mieć wpływ na wydajność, a jeśli zauważysz spadek wydajności, ustaw ten parametr serwera na wartość "WYŁ." w wystąpieniu serwera elastycznego.

Kroki do wykonania po migracji

Oto informacje potrzebne do poznania po migracji w miejscu:

Uwaga

Po migracji nie uruchamiaj ponownie zatrzymanego wystąpienia pojedynczego serwera, ponieważ może to utrudnić łączność klienta i aplikacji.

• Skopiuj następujące właściwości ze źródłowego pojedynczego serwera do docelowego serwera elastycznego po zakończeniu operacji migracji w miejscu:
  • Ustawienia strony monitorowania (alerty, metryki i ustawienia diagnostyczne) i ustawienia blokad
  • Wszystkie skrypty programu Terraform/interfejsu wiersza polecenia, które hostujesz w celu zarządzania wystąpieniem pojedynczego serwera, powinny zostać zaktualizowane przy użyciu odwołań serwera elastycznego.
• W przypadku wystąpienia pojedynczego serwera z włączonym magazynem zapytań parametr serwera "slow_query_log" w wystąpieniu docelowym ma wartość WŁĄCZONE, aby zapewnić parzystość funkcji podczas migracji do serwera elastycznego. Należy pamiętać, że w przypadku niektórych obciążeń może to mieć wpływ na wydajność, a jeśli zauważysz spadek wydajności, ustaw ten parametr serwera na wartość "WYŁ." w wystąpieniu serwera elastycznego.
• W przypadku wystąpienia pojedynczego serwera z prywatnymi punktami końcowymi usuń walidację po migracji wystąpienia źródłowego pojedynczego serwera. Jeśli nie zostanie wykonana żadna operacja usuwania serwera, wystąpienie źródłowe będzie utrzymywane do 14 dni po usunięciu przez usługę.
• W przypadku wystąpienia pojedynczego serwera z włączonym Microsoft Defender dla Chmury stan włączania jest migrowany. Aby uzyskać parzystość na serwerze elastycznym po automigracji dla właściwości, które można skonfigurować na pojedynczym serwerze, rozważ szczegóły w poniższej tabeli:

Właściwości	Konfiguracja
Pomijanie określonych typów alertów	Wyłącz określone typy alertów za pomocą platformy Microsoft Defender dla Chmury. Aby uzyskać więcej informacji, odwiedź stronę Pomijanie alertów z przewodnika Microsoft Defender dla Chmury. Użytkownicy pojedynczego serwera mogą używać właściwości interfejsu API: properties.disabledAlerts
Powiadomienia e-mail	Zdefiniuj powiadomienie e-mail dotyczące alertów Microsoft Defender dla Chmury dla wszystkich zasobów w subskrypcji. Aby uzyskać więcej informacji, zobacz Konfigurowanie powiadomień e-mail dotyczących alertów zabezpieczeń. Użytkownicy pojedynczego serwera mogą używać właściwości interfejsu API: properties.emailAccountAdmins, properties.emailAddresses
Eksportowanie alertów w celu dalszego przetwarzania i/lub archiwizowania	Alerty są przechowywane na platformie Microsoft Defender dla Chmury i udostępniane za pośrednictwem usługi Azure Resource Graph. Alerty można wyeksportować do innego magazynu i oddzielnie zarządzać przechowywaniem. Aby uzyskać więcej informacji, odwiedź stronę Konfigurowanie eksportu ciągłego w witrynie Azure Portal — Microsoft Defender dla Chmury. Użytkownicy pojedynczego serwera mogą używać właściwości interfejsu API: properties.retentionDays, properties.storageAccountAccessKey, properties.storageEndpoint

Często zadawane pytania (FAQ)

Pyt. Dlaczego jestem automatycznie migrowany?

Odp. Wystąpienie usługi Azure Database for MySQL — Single Server kwalifikuje się do migracji w miejscu do naszej flagowej oferty Azure Database for MySQL — elastyczny serwer. Ta migracja w miejscu usunie obciążenie związane z ręczną migracją serwera i zapewni możliwość korzystania z zalet serwera elastycznego, w tym lepszej wydajności cenowej & , szczegółowej kontroli nad konfiguracją bazy danych i niestandardowych okien konserwacji.

Pyt. Jak przebiega automigracja? Co to wszystko jest migrowane?

Odp. Serwer elastyczny jest obsługiwany tak, aby pasował do tych samych VCores i pamięci masowej, co pojedynczy serwer. Następnie źródłowy pojedynczy serwer jest przełączany w stan zatrzymania, migawka pliku danych jest pobierana i kopiowana do docelowego serwera elastycznego. Przełącznik DNS jest wykonywany w celu przekierowania wszystkich istniejących połączeń do obiektu docelowego, a docelowy serwer elastyczny jest przełączany do trybu online. Automigration migruje pliki danych całego serwera (w tym schemat, dane, identyfikatory logowania) oprócz parametrów serwera (wszystkie zmodyfikowane parametry serwera w źródle są kopiowane do lokalizacji docelowej, niezmodyfikowane parametry serwera przyjmują wartość domyślną zdefiniowaną przez serwer elastyczny) i reguły zapory. Jest to migracja offline, w której przestój trwa do 5 minut lub mniej.

Pyt. Jak skonfigurować lub wyświetlić alerty migracji w miejscu?

Odp. Poniżej przedstawiono sposoby konfigurowania alertów:

• Skonfiguruj alerty dotyczące kondycji usługi, aby otrzymywać harmonogram migracji w miejscu i powiadomienia o postępie za pośrednictwem poczty e-mail/wiadomości SMS, wykonując kroki opisane tutaj.
• Aby wykonać kroki , zapoznaj się z powiadomieniem o migracji w miejscu w witrynie Azure Portal.

Pyt. Jak mogę odroczyć zaplanowaną migrację?

Odp. Harmonogram migracji można przejrzeć, przechodząc do bloku Migracja wystąpienia pojedynczego serwera. Jeśli chcesz odroczyć migrację, możesz odroczyć co najwyżej miesiąc, przechodząc do bloku Migracja pojedynczego wystąpienia serwera w witrynie Azure Portal i ponownie konfigurując migrację, wybierając kolejne okno migracji w ciągu miesiąca. Szczegóły migracji są zablokowane siedem dni przed zaplanowanym oknem migracji, po którym nie można ponownie zaplanować. Migracja lokalna może być odraczana co miesiąc do 16 września 2024 r.

Pyt. Jaka nazwa użytkownika i parametry połączenia będą obsługiwane dla migrowanego serwera elastycznego? ​​

Odp. Oba formaty nazw użytkowników — username@server_name (format pojedynczego serwera) i nazwa użytkownika (format serwera elastycznego) są obsługiwane dla zmigrowanego serwera elastycznego, dlatego nie trzeba ich aktualizować w celu zachowania ciągłości działania po migracji aplikacji. Ponadto oba formaty parametry połączenia (pojedynczy i elastyczny format serwera) są również obsługiwane dla zmigrowanego serwera elastycznego.

Pyt. Jak włączyć wysoką dostępność (wysoka dostępność) dla mojego serwera zmigrowanego automatycznie?

Odp. Domyślnie automigracja konfiguruje migrację do wystąpienia innego niż HA. Ponieważ wysoką dostępność zabezpieczeń można włączyć tylko podczas tworzenia serwera, należy włączyć wysoką dostępność przed zaplanowaną automigracją przy użyciu opcji edycji harmonogramu automigracji w portalu. Wysoką dostępność można włączyć tylko dla jednostek SKU Ogólnego przeznaczenia\Zoptymalizowane pod kątem pamięci na docelowym serwerze elastycznym, ponieważ migracja podstawowej do jednostki SKU z możliwością rozszerzenia nie obsługuje konfiguracji wysokiej dostępności.

Pyt. Widzę różnicę cenową dotyczącą mojego potencjalnego przejścia z programu MySQL Basic Single Server do serwera elastycznego MySQL?

Odp. Kilka serwerów może zobaczyć niewielki wzrost cen po migracji (szacowane koszty można zobaczyć, wybierając opcję edycji harmonogramu automigracji w portalu), ponieważ minimalny limit magazynu w obu ofertach jest inny (5 GiB na pojedynczym serwerze; 20 GiB na serwerze elastycznym) i koszt magazynu (0,1$ na pojedynczym serwerze; 0,115$ na serwerze elastycznym) dla serwera elastycznego jest nieco wyższy niż pojedynczy serwer. W przypadku serwerów, których dotyczy problem, ten wzrost cen serwera elastycznego zapewnia lepszą przepływność i wydajność w porównaniu z pojedynczym serwerem.

Powiązana zawartość

• Zarządzanie usługą Azure Database for MySQL — serwer elastyczny przy użyciu witryny Azure Portal.