Uaktualnienia wersji głównych na serwerze elastycznym usługi Azure Database for PostgreSQL

2025-06-19

DOTYCZY: Azure Database for PostgreSQL — serwer elastyczny

Elastyczny serwer usługi Azure Database for PostgreSQL obsługuje bazy danych PostgreSQL w wersji 17 (wersja zapoznawcza), 16, 15, 14, 13, 12, 11. Społeczność Postgres publikuje nową wersję główną, która zawiera nowe funkcje około raz w roku. Ponadto każda wersja główna otrzymuje okresowe poprawki błędów w postaci wersji pomocniczych. Aktualizacje wersji pomniejszej obejmują zmiany, które są wstecznie kompatybilne z istniejącymi aplikacjami. Serwer elastyczny usługi Azure Database for PostgreSQL okresowo aktualizuje wersje pomocnicze podczas okna obsługi klienta.

Uaktualnienia wersji głównych są bardziej skomplikowane niż uaktualnienia wersji pomocniczej. Mogą one obejmować zmiany wewnętrzne i nowe funkcje, które mogą nie być zgodne z poprzednimi wersjami istniejących aplikacji.

Elastyczny serwer usługi Azure Database dla PostgreSQL ma funkcję, która umożliwia uaktualnienie głównej wersji serwera jednym kliknięciem. Ta funkcja upraszcza proces uaktualniania, minimalizując zakłócenia dla użytkowników i aplikacji, które uzyskują dostęp do serwera.

Uaktualnienia w miejscu zachowują nazwę serwera i inne ustawienia bieżącego serwera po uaktualnieniu wersji głównej. Nie wymagają migracji danych ani zmian w parametry połączenia aplikacji. Uaktualnienia w miejscu są szybsze i wymagają krótszego przestoju niż migracja danych.

Proces uaktualniania

Poniżej przedstawiono niektóre ważne kwestie związane z aktualizacjami na miejscu do wersji głównych:

Przed rozpoczęciem uaktualniania upewnij się, że serwer ma co najmniej 10–20% dostępny bezpłatny magazyn. Podczas procesu uaktualniania tymczasowe pliki dziennika i operacje metadanych mogą zwiększyć użycie dysku. Niewystarczająca ilość wolnego miejsca może spowodować błędy uaktualniania lub problemy z wycofywaniem.
Podczas procesu uaktualniania wersji głównej w miejscu serwer elastyczny usługi Azure Database for PostgreSQL uruchamia procedurę wstępnej kontroli w celu zidentyfikowania potencjalnych problemów, które mogą spowodować niepowodzenie uaktualnienia.
- Jeśli wstępne sprawdzanie wykryje jakiekolwiek niezgodności, tworzy zdarzenie dziennika, które pokazuje, że wstępne sprawdzanie uaktualnienia nie powiodło się wraz z komunikatem o błędzie.
- Jeśli wstępne sprawdzanie zakończy się pomyślnie, serwer elastyczny usługi Azure Database for PostgreSQL zatrzymuje usługę i wykonuje niejawną kopię zapasową tuż przed rozpoczęciem uaktualniania. Usługa może użyć tej kopii zapasowej, aby przywrócić wystąpienie bazy danych do poprzedniej wersji, jeśli pojawi się błąd w trakcie aktualizacji.
Serwer elastyczny usługi Azure Database for PostgreSQL używa narzędzia pg_upgrade w celu przeprowadzania uaktualnień wersji głównych na miejscu. Usługa zapewnia elastyczność pomijania wersji i uaktualniania bezpośrednio do nowszych wersji.
Podczas lokalnego uaktualnienia wersji głównej serwera, który jest skonfigurowany na wysoką dostępność, usługa wyłącza wysoką dostępność, przeprowadza aktualizację na serwerze podstawowym, a następnie ponownie włącza wysoką dostępność po zakończeniu aktualizacji.
Większość rozszerzeń jest automatycznie aktualizowana do nowszych wersji podczas głównego aktualizowania na miejscu z pewnymi wyjątkami.
Proces uaktualniania wersji głównej w miejscu dla serwera elastycznego usługi Azure Database for PostgreSQL automatycznie wdraża najnowszą obsługiwaną wersję pomocniczą.
Uaktualnienie wersji głównej w miejscu jest operacją offline, co oznacza, że serwer będzie niedostępny podczas procesu. Podczas gdy większość uaktualnień kończy się w mniej niż 15 minutach, rzeczywisty czas trwania zależy od rozmiaru i złożoności bazy danych. W szczególności wymagany czas jest bezpośrednio proporcjonalny do liczby obiektów (tabel, indeksów, schematów) w wystąpieniu bazy danych PostgreSQL. Większe lub bardziej złożone schematy mogą mieć dłuższy czas uaktualniania.
Długotrwałe transakcje lub duże obciążenie przed uaktualnieniem może wydłużyć czas potrzebny na zamknięcie bazy danych i zwiększenie czasu uaktualniania.
Po pomyślnym uaktualnieniu wersji głównej na miejscu, nie ma zautomatyzowanych sposobów powrotu do wcześniejszej wersji. Można jednak wykonać odtworzenie do punktu w czasie (PITR) do momentu sprzed uaktualnienia, aby przywrócić poprzednią wersję wystąpienia bazy danych.
Azure Database for PostgreSQL Flexible Server tworzy migawkę bazy danych podczas aktualizacji. Migawka jest wykonywana przed rozpoczęciem uaktualniania. Jeśli uaktualnienie zakończy się niepowodzeniem, system automatycznie przywróci bazę danych do stanu z migawki.
Program PostgreSQL 16 wprowadza środki zabezpieczeń oparte na rolach. Po uaktualnieniu wersji głównej na serwerze elastycznym usługi Azure Database for PostgreSQL pierwszy użytkownik utworzony na serwerze — któremu udzielono opcji ADMIN — będzie teraz miał uprawnienia administracyjne do innych ról na potrzeby podstawowych operacji konserwacji.

Zagadnienia i ograniczenia dotyczące uaktualniania

Jeśli operacja kontroli wstępnej zakończy się niepowodzeniem podczas uaktualniania wersji głównej na miejscu, uaktualnienie zostanie zablokowane ze szczegółowym komunikatem o błędzie. Poniżej przedstawiono znane ograniczenia, które mogą spowodować niepowodzenie uaktualnienia lub nieoczekiwane zachowanie:

Nieobsługiwane konfiguracje serwera

Repliki do odczytu nie są obsługiwane podczas uaktualniania w miejscu. Przed uaktualnieniem serwera podstawowego musisz usunąć replikę do odczytu. Po uaktualnieniu można ponownie utworzyć replikę.
Reguły ruchu sieciowego mogą blokować operacje uaktualniania.
- Upewnij się, że serwer elastyczny może wysyłać/odbierać ruch na portach 5432 i 6432 w sieci wirtualnej oraz do usługi Azure Storage (na potrzeby archiwizacji dzienników).
- Jeśli sieciowe grupy zabezpieczeń (NSG) ograniczają ten ruch, funkcja wysokiej dostępności nie zostanie automatycznie ponownie włączona po uaktualnieniu. Może być konieczne ręczne zaktualizowanie reguł NSG i ponowne włączenie HA.
Sloty replikacji logicznej nie są obsługiwane podczas bezpośrednich aktualizacji wersji głównych.
Serwery korzystające z magazynu SSDv2 nie kwalifikują się do aktualizacji głównych wersji.
Widoki zależne od pg_stat_activity nie są obsługiwane podczas uaktualniania wersji głównych.

Ograniczenia rozszerzeń

Uaktualnienia wersji głównej w miejscu nie obsługują wszystkich rozszerzeń PostgreSQL. Aktualizacja zakończy się niepowodzeniem podczas wstępnego sprawdzania, jeśli zostaną znalezione nieobsługiwane rozszerzenia.

Następujące rozszerzenia nie są obsługiwane w żadnej wersji bazy danych PostgreSQL: timescaledb, , dblinkorafce, , , pg_partmanpostgres_fdw
Następujące rozszerzenia nie są obsługiwane, gdy celem uaktualnienia jest PostgreSQL 16 lub nowszy: pgrouting
Podczas uaktualniania do bazy danych PostgreSQL 17 nie są obsługiwane następujące rozszerzenia: pgrouting, , ageazure_ai, , hllpg_diskann
Rozszerzenia, takie jak pg_repack, i hypopg nie obsługują uaktualnień w miejscu i powinny zostać usunięte przed uaktualnieniem i ponownie utworzone po. Te rozszerzenia nie są trwałe i bezpieczne w celu ponownego skonfigurowania po uaktualnieniu.

Te rozszerzenia należy usunąć z parametru serwera azure.extensions przed uaktualnieniem. Jeśli istnieje, uaktualnienie zostanie zablokowane.

zagadnienia dotyczące PostGIS-Specific

Jeśli używasz programu PostGIS lub jakichkolwiek zależnych rozszerzeń, musisz skonfigurować parametr serwera search_path tak, aby zawierał następujące elementy:

Schematy związane z systemem PostGIS
Rozszerzenia zależne, w tym: postgis, , postgis_rasterpostgis_sfcgal, postgis_tiger_geocoder, postgis_topology, address_standardizer, , address_standardizer_data_usfuzzystrmatch
Błąd konfigurowania search_path może prowadzić do niepowodzenia uaktualniania lub uszkodzonych obiektów po uaktualnieniu.

Inne zagadnienia dotyczące uaktualniania

Duże obiekty (LOs): bazy danych z milionami dużych obiektów (przechowywanych w pg_largeobject) mogą powodować niepowodzenia uaktualnień z powodu dużego użycia pamięci lub woluminu dziennika. Użyj narzędzia vacuumlo, aby wyczyścić nieużywane obiekty LO i rozważyć skalowanie serwera przed uaktualnieniem, jeśli wiele obiektów LO jest nadal używanych.

Ostrzeżenie

Należy zachować ostrożność używając Vacuumlo. vacuumlo identyfikuje osierocone duże obiekty na podstawie konwencjonalnych kolumn referencyjnych (oid, lo). Jeśli aplikacja używa niestandardowych lub pośrednich typów odwołań, prawidłowe duże obiekty mogą zostać błędnie usunięte. vacuumlo Ponadto może zużywać znaczące zasoby CPU, pamięci i operacji we/wy na sekundę (IOPS), szczególnie w bazach danych zawierających miliony dużych obiektów. Uruchom go podczas okienek konserwacyjnych i najpierw przetestuj w środowisku nieprodukcyjnym.

Po aktualizacji

Po zakończeniu aktualizacji do najnowszej głównej wersji zalecamy uruchomienie polecenia ANALYZE w każdej bazie danych, aby odświeżyć tabelę pg_statistic. Brakujące lub nieaktualne statystyki mogą prowadzić do nieoptymalnych planów zapytań, co z kolei może obniżyć wydajność i zająć nadmiar pamięci.

postgres=> analyze;
ANALYZE

Wyświetlanie dzienników uaktualniania

Dzienniki uaktualniania wersji głównej (PG_Upgrade_Logs) zapewniają bezpośredni dostęp do szczegółowych dzienników serwera. Integracja PG_Upgrade_Logs z procesem uaktualniania może pomóc zapewnić bezproblemowe i bardziej przejrzyste przejście do nowych wersji bazy danych PostgreSQL.

Dzienniki uaktualniania wersji głównej można skonfigurować w taki sam sposób jak dzienniki serwera, używając następujących parametrów serwera:

Aby włączyć funkcję, ustaw logfiles.download_enable na ON.
Aby zdefiniować przechowywanie plików dziennika w dniach, użyj polecenia logfiles.retention_days.

Konfigurowanie dzienników uaktualniania

Aby rozpocząć korzystanie z PG_Upgrade_Logs, możesz skonfigurować przechwytywanie dzienników serwera PostgreSQL oraz dzienników aktualizacji do nowszej wersji głównej.

Dostęp do dzienników uaktualniania można uzyskać za pośrednictwem interfejsu użytkownika dla dzienników serwera. W tym miejscu możesz monitorować postęp i szczegóły uaktualnień wersji głównej bazy danych PostgreSQL w czasie rzeczywistym. Ten interfejs użytkownika zapewnia scentralizowaną lokalizację do przeglądania dzienników, dzięki czemu można łatwiej śledzić i rozwiązywać problemy z procesem uaktualniania.

Korzyści wynikające z używania dzienników uaktualniania

Szczegółowe dane diagnostyczne: PG_Upgrade_Logs zapewnia cenny wgląd w proces uaktualniania. Przechwytuje szczegółowe informacje o wykonanych operacjach i wyróżnia wszelkie błędy lub ostrzeżenia, które występują. Ten poziom szczegółowości odgrywa kluczową rolę w diagnozowaniu i rozwiązywaniu problemów, które mogą wystąpić podczas uaktualniania, w celu zapewnienia bezproblemowego przejścia.
Usprawnione rozwiązywanie problemów: dzięki bezpośredniemu dostępowi do tych dzienników można szybko zidentyfikować i rozwiązać potencjalne przeszkody uaktualniania, zmniejszyć przestoje i zminimalizować wpływ na operacje. Dzienniki służą jako kluczowe narzędzie do rozwiązywania problemów, umożliwiając wydajniejsze i skuteczne rozwiązanie problemu.

Uwaga

Uaktualnienia wersji głównej na miejscu są obsługiwane na serwerach automatycznie migrowanych. Po pomyślnej aktualizacji do wersji głównej na zautomatyzowanym serwerze format nazwy użytkownika username@servername nie będzie już obsługiwany. Zamiast tego należy użyć standardowego formatu: nazwa użytkownika. Aby uniknąć problemów z uwierzytelnianiem, dokładnie przejrzyj i zaktualizuj wszystkie parametry połączenia w aplikacjach i skryptach, aby upewnić się, że używają zaktualizowanego formatu nazwy użytkownika po uaktualnieniu.

Udostępnij za pośrednictwem