Automigracja z pojedynczego serwera Azure Database for PostgreSQL do elastycznego serwera
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 używa usługi migracji Azure PostgreSQL do dostarczania odpornej migracji w trybie offline podczas planowanego okna migracji. Przestój różni się w zależności od cech obciążenia. 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 Automatycznej migracji wybiera pojedynczy serwer do migracji na podstawie następujących kryteriów:
- Serwery bez złożonych funkcji, takich jak CMK, Microsoft Entra ID, Read Replica i Prywatny punkt końcowy.
- Rozmiar danych <= 100 GB
- Dostęp publiczny jest włączony
Uwaga
W przypadku użycia dowolnej z tych funkcji, takich jak CMK, Microsoft Entra ID, Read Replica i Prywatny punkt końcowy, wymagane będzie dodatkowe planowanie. Podaj szczegóły w poniższym formularzu nominacji i skontaktujemy się z Tobą.
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 automatycznej migracji. Prześlij szczegóły serwera za pośrednictwem tego formularza.
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.
Wystąpienie pojedynczego serwera musi mieć ustawienie Odmów dostępu do sieci publicznej skonfigurowane na Wartość Nie. Tę opcję można znaleźć w bloku Zabezpieczenia połączeń w witrynie Azure Portal.
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).
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. Ponadto kopiuje wszystkie istniejące reguły zapory do serwera elastycznego, zapewniając nieprzerwaną łączność.
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.
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.
Automigration w głównych wersjach bazy danych PostgreSQL
Ta migracja może obejmować przenoszenie danych z pojedynczego serwera PostgreSQL (wersje 9.5, 9.6 lub 10) do bazy danych PostgreSQL 11 na serwerze elastycznym. Należy pamiętać, że te wcześniejsze wersje zostały wycofane przez społeczność postgreSQL. Aby zapewnić bezpieczeństwo, stabilność i wydajność, zaleca się przyjęcie obsługiwanych wersji społeczności.
Podczas migracji między głównymi wersjami bazy danych PostgreSQL należy wziąć pod uwagę następujące kluczowe czynniki, aby zapewnić pomyślne i płynne przejście:
Wycofane funkcje — funkcje wycofane w starszych wersjach mogą nie być już dostępne w usłudze PostgreSQL 11. Ważne jest, aby przejrzeć informacje o wersji dotyczące wszelkich zmian powodujących niezgodność lub przestarzałych funkcji, które mogą mieć wpływ na aplikację.
Testowanie aplikacji — przeprowadzanie dokładnych testów aplikacji w usłudze PostgreSQL 11. Zwróć uwagę na potencjalne problemy z zapytaniami SQL, funkcjami lub narzędziami innych firm, ponieważ mogą one zachowywać się inaczej lub całkowicie zakończyć się niepowodzeniem z powodu zmian w nowszej wersji.
Zmiany konfiguracji — uaktualnienia wersji głównej często wprowadzają zmiany parametrów serwera przez dodanie nowych parametrów lub zmianę domyślnych wartości istniejących. Te zmiany mogą mieć wpływ na sortowanie, wykonywanie zapytań i przechowywanie danych. Aby zapewnić zgodność, przetestuj aplikację pod kątem tych zaktualizowanych ustawień i rozwiąż wszelkie występujące problemy. Jeśli wystąpią problemy, użyj skryptu podanego w sekcji kroków po migracji, aby skopiować istniejące parametry serwera z wystąpienia pojedynczego serwera do serwera elastycznego z automigrated.
Kroki do wykonania po migracji
Poniżej przedstawiono informacje dotyczące kroków po automigracji.
Jeśli automatyczna migracja obejmuje migrację między głównymi wersjami bazy danych PostgreSQL, dokładnie przetestuj aplikację, aby zidentyfikować wpływ zmian powodujących niezgodność i korekt parametrów. Wprowadź niezbędne zmiany, aby zapewnić zgodność i optymalną wydajność.
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.
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.
Ustawienia kontroli dostępu (IAM) dla serwera elastycznego będą dziedziczone z ustawień subskrypcji. Jeśli podano jakiekolwiek przypisania ról specyficzne dla pojedynczego serwera, należy utworzyć te przypisania ról na serwerze elastycznym.
Skopiuj ustawienia strony monitorowania (alerty, metryki i ustawienia diagnostyczne) do serwera elastycznego.
Aby włączyć szczegółowe informacje dotyczące 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.
Sprawdź, czy jednostka SKU serwera elastycznego jest zgodna z jednostką wymienioną w powiadomieniu automigracji usługi Service Health. Jeśli jest inaczej, przywróć ją do jednostki SKU określonej w powiadomieniu. Ma to kluczowe znaczenie dla zapewnienia dokładnych rozliczeń.
Istniejące parametry połączenia pojedynczego serwera będą teraz wskazywać serwer elastyczny. Aby uzyskać dostęp do pojedynczego serwera, został wygenerowany nowy zestaw parametry połączenia. Można je pobrać z powiadomienia usługi Service Health wysyłanego do automatycznego przesyłania pojedynczego serwera.
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, które zostały wcześniej objęte 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.
Długoterminowe przechowywanie kopii zapasowej
Automatyczna migracja pojedynczych serwerów nie konfiguruje automatycznej kopii zapasowej przechowywania długoterminowego (LTR) po migracji na serwer elastyczny. Możesz utworzyć kopię zapasową serwera elastycznego usługi Azure Database for PostgreSQL z długoterminowym przechowywaniem przy użyciu usługi Azure Backup.
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 jest 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.
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 powoduje 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 można zobaczyć przestój w ciągu kilku minut do 2 godzin w zależności od rozmiaru obciążenia. Aby zapoznać się z testami porównawczymi szybkości migracji, zobacz Test porównawczy szybkości migracji usługi Azure PostgreSQL.
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 28 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. Jakie kroki po migracji należy wykonać, jeśli mój pojedynczy serwer używa reguł sieci wirtualnej?
Odp. Reguły sieci wirtualnej nie są obsługiwane na serwerze elastycznym. Zapoznaj się z tą sekcją
Pyt. Czy muszę ponownie skonfigurować kopie zapasowe przechowywania długoterminowego na serwerze elastycznym?
Odp. Tak. Zapoznaj się z tą sekcją
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
Pyt. Co się stanie, jeśli nie zmigruję lub mój serwer nie zostanie zmigrowany automatycznie do 28 marca 2025 r.?
Odp. Po upływie terminu wycofania z dnia 28 marca 2025 r. wszystkie istniejące pojedyncze serwery, które nie zostały zmigrowane, zostaną wymusione na serwer elastyczny. Serwery z funkcjami dodatków, takimi jak cmK lub prywatny punkt końcowy, będą wymagały większej liczby akcji po migracji przez użytkownika w celu zapewnienia normalnego działania. Brak rozszerzeń do daty wycofania.