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

Serwer elastyczny Azure Database for PostgreSQL obsługuje bazy danych PostgreSQL w wersji 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. Elastyczny serwer usługi Azure Database for PostgreSQL okresowo aktualizuje wersje podrzędne w czasie 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 nie są zgodne z poprzednimi wersjami istniejących aplikacji.

Twój elastyczny serwer Azure Database for PostgreSQL ma funkcję umożliwiającą przeprowadzenie uaktualnienia do nowej wersji głównej serwera w miejscu. 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.

Kontrole poprawności aktualizacji

Azure Database for PostgreSQL — elastyczny serwer udostępnia kontrole weryfikacji uaktualnienia, które pomagają ocenić gotowość do uaktualnienia przed rozpoczęciem uaktualniania do nowej wersji głównej.

Kontrole poprawności aktualizacji przeprowadzają serię weryfikacji zgodności i konfiguracji na serwerze, aby zidentyfikować warunki, które mogą spowodować niepowodzenie aktualizacji lub jej nieoczekiwane działanie. Typowe kontrole obejmują nieobsługiwane rozszerzenia, sloty replikacji logicznej, przygotowane transakcje, wyzwalacze zdarzeń, nieobsługiwane zależności obiektów oraz oczekujące zmiany konfiguracji wymagające ponownego uruchomienia.

Proces weryfikacji jest przeznaczony do oceny gotowości uaktualnienia bez inicjowania rzeczywistej operacji uaktualniania. Te same kontrole poprawności są również wykonywane automatycznie podczas przepływu pracy uaktualniania wersji głównej. Te testy nie modyfikują wersji serwera, wyzwalają przestoje ani ponownie uruchamiają serwera. Uruchom kontrole poprawności przed zaplanowaniem okna uaktualnienia produkcyjnego.

Sprawdzanie poprawności uaktualnienia można uruchomić w portalu Azure lub przy użyciu Azure CLI. Aby uzyskać instrukcje, zobacz Run upgrade validation checks (Uruchamianie sprawdzania poprawności uaktualnienia).

Po zakończeniu walidacji zwracany jest jeden z następujących wyników:

• Nie wykryto żadnych problemów blokujących: Testy poprawności uaktualniania zostały ukończone pomyślnie i nie zidentyfikowały żadnych problemów, które blokują uaktualnienie.
• Wykryto problemy z blokowaniem: Testy sprawdzania poprawności uaktualnienia zidentyfikowały co najmniej jeden problem, który należy rozwiązać przed kontynuowaniem uaktualniania.

W zależności od wyników możesz kontynuować uaktualnianie lub korygować zgłoszone problemy i ponownie uruchomić walidację.

Ograniczenia

W przypadku korzystania z testów weryfikacji uaktualnienia należy wziąć pod uwagę następujące ograniczenia:

• Stan serwera musi być gotowy.
• Sprawdzanie poprawności nie jest obsługiwane w replikach do odczytu.
• Walidacja nie może zostać uruchomiona, gdy inna operacja serwera jest już w toku.
• Sprawdzanie poprawności wymaga łączności ze wszystkimi bazami danych na serwerze. Nieodpowiadalne lub niedostępne bazy danych mogą powodować błędy walidacji.
• Mimo że sprawdzanie poprawności nie powoduje przestoju, rozważ ich uruchomienie w okresach mniejszej aktywności bazy danych.

Aby uzyskać instrukcje krok po kroku, zobacz Run upgrade validation checks (Uruchamianie testów weryfikacji uaktualnienia).

Proces uaktualniania

Oto kilka ważnych kwestii dotyczących aktualizacji głównych wersji na miejscu:

• Przed rozpoczęciem aktualizacji upewnij się, że na serwerze jest dostępne co najmniej 10–20% wolnego miejsca na dysku. 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 miejscowego uaktualnienia do nowszej wersji głównej serwer elastyczny usługi Azure Database for PostgreSQL uruchamia procedurę kontroli wstępnej, aby zidentyfikować wszelkie potencjalne problemy, które mogłyby 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, Azure Database for PostgreSQL serwer elastyczny zatrzymuje usługę i wykonuje niejawną kopię zapasową tuż przed rozpoczęciem uaktualniania. Usługa może użyć tej ukrytej kopii zapasowej, aby przywrócić instancję bazy danych do poprzedniej wersji, jeśli podczas uaktualniania wystąpi błąd.
• Elastyczny serwer usługi Azure Database for PostgreSQL korzysta z narzędzia pg_upgrade do przeprowadzania uaktualnień głównych wersji w miejscu. Usługa zapewnia elastyczność pomijania wersji i uaktualniania bezpośrednio do nowszych wersji.
• Podczas uaktualniania miejscowego głównej wersji serwera, na którym włączono funkcję wysokiej dostępności (HA), usługa wyłącza HA, przeprowadza uaktualnienie na serwerze podstawowym, a następnie ponownie włącza HA po zakończeniu uaktualnienia. Ponowne włączenie wysokiej dostępności wymaga wystarczającej pojemności do utworzenia nowego wystąpienia rezerwowego.
• 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 Azure Database for PostgreSQL automatycznie wdraża najnowszą obsługiwaną wersję pomocniczą.
• Czas trwania uaktualniania zależy od rozmiaru i złożoności bazy danych, w tym liczby obiektów (tabel, indeksów, schematów), dużych obiektów i rozszerzeń. Większe lub bardziej złożone obciążenia 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. Odzyskiwanie do punktu w czasie (PITR) można wykonać do czasu przed uaktualnieniem, aby przywrócić poprzednią wersję na nowym serwerze.
• Zabezpieczanie serwera Azure Database for PostgreSQL. Po uaktualnieniu wersji głównej na serwerze elastycznym Azure Database for PostgreSQL pierwszy użytkownik utworzony na serwerze, któremu udzielono opcji ADMIN, ma teraz uprawnienia administracyjne do innych ról na potrzeby podstawowych operacji konserwacji.

Zagadnienia i ograniczenia dotyczące uaktualniania

Jeśli operacja wstępnej kontroli zakończy się niepowodzeniem podczas uaktualniania wersji głównej w miejscu, proces uaktualniania zostanie zatrzymany i zostanie wyświetlony szczegółowy komunikat o błędzie. Następujące znane ograniczenia mogą spowodować niepowodzenie uaktualnienia lub nieoczekiwanie zachowywać się:

Nieobsługiwane konfiguracje serwera

• Replikacja geograficzna w Azure Database for PostgreSQL nie jest obsługiwana podczas uaktualnień w miejscu. Przed zaktualizowaniem serwera podstawowego należy usunąć replikę do odczytu (w tym każdą kaskadową 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ć i odbierać ruch na portach 5432 i 6432 w sieci wirtualnej oraz do Azure Storage (na potrzeby archiwizowania dzienników).
  • Jeśli sieciowe grupy zabezpieczeń ograniczają ten ruch, wysoka dostępność (HA) nie zostanie automatycznie ponownie włączona po uaktualnieniu. Może być konieczne ręczne zaktualizowanie reguł NSG i ponowne włączenie HA.
• Widoki zależne od pg_stat_activity nie są obsługiwane podczas uaktualniania wersji głównych.
• W przypadku uaktualniania z bazy danych PostgreSQL 11 do nowszej wersji należy najpierw skonfigurować serwer elastyczny do korzystania z uwierzytelniania SCRAM , włączając funkcję SCRAM i resetując wszystkie hasła roli uwierzytelniania.

Ograniczenia rozszerzeń

Uaktualnienia wersji głównej w miejscu nie obsługują wszystkich rozszerzeń bazy danych PostgreSQL. Aktualizacja kończy się niepowodzeniem podczas kontroli wstępnej, jeśli na ścieżce aktualizacji, której dotyczy problem, występuje zablokowane rozszerzenie. Większość bloków jest ograniczona do określonych wersji docelowych (a czasami źródłowych) zamiast każdego uaktualnienia, jak wspomniano na poniższych listach.

• Następujące rozszerzenia blokują aktualizację na miejscu do nowej wersji głównej na wszystkich ścieżkach aktualizacji. Usuń je przed uaktualnieniem i ponownie włącz je po, jeśli są obsługiwane w wersji docelowej: session_variable, , anonage.

• Następujące rozszerzenia są nieutrwalanymi rozszerzeniami narzędziowymi i zgodnie z założeniem muszą zostać usunięte przed uaktualnieniem i ponownie utworzone po nim (we wszystkich ścieżkach uaktualniania): pg_repack, hypopg, pg_partman.

• Następujące rozszerzenia są blokowane tylko w określonych ścieżkach wersji. Usuń je przed uaktualnieniem, jeśli uaktualnienie jest zgodne z wyświetlonym warunkiem, i ponownie włącz je po, jeśli jest obsługiwane w wersji docelowej:

  Extension	Zablokowane, gdy
  pg_hint_plan	Wersja docelowa to PostgreSQL 14
  semver	Wersja docelowa to PostgreSQL 16 lub 17
  azure_local_ai	Wersja docelowa to PostgreSQL 17 lub 18
  pg_failover_slots	Wersja docelowa to PostgreSQL 17 lub 18 (udostępniona biblioteka wstępnego ładowania)
  azure_ai	Wersja docelowa to PostgreSQL 18
  azure_storage	Wersja docelowa to PostgreSQL 18
  pg_diskann	Wersja docelowa to PostgreSQL 18
  pgrouting	Wersja docelowa to PostgreSQL 15; lub źródło jest starsze niż PostgreSQL 16, a obiekt docelowy to PostgreSQL 16 lub nowszy; lub wersja docelowa to PostgreSQL 18
  orafce	Wersja źródłowa to PostgreSQL 11, 12 lub 13

• Następujące rozszerzenia są blokowane, gdy inne obiekty bazy danych zależą od ich obiektów, ponieważ uaktualnienie w przeciwnym razie zakończy się niepowodzeniem. Rozwiąż zależności przed uaktualnieniem:

  • pg_stat_statements: zablokowany, gdy inne obiekty zależą od jego widoku lub funkcji, co może spowodować ALTER EXTENSION pg_stat_statements UPDATE niepowodzenie. Najpierw usuń obiekty zależne.
  • pgcrypto: po zainstalowaniu w schemacie pg_catalog i uaktualnieniu z bazy danych PostgreSQL 11 lub 12 do bazy danych PostgreSQL 13 lub nowszej zablokowane, gdy obiekty klienta zależą od niego (konflikt z wbudowaną gen_random_uuid() funkcją). Najpierw przenieś rozszerzenie do innego schematu lub upuść obiekty zależne.

Zagadnienia specyficzne dla systemu PostGIS

Jeśli używasz programu PostGIS lub jakichkolwiek rozszerzeń zależnych, skonfiguruj search_path parametr 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
• Jeśli nie skonfigurujesz search_path poprawnie, uaktualnienie może zakończyć się niepowodzeniem lub przerwać obiekty po uaktualnieniu.

Zagadnienia specyficzne dla bazy danych TimescaleDB

Jeśli używasz TimescaleDB, uaktualnienia głównej wersji w miejscu są obsługiwane tylko dla określonych kombinacji źródłowej i docelowej wersji PostgreSQL:

Jeśli ścieżka aktualizacji TimescaleDB nie jest uwzględniona w macierzy obsługiwanych ścieżek, aktualizacja w miejscu do nowej wersji głównej jest zablokowana. Aby kontynuować, upuść rozszerzenie TimescaleDB przed uaktualnieniem, jeśli jest to możliwe, lub użyj alternatywnego podejścia migracji, takiego jak migracja równoległa z replikacją logiczną.

Przed rozpoczęciem uaktualniania upewnij się, że wersje źródłowe i docelowe są uwzględnione w obsługiwanej macierzy.

Inne zagadnienia dotyczące uaktualniania

• Uaktualnienie wersji głównej w miejscu korzysta z zasobów procesora CPU i pamięci dostępnych na bieżącej jednostce SKU obliczeniowej serwera. Operacje uaktualniania mogą wymagać więcej zasobów niż normalne obciążenie środowiska uruchomieniowego serwera, w zależności od rozmiaru bazy danych, złożoności schematu i konfiguracji.
• W przypadku serwerów z ograniczonym zapasem zasobów, w tym mniejszych jednostek SKU z serii Burstable, rozważ tymczasowe przeskalowanie do większej jednostki SKU mocy obliczeniowej przed uaktualnieniem, a następnie powrót do poprzedniego rozmiaru po jego zakończeniu. To wymaganie nie jest konieczne dla wszystkich serwerów typu Burstable; potrzeba dodatkowych zasobów zależy od obciążenia i konfiguracji serwera.
• Wyzwalacze zdarzeń: kontrola przed aktualizacją blokuje wyzwalacze zdarzeń, ponieważ są one powiązane z poleceniami DDL i mogą odwoływać się do katalogów systemowych, które zmieniają się między głównymi wersjami. Przed aktualizacją usuń wszystkie elementy EVENT TRIGGER, a następnie odtwórz je po aktualizacji, aby zapewnić jej bezproblemowy przebieg.
• Duże obiekty (LO): Sposób, w jaki uaktualnienie obsługuje bazy danych zawierające miliony dużych obiektów (przechowywanych w pg_largeobject), zależy od docelowej wersji głównej:
  • Docelowy program PostgreSQL 15 lub nowszy: uaktualnienie używa zoptymalizowanej metody zbiorczej do transferu dużych metadanych obiektów, więc użycie pamięci i dysku tymczasowego nie jest już skalowane z liczbą dużych obiektów. Bazy danych z dziesiątkami lub setkami milionów dużych obiektów są niezawodnie uaktualniane bez dodatkowego przygotowania. Uruchamianie vacuumlo ani wcześniejsze skalowanie serwera w górę nie jest konieczne, aby obejść problem dużej liczby dużych obiektów, chociaż nadal możesz uruchomić vacuumlo, aby usunąć nieużywane duże obiekty z innych powodów.
  • Docelowy program PostgreSQL 14 lub starszy: bazy danych z milionami dużych obiektów mogą powodować błędy uaktualniania z powodu dużego użycia pamięci lub woluminu dziennika. Użyj narzędzia vacuumlo , aby wyczyścić nieużywane duże obiekty i rozważ skalowanie serwera przed uaktualnieniem, jeśli wiele dużych obiektów jest nadal używanych.

Po aktualizacji

Po zakończeniu aktualizacji do nowej wersji głównej uruchom polecenie 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

Użyj PG_Upgrade_Logs do monitorowania postępu uaktualnienia i rozwiązywania problemów. Przejrzyj dzienniki podczas i po uaktualnieniu, aby śledzić postęp, diagnozować błędy lub opóźnienia oraz identyfikować problemy blokujące, aby umożliwić szybkie podjęcie działań naprawczych.

Włączanie dzienników uaktualniania przy użyciu parametrów dziennika serwera

• Ustaw logfiles.download_enable na WŁĄCZONE.
• Skonfiguruj przechowywanie za pomocą polecenia logfiles.retention_days.

Zobacz Pobieranie PostgreSQL i dzienników aktualizacji, aby rozpocząć pracę.

Treści powiązane

• Uaktualnienie wersji głównej
• Uruchamianie testów weryfikacji uaktualnienia