Udostępnij za pomocą

Uaktualnienia wersji głównych w usłudze Azure Database for PostgreSQL

Wystąpienie elastycznego serwera Azure Database for PostgreSQL obsługuje wersje PostgreSQL: 18, 17, 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. Instancja serwera elastycznego usługi Azure Database for PostgreSQL okresowo aktualizuje wersje pomniejsze podczas okna konserwacji 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.

Instancja elastycznego serwera bazy danych Azure Database for PostgreSQL ma funkcję, która umożliwia aktualizację 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.

Uwaga

Usługa Azure Database for PostgreSQL obsługuje na miejscu uaktualnienia wersji głównych tylko do obecnie obsługiwanych wersji PostgreSQL. Na przykład możesz uaktualnić bieżącą wersję, biorąc pod uwagę, że wersja docelowa jest oficjalnie obsługiwana przez platformę Azure w momencie uaktualnienia. Nie można wybrać nieobsługiwanych wersji jako celów uaktualnienia, a próba uaktualnienia do wersji o statusie przestarzałym może spowodować awarię lub zakłócenia w działaniu usługi. Przed zainicjowaniem uaktualnienia wersji należy zawsze zapoznać się z zasadami wersjonowania usługi Azure PostgreSQL oraz dokumentacją dotyczącą uaktualnień.

Uwaga

Uaktualnienia wersji głównej do bazy danych PostgreSQL 18 są włączane w fazach. Obecnie MVU do PostgreSQL 18 jest dostępny w regionach AustraliaSoutheast, CanadaCentral, CentralIndia, CentralUS, EastAsia, EastUS, EastUS2, NorthCentralUS, SouthAfricaNorth, SouthCentralUS, SwedenCentral, WestCentralUS, WestUS2 i WestUS3.

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 głównej wersji na miejscu, wystąpienie serwera elastycznego Azure Database for PostgreSQL uruchamia procedurę wstępnej kontroli, aby zidentyfikować wszelkie potencjalne problemy, 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 sprawdzenie zakończy się pomyślnie, elastyczny serwer Azure Database for PostgreSQL zatrzymuje usługę i wykonuje niejawną kopię zapasową tuż przed rozpoczęciem aktualizacji. 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.
  • Elastyczna instancja serwera usługi Azure Database for PostgreSQL używa narzędzia pg_upgrade do wykonywania uaktualnień wersji głównych. 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 ulepszenia wersji głównej bez zmian lokalizacji wystąpienia elastycznego serwera 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.
  • Serwer elastyczny usługi Azure Database for PostgreSQL tworzy zrzut bazy danych w trakcie 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 w wystąpieniu serwera elastycznego 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 należy usunąć replikę do odczytu (w tym dowolną kaskadowo replikę do odczytu). Po uaktualnieniu można ponownie utworzyć replikę.
  • Reguły ruchu sieciowego mogą blokować operacje uaktualniania.
    • Upewnij się, że instancja elastycznego serwera może wysyłać i odbierać ruch na portach 5432 i 6432 w swojej sieci wirtualnej oraz do usługi Azure Storage, przeznaczonej na archiwizację 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.
  • Jeśli przeprowadzasz uaktualnienie z PG11 do nowszej wersji, musisz najpierw skonfigurować serwer elastyczny do korzystania z uwierzytelniania SCRAM, poprzez włączenie SCRAM i resetowanie wszystkich haseł roli logowania.

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 są obsługiwane do zwykłego użycia, ale będą blokować aktualizację głównej wersji na miejscu, jeśli będą obecne. Usuń je przed uaktualnieniem i włącz je ponownie po, jeśli są obsługiwane w wersji docelowej: timescaledb, , dblinkorafce, . postgres_fdw
  • Następujące rozszerzenia są rozszerzeniami narzędzi nietrwałymi i należy je usunąć i ponownie utworzyć po uaktualnieniu zgodnie z projektem: pg_repack, hypopg.
  • Podczas uaktualniania do programu PostgreSQL 17 następujące rozszerzenia nie są obsługiwane i należy je usunąć przed uaktualnieniem. Można je ponownie włączyć tylko wtedy, gdy są obsługiwane w wersji docelowej: age, , azure_aihll, pg_diskann, . pgrouting

Nuta: Jeśli którekolwiek z tych rozszerzeń pojawi się w parametrze azure.extensions serwera, uaktualnienie zostanie zablokowane. Usuń je z parametru przed rozpoczęciem uaktualniania.

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

  • Wyzwalacze zdarzeń: uaktualnianie wstępnego sprawdzania blokuje wyzwalacze zdarzeń, ponieważ są one podłączone do poleceń DDL i mogą odwoływać się do katalogów systemowych, które zmieniają się między wersjami głównymi — upuść wszystkie EVENT TRIGGERs przed uaktualnieniem, a następnie ponownie utworzyć je po uaktualnieniu, aby zapewnić bezproblemowe uaktualnienie.
  • 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.

Powiązana zawartość

  • Last updated on