Udostępnij za pomocą

Konserwacja zaplanowana

Aby zapewnić bezpieczeństwo, stabilność i aktualność zarządzanej bazy danych, wystąpienie serwera elastycznego usługi Azure Database for PostgreSQL okresowo wykonuje operacje konserwacji. Podczas konserwacji serwer uzyskuje nowe funkcje, aktualizacje i poprawki.

Important

Unikaj wszystkich operacji na serwerze (modyfikacji, zmian konfiguracji, uruchamiania/zatrzymywania serwera) w trakcie konserwacji instancji serwera elastycznego usługi Azure Database for PostgreSQL. Angażowanie się w te działania może prowadzić do nieprzewidywalnych wyników i potencjalnie wpływać na wydajność i stabilność serwera. Przed przeprowadzeniem operacji serwera poczekaj na zakończenie konserwacji.

Okno obsługi

Możesz zaplanować konserwację w określonym dniu tygodnia oraz przedział czasu w tym dniu. Możesz też zezwolić systemowi na automatyczne wybranie dnia i przedziału czasu.

System wysyła powiadomienia o konserwacji z 5 dni kalendarzowych z wyprzedzeniem, dzięki czemu masz czas na przygotowanie. System informuje również o tym, kiedy rozpocznie się konserwacja i kiedy zakończy się pomyślnie.

Powiadomienia o nadchodzącej zaplanowanej konserwacji można otrzymywać za pośrednictwem:

  • Wyślij wiadomość e-mail na określony adres.
  • Wyślij wiadomość e-mail do roli Azure Resource Manager.
  • Wiadomość SMS do urządzeń przenośnych.
  • Wysyłanie powiadomień push do aplikacji platformy Azure.
  • Wiadomość głosowa.

Podczas określania preferencji dla harmonogramu konserwacji można wybrać harmonogram niestandardowy i harmonogram zarządzany przez system. Jeśli zdecydujesz się na harmonogram niestandardowy, możesz określić dzień tygodnia i przedział czasu. Jeśli jednak wybierzesz harmonogram zarządzany przez system, system wybierze dla Ciebie dzień. W ciągu tego dnia wybiera jednogodzinne przedział czasu z zakresu od 11:00 do 7:00 w regionie serwera. Dla każdego wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL można skonfigurować różne harmonogramy konserwacji.

Important

Zwykle interwał między pomyślnymi zdarzeniami konserwacji zaplanowanej dla serwera wynosi co najmniej 30 dni. Jednak w przypadku krytycznej aktualizacji awaryjnej, takiej jak poważna luka w zabezpieczeniach, okno powiadomień może być krótsze niż pięć dni, a nawet pominięte. Aktualizacja krytyczna może zostać zastosowana na serwerze, nawet jeśli system wykonał zaplanowaną konserwację w ciągu ostatnich 30 dni.

Ustawienia zaplanowanej konserwacji można zaktualizować w dowolnym momencie. Jeśli zaplanowano konserwację wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL i zaktualizujesz preferencje zaplanowanej konserwacji, bieżące wdrożenie nie zostanie przeprogramowane. Jest on kontynuowany w dniu i o godzinie, kiedy został już zaplanowany. Zmiany ustawień konserwacji zaplanowanej stają się skuteczne po pomyślnym zakończeniu następnej zaplanowanej konserwacji.

Konserwacja zarządzana przez system a niestandardowa

Harmonogram zarządzany przez system lub niestandardowy harmonogram dla każdego wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL można zdefiniować w ramach subskrypcji platformy Azure:

  • Zgodnie z harmonogramem zarządzanym przez system system system wybiera dowolne jednogodzinne okno od 11:00 do 7:00 w czasie regionu serwera.
  • Za pomocą niestandardowego harmonogramu można określić okno obsługi serwera, wybierając dzień tygodnia i godzinę rozpoczęcia przedziału czasu jednego godziny.

Zaplanowana konserwacja odbywa się najpierw na serwerach skonfigurowanych z harmonogramami zarządzanymi przez system. Serwery z niestandardowymi harmonogramami działają po co najmniej siedmiu dniach w ramach regionu. Aby otrzymywać wczesne aktualizacje dla serwerów programistycznych i testowych, użyj harmonogramu zarządzanego przez system. Ten wybór harmonogramu umożliwia wczesne testowanie i rozwiązywanie problemów, zanim aktualizacje dotrą do serwerów produkcyjnych z niestandardowymi harmonogramami.

Aktualizacje dla serwerów niestandardowych harmonogramu rozpoczynają się siedem dni później podczas zdefiniowanego okna obsługi. Po powiadomieniu nie można odroczyć aktualizacji. Zalecamy używanie niestandardowych harmonogramów tylko dla środowisk produkcyjnych.

W rzadkich przypadkach system może anulować niektóre zdarzenia konserwacji lub niektóre zdarzenia mogą zakończyć się niepowodzeniem. Jeśli aktualizacja zakończy się niepowodzeniem, proces zostanie wycofany i serwer przywrócony do poprzedniej wersji plików binarnych. Serwer może być nadal uruchamiany ponownie w oknie obsługi.

Jeśli aktualizacja została anulowana lub nie powiodła się, system generuje powiadomienie o anulowanym lub nieudanym zdarzeniu konserwacji. Kolejna próba przeprowadzenia konserwacji jest zaplanowana zgodnie z bieżącymi ustawieniami harmonogramu i otrzymasz powiadomienie o nim z 5 dni kalendarzowych z wyprzedzeniem.

Zagadnienia do rozważenia i ograniczenia

Niektóre zagadnienia dotyczące rozważania podczas miesięcznej konserwacji:

  • Miesięczna konserwacja ma wpływ i wiąże się z pewnymi przestojami.
  • Przestój zależy od obciążenia transakcyjnego serwera w czasie konserwacji.
  • Po zaplanowaniu konserwacji wszelkie zmiany ustawień konserwacji będą stosowane tylko do następnego cyklu konserwacji, a nie bieżącego.

Przeprowadzanie konserwacji na zatrzymanych/wyłączonych wystąpieniach

Jeśli serwer PostgreSQL zostanie zatrzymany podczas zaplanowanej konserwacji, konserwacja nie zostanie zastosowana natychmiast. Zamiast tego konserwacja zostanie zastosowana po ponownym uruchomieniu serwera ręcznie przez klienta lub automatycznie za pośrednictwem 7-dniowej funkcji automatycznego ponownego uruchamiania . Powiadomienie zostanie wysłane do klienta z informacją, że nie można zastosować konserwacji, ponieważ serwer zostanie zatrzymany i zostanie zastosowany po ponownym uruchomieniu serwera.

Klienci mogą zauważyć niewielki wzrost czasu ponownego uruchomienia (5–8 minut) podczas oczekiwania na konserwację, szczególnie podczas ręcznego ponownego uruchamiania.

Treści powiązane

  • Last updated on