Co się stanie z usługą Azure Database for PostgreSQL — pojedynczy serwer po ogłoszeniu o wycofaniu?

DOTYCZY: Azure Database for PostgreSQL — pojedynczy serwer

Azure Database for PostgreSQL — pojedynczy serwer znajduje się na ścieżce wycofania i ma zostać wycofany 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 zakresie obliczeń, dostępności, skalowalności i wydajności w środowisku 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 zapewnia najlepszą platformę bazy danych typu open source platformy Azure.

W ramach tego wycofania nie obsługujemy już tworzenia nowych wystąpień pojedynczego serwera z witryny Azure Portal od 30 listopada 2023 r. Jeśli 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 i szablonu usługi ARM. Jednak od marca 2025 r. te metody nie będą już używane.

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 temat usługi Azure Database for PostgreSQL — serwer elastyczny, 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 narzędzia migracji pojedynczego serwera do serwera elastycznego.

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 zakresie obliczeń, dostępności, skalowalności i wydajności w środowisku 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 zapewnia 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 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 będą nadal 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 listopada 2024 r. Będziemy nadal obsługiwać pojedyncze serwery za pośrednictwem naszych 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 obsługi wdrożeń pojedynczego serwera w danych o zachodzie słońca 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 dla Ciebie.

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 narzędzia 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 jest to zależne 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. Obecnie narzędzie migracji pojedynczego serwera do serwera elastycznego obsługuje tylko migracje w trybie offline. Migracja w trybie offline wymaga przestoju aplikacji podczas procesu migracji. Aby uzyskać więcej informacji, zobacz Narzędzie migracji — pojedynczy serwer usługi Azure Database for PostgreSQL do serwera elastycznego.

Przestój zależy od kilku czynników, w tym liczby baz danych, rozmiaru baz danych, liczby tabel wewnątrz każdej bazy 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 w trybie offline są mniej złożone, z kilkoma szansami awarii i są zalecanym sposobem przeprowadzania migracji z jednego serwera do serwera elastycznego dla obciążeń z oknami usług.

Jeśli wymagania dotyczące przestojów nie są spełnione przez migracje w trybie offline dostarczone przez pojedynczy serwer do narzędzia do migracji elastycznej, możesz skontaktować się z zespołami kont.

Uwaga

Obsługa migracji online jest dostępna wkrótce.

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 Północna

Zalecamy migrację do regionów CN3/CE3, Indie Środkowe, Szwecja Środkowa i Szwecja Południowa. Pyt. Mam łącze prywatne skonfigurowane dla mojego pojedynczego serwera i ta funkcja nie jest obecnie obsługiwana na serwerze elastycznym. Jak przeprowadzić migrację?

Odp. Obsługa serwera elastycznego dla łącza prywatnego jest naszym najwyższym priorytetem i planem działania. Ta funkcja ma zostać uruchomiona w kwartale 4 2023 r. Inną opcją jest rozważenie migracji do serwera elastycznego ze wstrzykniętą siecią wirtualną.

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 źródło pojedynczego serwera, które pozostaje operacyjne do czasu przeprowadzenia migracji. 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.Narzędzie migracji pojedynczego serwera do serwera elastycznego może migrować bazy danych wszystkich rozmiarów z pojedynczego serwera do serwera elastycznego. Nowa wersja narzędzia nie ma żadnych ograniczeń dotyczących rozmiaru baz danych.

Pyt. Czy migracja między regionami jest obsługiwana?

Odp. Obecnie narzędzie migracji pojedynczego serwera do serwera elastycznego nie obsługuje migracji między regionami. Jest ona obsługiwana w późniejszym momencie. Do przeprowadzania migracji między regionami można użyć pg_dump/pg_restore.

Należy unikać migracji danych między regionami, ponieważ migracja trwa długo. Prostszą metodą jest uruchomienie repliki do odczytu w docelowym regionie geograficznym, przełączenie aplikacji w tryb failover i wykonanie kroków opisanych wcześniej.

Pyt. Czy jest obsługiwana migracja między subskrypcjami?

Odp. Narzędzie migracji pojedynczego serwera do serwera elastycznego obsługuje migracje między subskrypcjami.

Pyt. Czy subskrypcja między grupami zasobów jest obsługiwana?

Odp. Narzędzie migracji pojedynczego serwera do serwera elastycznego obsługuje migracje między grupami zasobów.

Pyt. Czy istnieje obsługa między wersjami?

Odp. Usługa migracji pojedynczy serwer do serwera elastycznego 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.

Narzędzie migracji pojedynczego serwera do serwera elastycznego

Narzędzie migracji pojedynczego serwera do serwera elastycznego to zaawansowane narzędzie , które umożliwia łatwe migrowanie bazy danych programu SQL Server z jednego serwera do serwera elastycznego. Dzięki temu narzędziu 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. Narzędzie migracji pojedynczego serwera do serwera elastycznego 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. Narzędzie migracji pojedynczego serwera do serwera elastycznego obsługuje teraz migrację w trybie offline, a migracje online będą dostępne wkrótce. W przypadku migracji w trybie offline przestój aplikacji rozpoczyna się po rozpoczęciu migracji. W przypadku migracji online przestój jest ograniczony do czasu wymaganego do skrócenia czasu po zakończeniu migracji, ale korzysta z mechanizmu replikacji logicznej. Dane/schemat muszą przekazać te ograniczenia aparatu PG typu open source na potrzeby migracji online. Zalecamy przetestowanie migracji w trybie offline, aby określić, czy przestój jest akceptowalny.

Migracje online i offline porównano w poniższej tabeli:

Obszar	Migracja w trybie online	Migracja w trybie offline
Dostępność bazy danych do odczytu podczas migracji	Dostępna	Dostępna
Dostępność bazy danych do zapisywania podczas migracji	Dostępny	Ogólnie rzecz biorąc, nie jest to zalecane. Wszystkie operacje "zapisu" zainicjowane po migracji nie są przechwytywane ani migrowane
Użyteczność aplikacji	Aplikacje, które wymagają maksymalnego czasu pracy	Aplikacje, które mogą pozwolić na zaplanowany przestój lub mają ograniczenia schematu/obciążenia, które uniemożliwiają migrację online
Odpowiedniość dla obciążeń z dużym obciążeniem zapisu	Odpowiednie, ale oczekiwane zmniejszenie obciążenia podczas migracji	Jest to zalecane rozwiązanie tylko wtedy, gdy można wyłączyć zapisy podczas migracji. Wszystkie operacje zapisu w źródle nie są migrowane na serwer docelowy po rozpoczęciu migracji
Ręczne przełączanie jednorazowe	Wymagania	Niewymagane
Wymagany przestój	Mały i stały niezależnie od rozmiaru danych	Proporcjonalnie do rozmiaru danych i innych czynników. Może to być nawet kilka minut dla mniejszych baz danych do kilku godzin dla większych baz danych
Czas migracji	Zależy od rozmiaru bazy danych i działania zapisu do czasu przejścia jednorazowego	Zależy od rozmiaru bazy danych

Pyt. Czy istnieją jakieś zalecenia dotyczące optymalizacji wydajności narzędzia migracji pojedynczego serwera do serwera elastycznego?

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.

Pyt. Jak długo trwa migracja w trybie offline za pomocą narzędzia migracji pojedynczego serwera do serwera elastycznego?

Odp. W poniższej tabeli przedstawiono czas przeprowadzania migracji w trybie offline dla baz danych o różnych rozmiarach przy użyciu narzędzia migracji pojedynczego serwera do serwera elastycznego. Migracja została przeprowadzona przy użyciu serwera elastycznego z jednostkami SKU:

Standard_D4ds_v4 (4 rdzenie, 16 GB pamięci, dysk 128 GB 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 migracji na serwer, zdecydowanie zalecamy wykonanie przywracania do punktu w czasie (do punktu w czasie) pojedynczego serwera i uruchomienie go względem narzędzia migracji pojedynczego serwera do serwera elastycznego.

Pyt. Jak długo trwa migracja w trybie online za pomocą narzędzia migracji pojedynczego serwera do serwera elastycznego?

Odp. Migracja online obejmuje następujące kroki:

1. Początkowa kopia baz danych
2. 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, czas potrzebny na krok 2 będzie dłuższy.

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 obszarze Typ problemu wybierz pozycję Problem techniczny.
  • W obszarze 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 migrowanie usług może być frustrujące środowisko i przepraszamy z wyprzedzeniem za wszelkie niedogodności, które może to spowodować. Możesz wybrać najlepszy scenariusz dla Ciebie i twojego środowiska.

Następne kroki

• Narzędzie migracji
• Co to jest serwer elastyczny?