Automatyczne migrowanie w miejscu z usługi Azure Database for MySQL — pojedynczy serwer do serwera elastycznego
DOTYCZY:
Azure Database for MySQL — pojedynczy serwer
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 obciążeń bazy danych pojedynczego serwera z włączoną jednostką SKU Podstawowa, Ogólnego przeznaczenia lub Zoptymalizowana pod kątem pamięci, magazyn danych używany< = 20 GiB i brak złożonych funkcji (CMK, Microsoft Entra ID, Read Replica, Private Link). 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 samonaprawiania środowiska migracji w trybie offline podczas planowanego okna obsługi z krótszym niż 5 minut przestojów . 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 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 z włączoną jednostką SKU Podstawowa, Ogólnego przeznaczenia lub Zoptymalizowana pod kątem pamięci, używany magazyn <danych = 20 GiB i brak złożonych funkcji (CMK, Microsoft Entra ID, Read Replica, Private Link), możesz teraz nominować siebie (jeśli usługa nie została jeszcze zaplanowana) na potrzeby automigracji, przesyłając szczegóły serwera za pośrednictwem tego formularza.
Konfigurowanie alertów migracji i przeglądanie harmonogramu 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.
Poniżej opisano sposoby przeglądania harmonogramu migracji po otrzymaniu powiadomienia automatycznego automigracji w miejscu:
Uwaga
Harmonogram migracji zostanie zablokowany 7 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.
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.
- 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 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 | 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)
- 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 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 | Konfigurowanie |
|---|---|
| properties.disabledAlerts | Określone typy alertów można wyłączyć przy użyciu platformy Microsoft Defender dla Chmury. Aby uzyskać więcej informacji, zobacz artykuł Pomijanie alertów z Microsoft Defender dla Chmury przewodnik. |
| properties.emailAccount Administracja s, properties.emailAddresses | Możesz centralnie zdefiniować powiadomienie e-mail dotyczące alertów Microsoft Defender dla Chmury dla wszystkich zasobów w subskrypcji. Aby uzyskać więcej informacji, zobacz artykuł Konfigurowanie powiadomień e-mail dotyczących alertów zabezpieczeń. |
| properties.retentionDays, properties.storageAccountAccessKey, properties.storageEndpoint | Platforma Microsoft Defender dla Chmury uwidacznia alerty 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 na temat eksportu ciągłego, zobacz artykuł Konfigurowanie eksportu ciągłego w witrynie Azure Portal — Microsoft Defender dla Chmury. |
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 zostaną 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.