Co się stanie z usługą Azure Database for PostgreSQL — pojedynczy serwer po ogłoszeniu o wycofaniu?
DOTYCZY: 
Azure Database for PostgreSQL — pojedynczy serwer
**Usługa Azure Database for PostgreSQL — pojedynczy serwer znajduje się na ścieżce wycofania i ma zostać wycofana do 28 marca 2025 r.
Azure Database for PostgreSQL — pojedynczy serwer ogólnie stał się dostępny w 2018 roku. Biorąc pod uwagę opinie klientów i nowe postępy w obliczeniach, dostępności, skalowalności i wydajności bazy danych platformy Azure, oferta pojedynczego serwera musi zostać wycofana i uaktualniona przy użyciu nowej architektury. Azure Database for PostgreSQL — serwer elastyczny to następna generacja usługi i oferuje najlepszą platformę bazy danych typu open source platformy Azure.
W ramach tego wycofania nie będziemy już obsługiwać tworzenia nowych wystąpień pojedynczego serwera z witryny Azure Portal od 30 listopada 2023 r. Jeśli jednak musisz utworzyć wystąpienia pojedynczego serwera w celu spełnienia wymagań dotyczących ciągłości działania, możesz nadal używać interfejsu wiersza polecenia platformy Azure do marca 2025 r.
Jeśli obecnie masz usługę Azure Database for PostgreSQL — pojedynczy serwer hostujący serwery produkcyjne, cieszymy się, że możesz przeprowadzić migrację usługi Azure Database for PostgreSQL — pojedynczy serwer do usługi Azure Database for PostgreSQL — serwer elastyczny.
Azure Database for PostgreSQL — serwer elastyczny to w pełni zarządzana usługa bazy danych gotowa do produkcji, która umożliwia bardziej szczegółową kontrolę i elastyczność funkcji zarządzania bazami danych i ustawień konfiguracji. Aby uzyskać więcej informacji na ten temat, odwiedź stronę Azure Database for PostgreSQL — serwer elastyczny.
Migrowanie z usługi Azure Database for PostgreSQL — pojedynczy serwer do usługi Azure Database for PostgreSQL — serwer elastyczny
Dowiedz się, jak przeprowadzić migrację z usługi Azure Database for PostgreSQL — pojedynczy serwer do usługi Azure Database for PostgreSQL — serwer elastyczny przy użyciu usługi migracji PostgreSQL.
Często zadawane pytania (FAQ)
Pyt. Dlaczego usługa Azure Database for PostgreSQL — pojedynczy serwer jest wycofywana?
Odp. Azure Database for PostgreSQL — pojedynczy serwer ogólnie stał się dostępny w 2018 roku. Biorąc pod uwagę opinie klientów i nowe postępy w obliczeniach, dostępności, skalowalności i wydajności bazy danych platformy Azure, oferta pojedynczego serwera musi zostać wycofana i uaktualniona przy użyciu nowej architektury. Azure Database for PostgreSQL — serwer elastyczny to następna generacja usługi i oferuje najlepszą platformę bazy danych typu open source platformy Azure.
Pyt. Dlaczego poproszono mnie o migrację do usługi Azure Database for PostgreSQL — serwer elastyczny?
A. Azure Database for PostgreSQL — serwer elastyczny to najlepsza platforma do uruchamiania wszystkich obciążeń PostgreSQL typu open source na platformie Azure. Azure Database for PostgreSQL — serwer elastyczny jest ekonomiczny, zapewnia lepszą wydajność we wszystkich warstwach usług i zapewnia więcej sposobów kontrolowania kosztów tańszego i szybszego odzyskiwania po awarii. Inne ulepszenia serwera elastycznego obejmują:
- Obsługa bazy danych Postgres w wersji 11 i nowszych oraz wbudowanych ulepszeń zabezpieczeń
- Lepsza wydajność cenowa dzięki obsłudze opcji obliczeniowych w warstwie z możliwością zwiększenia szybkości.
- Ulepszony czas pracy przez skonfigurowanie rezerwy dynamicznej w tej samej lub innej strefie dostępności i oknach obsługi kontrolowanych przez użytkownika.
- Uproszczone środowisko deweloperskie dla obciążeń danych o wysokiej wydajności.
Pyt. Jak szybko należy przeprowadzić migrację pojedynczego serwera na serwer elastyczny?
Odp. Azure Database for PostgreSQL — pojedynczy serwer ma zostać wycofany do 28 marca 2025 r., dlatego zdecydowanie zalecamy migrację pojedynczego serwera do serwera elastycznego najwcześniejszej okazji, aby zapewnić dużo czasu na przeprowadzenie cyklu życia migracji i wykorzystanie korzyści oferowanych przez serwer elastyczny.
Pyt. Co się stanie z istniejącymi wystąpieniami usługi Azure Database for PostgreSQL — pojedynczy serwer?
Odp. Istniejące obciążenia usługi Azure Database for PostgreSQL — pojedynczy serwer są obsługiwane do marca 2025 r.
Pyt. Czy nadal mogę utworzyć nową wersję 11 usługi Azure Database for PostgreSQL — pojedynczy serwer po dacie EOL społeczności w listopadzie 2023 r.?
Odp. Od 30 listopada 2023 r. nie będzie już można tworzyć nowych wystąpień pojedynczego serwera dla bazy danych PostgreSQL w wersji 11 za pośrednictwem witryny Azure Portal. Można je jednak nadal tworzyć za pośrednictwem interfejsu wiersza polecenia do marca 2025 r. Obsługujemy pojedyncze serwery za pośrednictwem zasad obsługi wersji. Najlepiej byłoby rozpocząć migrację do usługi Azure Database for PostgreSQL — serwer elastyczny natychmiast.
Pyt. Czy mogę kontynuować uruchamianie usługi Azure Database for PostgreSQL — pojedynczy serwer poza datą zachodu słońca 28 marca 2025 r.?
Odp. Planujemy obsługę pojedynczego serwera do daty zachodu słońca z 28 marca 2025 r. i zdecydowanie zalecamy rozpoczęcie planowania migracji tak szybko, jak to możliwe. Planujemy zakończenie wsparcia dla wdrożeń pojedynczego serwera w dniu 28 marca 2025 r.
Pyt. Co zrobić po ogłoszeniu wycofania pojedynczego serwera, jeśli nadal muszę utworzyć nowy pojedynczy serwer, aby zaspokoić swoje potrzeby biznesowe?
Odp. Nie zatrzymujemy możliwości natychmiastowego tworzenia nowych pojedynczych serwerów, więc możesz nadal tworzyć nowe pojedyncze serwery za pomocą interfejsu wiersza polecenia, aby spełnić potrzeby biznesowe wszystkich wersji bazy danych PostgreSQL obsługiwanych w usłudze Azure Database for PostgreSQL — pojedynczy serwer. Zdecydowanie zachęcamy do zapoznania się z serwerem elastycznym i sprawdzenie, czy będzie to spełniać Twoje potrzeby. Nie wahaj się skontaktować się z nami w razie potrzeby, abyśmy mogli cię poprowadzić i zaproponować najlepszą ścieżkę do przodu.
Pyt. Czy istnieją dodatkowe koszty związane z przeprowadzeniem migracji?
Odp. Płacisz za docelowy serwer elastyczny i źródłowy pojedynczy serwer podczas migracji. Konfiguracja i przetwarzanie docelowego serwera elastycznego określi dodatkowe koszty (zobacz Cennik , aby uzyskać więcej szczegółów). Po zlikwidowaniu źródłowego pojedynczego serwera po pomyślnej migracji płacisz tylko za serwer elastyczny. Korzystanie z usługi migracji pojedynczego serwera do serwera elastycznego nie kosztuje dodatkowych kosztów. Jeśli masz pytania lub obawy dotyczące kosztów migracji pojedynczego serwera na serwer elastyczny, skontaktuj się z przedstawicielem konta Microsoft.
Pyt. Czy na moje rozliczenia wpłynie uruchomienie usługi Azure Database for PostgreSQL — serwer elastyczny zamiast usługi Azure Database for PostgreSQL — pojedynczy serwer?
Odp. Rozliczenia powinny być porównywalne, jeśli wybierzesz podobną konfigurację do usługi Azure Database for PostgreSQL — pojedynczy serwer. Jeśli jednak wybierzesz tę samą strefę lub strefę nadmiarową z wysoką dostępnością docelowego serwera elastycznego, rachunek będzie wyższy niż na pojedynczym serwerze. Ta sama strefa lub strefowo nadmiarowa wysoka dostępność wymaga dodatkowego serwera rezerwowego do spun up i przechowywania nadmiarowych danych kopii zapasowej, dlatego dodatkowy koszt drugiego serwera. Ta architektura umożliwia zmniejszenie przestojów podczas nieplanowanych awarii i planowanej konserwacji. Ogólnie rzecz biorąc, serwer elastyczny zapewnia lepszą wydajność cenową, jednak zależy to od obciążenia.
Pyt. Czy wystąpi przestój podczas migracji usługi Azure Database z bazy danych PostgreSQL — pojedynczy serwer do serwera elastycznego?
Odp. Usługa migracji PostgreSQL obsługuje migracje offline i online. Migracja w trybie offline wymaga przestoju aplikacji podczas procesu migracji. Migracja online ułatwia migrowanie baz danych z ograniczonym przestojem, ale kilkoma ograniczeniami. Aby uzyskać więcej informacji, zobacz Usługa migracji PostgreSQL — pojedynczy serwer usługi Azure Database for PostgreSQL do serwera elastycznego.
Przestój zależy od kilku czynników, w tym liczby i rozmiaru baz danych, liczby tabel w każdej bazie danych, liczby indeksów i rozkładu danych między tabelami. Zależy również od jednostki SKU serwera źródłowego i docelowego oraz liczby operacji we/wy na sekundę dostępnej na serwerze źródłowym i docelowym.
Biorąc pod uwagę wiele czynników związanych z migracją, najlepszym podejściem do oszacowania przestoju w aplikacji jest wypróbowanie migracji na serwerze PITR przywróconym z serwera podstawowego w celu zaplanowania migracji produkcyjnej.
Migracje offline są mniej złożone i mają niewiele szans na awarię. Jest to zalecany sposób migrowania obciążeń z oknami usług z jednego serwera do serwera elastycznego. Migracja online może być używana w środowiskach produkcyjnych z niską tolerancją przestojów.
Pyt. Czy będą dostępne przyszłe aktualizacje pojedynczego serwera do obsługi najnowszych wersji bazy danych PostgreSQL?
Odp. Zalecamy przeprowadzenie migracji do serwera elastycznego, jeśli musisz uruchomić w najnowszych wersjach aparatu PostgreSQL. Nadal wdrażamy wersje pomocnicze wydane przez społeczność dla bazy danych Postgres w wersji 11 do czasu wycofania jej przez społeczność w listopadzie 2023 r.
Uwaga
Rozszerzamy obsługę bazy danych Postgres w wersji 11 wcześniejszej niż data wycofania społeczności i będziemy obsługiwać program PostgreSQL w wersji 11 zarówno na pojedynczym serwerze, jak i serwerze elastycznym, aby ułatwić to przejście. Rozważ migrację do serwera elastycznego, aby korzystać z zalet najnowszych wersji aparatu Postgres.
Pyt. W jaki sposób umowa SLA dotycząca dostępności serwera elastycznego 99,99% różni się od pojedynczego serwera?
Odp. Wdrożenie strefowo nadmiarowe serwera elastycznego zapewnia dostępność na poziomie 99,99% z odpornością na poziomie strefowym, a pojedynczy serwer zapewnia dostępność na poziomie 99,99%, ale bez odporności strefowej. Architektura wysokiej dostępności serwera elastycznego wdraża serwer rezerwowy z nadmiarowymi obliczeniami i magazynem (z danymi każdej lokacji przechowywanymi w 3-krotnych kopiach). Architektura wysokiej dostępności pojedynczego serwera nie ma pasywnej rezerwy dynamicznej, aby pomóc w odzyskiwaniu po awariach strefowych. Architektura wysokiej dostępności serwera elastycznego zmniejsza przestoje podczas nieplanowanych awarii i planowanej konserwacji.
Pyt. Mój pojedynczy serwer jest wdrażany w regionie, który nie obsługuje serwera elastycznego. Jak kontynuować migrację?
Odp. Zbliżamy się do równoważności regionalnej z pojedynczym serwerem. Są to regiony bez obecności serwera elastycznego.
- Chiny Wschodnie (CE i CE2),
- Chiny Północne (CN i CN2)
- Indie Zachodnie
- Szwecja Środkowa
Zalecamy migrację do regionów CN3/CE3, Indie Środkowe, Szwecja Środkowa i Szwecja Południowa. Pyt. Mam łącze prywatne skonfigurowane dla mojego pojedynczego serwera. Jak przeprowadzić migrację?
Odp. Obsługa usługi Private Link jest teraz dostępna na serwerze elastycznym. Możesz użyć serwera środowiska uruchomieniowego, aby przejść do serwera elastycznego z obsługą łącza prywatnego. Aby uzyskać więcej informacji, zobacz Serwer środowiska uruchomieniowego — pojedynczy serwer usługi Azure Database for PostgreSQL na serwer elastyczny.
Pyt. Czy istnieje możliwość wycofania migracji pojedynczego serwera do serwera elastycznego?
Odp. Możesz wykonać dowolną liczbę migracji testowych, przetestować powodzenie migracji i wykonać ostateczną migrację, gdy wszystko będzie gotowe. Migracje testowe nie wpływają na pojedyncze źródło serwera, które pozostaje operacyjne do czasu migracji i zmiany parametry połączenia, aby wskazywały serwer elastyczny. Jeśli podczas migracji testowej wystąpią jakiekolwiek błędy, możesz odroczyć ostateczną migrację i zachować działanie serwera źródłowego. Wówczas możesz ponownie podjąć próbę przeprowadzenia ostatecznej migracji po wyeliminowaniu błędów. Po przeprowadzeniu ostatecznej migracji na serwer elastyczny i otwarciu go dla obciążenia produkcyjnego utracisz możliwość powrotu do pojedynczego serwera bez ponoszenia utraty danych.
Pyt. Jak przeprowadzić migrację bazy danych (> 1 TB)
A. Usługa migracji PostgreSQL może migrować bazy danych o wszystkich rozmiarach z pojedynczego serwera do serwera elastycznego. Usługa migracji nie ma żadnych ograniczeń dotyczących rozmiaru baz danych.
Pyt. Czy migracja między regionami jest obsługiwana?
Odp. Tak.
Pyt. Czy jest obsługiwana migracja między subskrypcjami?
Odp. Usługa migracji PostgreSQL obsługuje migracje między subskrypcjami.
Pyt. Czy subskrypcja między grupami zasobów jest obsługiwana?
Odp. Usługa migracji PostgreSQL obsługuje migracje między grupami zasobów.
Pyt. Czy istnieje obsługa między wersjami?
Odp. Usługa migracji PostgreSQL obsługuje migrację z niższej wersji bazy danych PostgreSQL (PG 9.5 lub nowszej) do dowolnej nowszej wersji. Jak zawsze należy sprawdzić zgodność aplikacji z wyższymi wersjami bazy danych PostgreSQL.
Usługa migracji PostgreSQL
Usługa migracji PostgreSQL to zaawansowana usługa, która umożliwia łatwą migrację bazy danych serwera PostgreSQL z pojedynczego serwera na serwer elastyczny. Dzięki tej usłudze można łatwo przenieść bazę danych z serwera lokalnego lub maszyny wirtualnej do serwera elastycznego w chmurze, co pozwala na wykorzystanie skalowalności i elastyczności przetwarzania w chmurze.
Pyt. Które składniki danych, schematu i metadanych są migrowane w ramach migracji?
Odp. Usługa migracji PostgreSQL migruje schemat, dane i metadane ze źródła do miejsca docelowego. Wszystkie następujące składniki danych, schematu i metadanych są migrowane w ramach migracji bazy danych:
Migracja danych
- Wszystkie tabele ze wszystkich baz danych/schematów.
Migracja schematu:
- Nazewnictwo
- Klucz podstawowy
- Typ danych
- Położenie porządkowe
- Domyślna wartość
- Wartość null
- Atrybuty autoinkrementacji
- Indeksy pomocnicze
Migracja metadanych:
- Procedury składowane
- Funkcje
- Wyzwalacze
- Widoki
- Ograniczenia klucza obcego
Pyt. Jaka jest różnica między migracją offline i online?
Odp. W przypadku migracji w trybie offline przestój aplikacji rozpoczyna się po rozpoczęciu migracji. W przypadku migracji online przestój jest ograniczony do wymaganego czasu migracji jednorazowej na końcu procesu migracji. Jednak korzysta z mechanizmu replikacji logicznej, który podlega kilku ograniczeniom.
Poniższa tabela zawiera omówienie opcji offline i online.
| Opcja | Plusy | Minusy | Zalecane dla |
|---|---|---|---|
| W trybie offline | - Proste, łatwe i mniej złożone do wykonania. - Bardzo mało szans na awarię. - Brak ograniczeń dotyczących obiektów bazy danych, które może obsłużyć |
Przestój w aplikacjach. | - Najlepsze w scenariuszach, w których prostota i wysoki wskaźnik sukcesu są niezbędne. — Idealne rozwiązanie w przypadku scenariuszy, w których baza danych może być w trybie offline bez znaczącego wpływu na operacje biznesowe. — Odpowiednie dla baz danych, gdy proces migracji można ukończyć w ramach planowanego okna obsługi. |
| Tryb online | - Bardzo minimalny przestój w aplikacji. — Idealne rozwiązanie dla dużych baz danych i klientów z ograniczonymi wymaganiami dotyczącymi przestojów. |
— Replikacja używana w migracji online ma kilka ograniczeń (na przykład klucze podstawowe wymagane we wszystkich tabelach). — Trudne i bardziej złożone do wykonania niż migracja w trybie offline. - Większe szanse na niepowodzenie ze względu na złożoność migracji. — Istnieje wpływ na magazyn i przetwarzanie wystąpienia źródłowego, jeśli migracja jest uruchamiana przez długi czas. Wpływ należy uważnie monitorować podczas migracji. |
— Najlepsze rozwiązanie dla firm, w których ciągłość jest krytyczna, a przestoje muszą być minimalne. — Zalecane w przypadku baz danych, gdy proces migracji musi wystąpić bez przerywania bieżących operacji. |
Pyt. Czy istnieją jakieś zalecenia dotyczące optymalizacji wydajności migracji pojedynczego serwera na serwer elastyczny?
Odp. Tak. Aby przeprowadzić szybsze migracje, wybierz wyższą jednostkę SKU dla serwera elastycznego. Wybierz co najmniej 4 rdzenie wirtualne lub wyższe, aby szybko ukończyć migrację. Zawsze można zmienić jednostkę SKU tak, aby odpowiadała potrzebom aplikacji po migracji. Zapoznaj się z najlepszymi rozwiązaniami.
Pyt. Jak długo trwa migracja w trybie offline z pojedynczego serwera do serwera elastycznego z usługą migracji?
Odp. W poniższej tabeli przedstawiono czas poświęcony na przeprowadzanie migracji w trybie offline dla baz danych o różnych rozmiarach przy użyciu usługi migracji PostgreSQL. Migracja została przeprowadzona przy użyciu serwera elastycznego z jednostkami SKU:
Standard_D4ds_v4 (4 rdzenie, 16 GB pamięci i 500 operacji we/wy na sekundę)
| Rozmiar bazy danych | Czas (HH:MM) |
|---|---|
| 1 GB | 00:01 |
| 5 GB | 00:03 |
| 10 GB | 00:08 |
| 50 GB | 00:35 |
| 100 GB | 01:00 |
| 500 GB | 04:00 |
| 1000 GB | 07:00 |
Uwaga
Powyższe liczby są przybliżone czas potrzebny na ukończenie migracji. Aby uzyskać dokładny czas wymagany do przeprowadzenia migracji na serwer, zdecydowanie zalecamy wykonanie przywracania do punktu w czasie (przywracanie do punktu w czasie) pojedynczego serwera i przeprowadzenie migracji z usługą migracji PostgreSQL.
Pyt. Jak długo trwa migracja online z pojedynczego serwera do serwera elastycznego z usługą migracji?
Odp. Migracja online obejmuje następujące kroki:
- Początkowa kopia baz danych
- Przechwytywanie zmian danych — ponowne wykonywanie wszystkich transakcji w źródle w kroku 1 do miejsca docelowego.
Czas potrzebny w kroku 1 jest taki sam jak w przypadku migracji w trybie offline (zapoznaj się z poprzednim pytaniem).
Czas potrzebny na krok 2 zależy od transakcji występujących w źródle. Jeśli jest to obciążenie intensywnie korzystające z zapisu, trwa to dłużej.
Pyt. Czy firma Microsoft oferuje pomoc techniczną dotyczącą przejścia z pojedynczego serwera na serwer elastyczny?
Odp. Tak. Oprócz ciągłego aktualizowania usługi migracji współpracujemy z wewnętrznymi zespołami partnerskimi, które mogą współpracować z Tobą w całym procesie migracji. Aby uzyskać więcej informacji, skontaktuj się z przedstawicielem konta.
Pyt. Czy firma Microsoft może automatycznie migrować mój pojedynczy serwer do serwera elastycznego? Odp. Tak. Możesz nominować serwery do migracji automatycznej. Więcej informacji na ten temat można znaleźć i nominować serwery do automigracji tutaj.
Dodatkowa pomoc techniczna
Pyt. Mam dalsze pytania dotyczące przejścia na emeryturę.
Odp. Dalsze informacje można uzyskać na kilka różnych sposobów.
Uzyskaj odpowiedzi od ekspertów społeczności w usłudze Microsoft Q&A.
Jeśli masz plan pomocy technicznej i potrzebujesz pomocy technicznej, utwórz wniosek o pomoc techniczną: — W obszarze Podsumowanie wpisz opis problemu. — W polu Typ problemu wybierz pozycję Techniczne. — W polu Subskrypcja wybierz swoją subskrypcję. - W obszarze Usługa wybierz pozycję Moje usługi. — W polu Typ usługi wybierz pozycję Azure Database for PostgreSQL — pojedynczy serwer. — W polu Zasób wybierz zasób. — W polu Typ problemu wybierz pozycję Migrowanie do usługi Azure DB for PostgreSQL. — W obszarze Podtyp problemu wybierz pozycję Migrowanie z pojedynczego do serwera elastycznego.
Ostrzeżenie
Ten artykuł nie dotyczy użytkowników usługi Azure Database for PostgreSQL — serwer elastyczny. Dotyczy to klientów usługi Azure Database for PostgreSQL — pojedynczy serwer, którzy muszą przeprowadzić uaktualnienie do usługi Azure Database for PostgreSQL — serwer elastyczny.
Wiemy, że migracja usług może być frustrująca i przepraszamy z góry za wszelkie niedogodności, które mogą spowodować. Możesz wybrać najlepszy scenariusz dla Ciebie i twojego środowiska.