Automigration z usługi Azure Database for Postgresql — pojedynczy serwer do serwera elastycznego
DOTYCZY: 
Azure Database for PostgreSQL — pojedynczy serwer
Automigration z usługi Azure Database for PostgreSQL — pojedynczy serwer do serwera elastycznego to migracja zainicjowana przez usługę, która odbywa się w zaplanowanym oknie przestoju dla pojedynczego serwera, niezależnie od jego poprawek lub okna obsługi. Usługa identyfikuje kwalifikujące się serwery i wysyła powiadomienia z wyprzedzeniem za pomocą szczegółowych kroków dotyczących procesu automigracji. Możesz przejrzeć i dostosować harmonogram migracji w razie potrzeby lub przesłać wniosek o pomoc techniczną, aby zrezygnować z automigracji dla serwerów.
Automigration korzysta z usługi migracji Azure PostgreSQL w celu zapewnienia odpornej migracji w trybie offline podczas planowanego okna migracji. Przestój będzie się różnić w zależności od właściwości obciążenia, a większe obciążenia mogą wymagać nawet 20 minut. Aby zapoznać się z testami porównawczymi szybkości migracji, zobacz Test porównawczy szybkości migracji usługi Azure PostgreSQL. Ta migracja eliminuje konieczność ręcznej migracji serwera, umożliwiając korzystanie z funkcji serwera elastycznego po migracji, w tym lepszą wydajność cenową, szczegółową kontrolę konfiguracji bazy danych i niestandardowe okna obsługi.
Uwaga
Usługa Automigration wybiera pojedynczy serwer do migracji na podstawie następujących kryteriów:
- Pojedynczy serwer w wersji 11
- Serwery bez złożonych funkcji, takich jak CMK, Microsoft Entra ID, Read Replica i Prywatny punkt końcowy
- Rozmiar danych <= 10 GB
- Dostęp publiczny jest włączony
Proces automigracji
Proces automigracji obejmuje kilka kluczowych faz:
Tworzenie docelowego serwera elastycznego — serwer elastyczny jest tworzony w celu dopasowania do wydajności i kosztów jednostki SKU pojedynczego serwera. Dziedziczy wszystkie reguły zapory ze źródłowego pojedynczego serwera.
Migracja danych — migracja danych odbywa się w wyznaczonym oknie migracji, zazwyczaj zaplanowanym poza godzinami pracy dla regionu hostingu serwera (jeśli okno zostanie wybrane przez usługę). Źródłowy pojedynczy serwer jest ustawiony na tylko do odczytu, a wszystkie dane, schematy, role użytkownika, uprawnienia i własność obiektów bazy danych są migrowane do serwera elastycznego.
Przełącznik DNS — po migracji danych jest wykonywany przełącznik DNS, dzięki czemu istniejący pojedynczy serwer parametry połączenia bezproblemowo nawiązywać połączenie z nowym serwerem elastycznym. Zarówno formaty parametry połączenia serwera pojedynczego, jak i elastycznego, a także formaty nazw użytkowników (username@server_name i nazwa użytkownika) są obsługiwane na zmigrowanym serwerze elastycznym.
Widoczność serwera elastycznego — po pomyślnej migracji danych i przełączniku DNS nowy serwer elastyczny jest wyświetlany w ramach subskrypcji i może być zarządzany za pośrednictwem witryny Azure Portal lub interfejsu wiersza polecenia.
Zaktualizowane parametry połączenia z pojedynczym serwerem — zaktualizowane parametry połączenia dla starszego pojedynczego serwera są wysyłane za pośrednictwem powiadomień usługi Service Health w witrynie Azure Portal. Są one również dostępne na stronie portalu Pojedynczego serwera w obszarze Ustawienia —> parametry połączenia.
Usuwanie pojedynczego serwera — pojedynczy serwer jest zachowywany przez siedem dni po migracji przed usunięciem.
Nominowanie pojedynczych serwerów do automigracji
Proces nominacji jest przeznaczony dla użytkowników, którzy chcą dobrowolnie szybko śledzić migrację na serwer elastyczny. Jeśli jesteś właścicielem obciążenia pojedynczego serwera, możesz teraz nominować siebie (jeśli nie zostało to jeszcze zaplanowane przez usługę) na potrzeby automigracji. Prześlij szczegóły serwera za pośrednictwem tego formularza.
Jak sprawdzić, czy pojedynczy serwer jest zaplanowany na potrzeby automigracji
Aby określić, czy dla automigracji wybrano pojedynczy serwer, wykonaj następujące kroki:
- Powiadomienia dotyczące kondycji usługi — w witrynie Azure Portal przejdź do pozycji Zdarzenia planowanej konserwacji usługi Service Health>. Poszukaj zdarzeń oznaczonych jako "Powiadomienie o zaplanowanej automatycznej migracji do pojedynczego serwera usługi Azure Database for PostgreSQL". Powiadomienia są wysyłane 30, 14 i 7 dni przed datą migracji, a następnie ponownie podczas etapów migracji: w toku, ukończono i sześć dni przed likwidacją pojedynczego serwera.
Uwaga
Te powiadomienia domyślnie nie lądują w skrzynce odbiorczej. Aby otrzymywać je za pośrednictwem poczty e-mail lub wiadomości SMS, należy skonfigurować alerty usługi Service Health, wykonując kroki opisane tutaj
- Strona przeglądu pojedynczego serwera — przejdź do wystąpienia pojedynczego serwera w witrynie Azure Portal i sprawdź stronę Przegląd. Jeśli zaplanowano automatyczną migrację, szczegółowe informacje znajdziesz tutaj, w tym opcję odroczenia migracji o jeden miesiąc w danym momencie lub ponownie zaplanowaną w ciągu bieżącego miesiąca.
Uwaga
Harmonogram migracji zostanie zablokowany 7 dni przed zaplanowanym oknem migracji, w którym nie będzie można ponownie zaplanować.
- Powiadomienia e-mail usługi Azure CXP — środowisko klienta platformy Azure (CXP) wysyła również bezpośrednie wiadomości e-mail do ról klasycznych i ról RBAC skojarzonych z subskrypcją zawierającą pojedynczy serwer, udostępniając informacje na temat nadchodzących automigracji.
Sprawdzanie wymagań wstępnych dotyczących automigracji
Zapoznaj się z następującymi wymaganiami wstępnymi, aby upewnić się, że automigration zakończyła się pomyślnie:
- Wystąpienie pojedynczego serwera powinno być w stanie gotowości podczas planowanego okna migracji w celu wykonania automigracji.
- W przypadku wystąpienia pojedynczego serwera z włączonym protokołem SSL upewnij się, że masz wszystkie certyfikaty (Główny urząd certyfikacji DigiCertGlobalRootG2 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.
- Jeśli źródłowy pojedynczy serwer usługi Azure Database for Postgresql 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 wynosi 80 znaków, natomiast na pojedynczym serwerze dozwolona długość to 128 znaków).
W jaki sposób docelowy serwer elastyczny postgresql jest aprowizowany?
Warstwa obliczeniowa i jednostka SKU dla docelowego serwera elastycznego jest aprowizowana na podstawie warstwy cenowej źródłowego pojedynczego serwera i rdzeni wirtualnych, jak pokazano poniżej.
| 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 | B1MS |
| Podstawowy | 2 | Z możliwością zwielokrotnienia wydajności | B2s |
| Ogólnego przeznaczenia | 2 | Ogólnego przeznaczenia | Standardowa_D2s_v3 |
| Ogólnego przeznaczenia | 100 | Ogólnego przeznaczenia | Standardowa_D4s_v3 |
| Ogólnego przeznaczenia | 8 | Ogólnego przeznaczenia | Standardowa_D8s_v3 |
| Ogólnego przeznaczenia | 16 | Ogólnego przeznaczenia | Standardowa_D16s_v3 |
| Ogólnego przeznaczenia | 32 | Ogólnego przeznaczenia | Standard_D32s_v3 |
| Ogólnego przeznaczenia | 64 | Ogólnego przeznaczenia | Standard_D64s_v3 |
| Optymalizacja pod kątem pamięci | 2 | MemoryOptimized | Standardowa_E2s_v3 |
| Optymalizacja pod kątem pamięci | 100 | MemoryOptimized | Standardowa_E4s_v3 |
| Optymalizacja pod kątem pamięci | 8 | MemoryOptimized | Standardowa_E8s_v3 |
| Optymalizacja pod kątem pamięci | 16 | MemoryOptimized | Standardowa_E16s_v3 |
| Optymalizacja pod kątem pamięci | 32 | MemoryOptimized | Standardowa_E32s_v3 |
- Docelowy serwer elastyczny w wersji postgresql, regionie, parametry połączenia, subskrypcji i grupie zasobów pozostanie taki sam jak źródłowy pojedynczy serwer.
- W przypadku pojedynczych serwerów z magazynem mniejszym niż 20 GiB rozmiar magazynu jest ustawiony na 32 GiB, ponieważ jest to minimalny limit magazynu w usłudze Azure Database for Postgresql — serwer elastyczny.
- W przypadku pojedynczych serwerów z większym wymaganiem dotyczącym magazynu wystarczająca ilość miejsca do magazynowania odpowiada 1,25 razy lub 25% więcej miejsca niż to, co jest używane na pojedynczym serwerze, jest przydzielane. Podczas początkowej podstawowej kopii danych wiele instrukcji insert jest wykonywanych na obiekcie docelowym, co generuje listy WALS (Write Ahead Logs). Dopóki te listy WAL nie zostaną zarchiwizowane, dzienniki zużywają magazyn w miejscu docelowym, a tym samym margines bezpieczeństwa.
- 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.
Kroki do wykonania po migracji
Oto informacje potrzebne do poznania automigracji:
- Parametry serwera na serwerze elastycznym są dostosowane do standardów społeczności. Jeśli chcesz zachować te same wartości parametrów serwera co pojedynczy serwer, możesz zalogować się za pomocą programu PowerShell i uruchomić skrypt tutaj , aby skopiować wartości parametrów.
- Aby włączyć szczegółowe informacje o wydajności zapytań, należy włączyć magazyn zapytań na serwerze elastycznym, który nie jest domyślnie włączony
- Jeśli wymagana jest wysoka dostępność , możesz ją włączyć z zerowym przestojem.
Obsługa reguł sieci wirtualnej na serwerze elastycznym
W usłudze Azure Database for PostgreSQL — pojedynczy serwer reguła sieci wirtualnej to podsieć wymieniona na liście kontroli dostępu serwera (ACL). Ta reguła umożliwia pojedynczemu serwerowi akceptowanie komunikacji z węzłów w tej konkretnej podsieci. W przypadku serwera elastycznego reguły sieci wirtualnej nie są obsługiwane. Zamiast tego serwer elastyczny umożliwia tworzenie prywatnych punktów końcowych, umożliwiając serwerowi działanie w sieci wirtualnej. Prywatny punkt końcowy przypisuje prywatny adres IP do serwera elastycznego, a cały ruch między siecią wirtualną a serwerem jest bezpiecznie przesyłany za pośrednictwem sieci szkieletowej platformy Azure, eliminując potrzebę publicznej ekspozycji w Internecie.
Po migracji należy dodać prywatny punkt końcowy do serwera elastycznego dla wszystkich podsieci objętych wcześniej regułami sieci wirtualnej na pojedynczym serwerze. Ten proces można ukończyć przy użyciu witryny Azure Portal lub interfejsu wiersza polecenia platformy Azure. Po zakończeniu tego kroku łączność sieciowa pozostanie nienaruszona na serwerze elastycznym po migracji z pojedynczego serwera.
Często zadawane pytania (FAQ)
Pyt. Dlaczego jestem automatycznie migrowany?
Odp. Twoje wystąpienie usługi Azure Database for Postgresql — pojedynczy serwer kwalifikuje się do automatycznego administrowania naszą flagową ofertą usługi Azure Database for Postgresql — serwer elastyczny. Ta automatyczna migracja spowoduje usunięcie obciążenia w celu ręcznej migracji serwera. Możesz skorzystać z zalet serwera elastycznego, w tym lepszej ceny i wydajności, szczegółowej kontroli nad konfiguracją bazy danych i niestandardowych okien obsługi.
Pyt. Jak przebiega automigracja? Co to wszystko jest migrowane?
Odp. Serwer elastyczny jest aprowizowany tak, aby był ściśle zgodny z tymi samymi rdzeniami wirtualnymi i magazynem co pojedynczy serwer. Następnie źródłowy pojedynczy serwer jest umieszczany w stanie tylko do odczytu, schemat i dane są kopiowane 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 bazy danych (w tym schemat, dane, użytkownicy/role i uprawnienia). Migracja jest w trybie offline, w którym widzisz przestój do 20 minut.
Pyt. Jak skonfigurować lub wyświetlić alerty automigracji?
Odp. Poniżej przedstawiono sposoby konfigurowania alertów:
- Skonfiguruj alerty dotyczące kondycji usługi, aby otrzymywać powiadomienia o harmonogramie automatycznego trwania i postępach za pośrednictwem poczty e-mail/wiadomości SMS, wykonując kroki opisane tutaj.
- Sprawdź powiadomienie o automigracji w witrynie Azure Portal, wykonując poniższe kroki tutaj.
Pyt. Jak mogę odroczyć zaplanowaną migrację pojedynczego serwera?
Odp. Harmonogram migracji można przejrzeć, przechodząc do strony Przegląd wystąpienia pojedynczego serwera. Jeśli chcesz odroczyć migrację, możesz odroczyć co najwyżej miesiąc, przechodząc do strony Przegląd wystąpienia pojedynczego serwera w witrynie Azure Portal. Możesz ponownie zaplanować 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ć. Tę automigrację można odroczyć co miesiąc do 30 marca 2025 r.
Pyt. Jak zrezygnować z zaplanowanej automigracji pojedynczego serwera?
Odp. Jeśli chcesz zrezygnować z automigracji, możesz zgłosić bilet pomocy technicznej do tego celu.
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. Widzę różnicę cenową dotyczącą mojego potencjalnego przejścia z serwera postgresql Basic Single Server do serwera elastycznego postgresql?
Odp. Kilka serwerów może zobaczyć niewielką poprawkę cenową po migracji, ponieważ minimalny limit magazynu w obu ofertach jest inny (5 GiB na pojedynczym serwerze i 32 GiB na serwerze elastycznym). Koszt magazynowania dla serwera elastycznego jest nieznacznie wyższy niż pojedynczy serwer. Każdy wzrost cen jest przesunięty dzięki lepszej przepływności i wydajności w porównaniu z pojedynczym serwerem. Aby uzyskać więcej informacji na temat cennika serwera elastycznego, zapoznaj się z tym dokumentem