Zaplanowana konserwacja w usłudze Azure Database for PostgreSQL — serwer elastyczny
DOTYCZY: 
Azure Database for PostgreSQL — serwer elastyczny
Serwer elastyczny usługi Azure Database for PostgreSQL przeprowadza okresową konserwację, aby zapewnić bezpieczeństwo, stabilność i aktualność zarządzanej bazy danych. Podczas konserwacji serwer uzyskuje nowe funkcje, aktualizacje i poprawki.
Ważne
Unikaj wszystkich operacji serwera (modyfikacji, zmian konfiguracji, uruchamiania/zatrzymywania serwera) podczas elastycznej konserwacji serwera 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.
Wybieranie okna obsługi
Konserwację można zaplanować w określonym dniu tygodnia, podając okno czasowe w ciągu tego dnia. Możesz też zezwolić systemowi na automatyczne wybranie dnia i przedziału czasu.
System wysyła powiadomienia o konserwacji z wyprzedzeniem 5 dni, aby przygotować się do tego celu. System informuje również o rozpoczęciu konserwacji i pomyślnym zakończeniu.
Powiadomienia dotyczące nadchodzącej zaplanowanej konserwacji mogą być następujące:
- Wiadomość e-mail na określony adres.
- Wiadomość e-mail do roli usługi Azure Resource Manager.
- Wysłane w wiadomości SMS do urządzeń przenośnych.
- Wypychane jako powiadomienie do aplikacji platformy Azure.
- Dostarczono jako wiadomość głosową.
Podczas określania preferencji dla harmonogramu konserwacji możesz wybrać dzień tygodnia i przedział czasu. Jeśli nie określisz przedziału czasu, system wybierze czasy między 11:00 a 7:00 w czasie regionu serwera. Możesz zdefiniować różne harmonogramy dla każdego wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL w ramach subskrypcji platformy Azure.
Ważne
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ż 5 dni lub pominięte. Aktualizacja krytyczna może zostać zastosowana do serwera, nawet jeśli system pomyślnie wykonał zaplanowaną konserwację w ciągu ostatnich 30 dni.
Ustawienia harmonogramu można aktualizować w dowolnym momencie. Jeśli zaplanowano konserwację wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL i zaktualizowanie preferencji harmonogramu, bieżące wdrożenie będzie kontynuowane zgodnie z harmonogramem. Zmiany ustawień harmonogramu stają się skuteczne po pomyślnym zakończeniu następnej zaplanowanej konserwacji.
Harmonogramy konserwacji zarządzane przez system a niestandardowe
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.
- Zgodnie z niestandardowym harmonogramem możesz określić okno obsługi serwera, wybierając dzień tygodnia i jednogodzinne okno czasu.
Aktualizacje są najpierw stosowane do serwerów z harmonogramami zarządzanymi przez system, a następnie serwerami z niestandardowymi harmonogramami po co najmniej siedmiu dniach w obrębie regionu. Aby otrzymywać wczesne aktualizacje dla serwerów programistycznych i testowych, użyj harmonogramu zarządzanego przez system. Ten wybór 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 zdarzenia konserwacji można anulować przez system lub zakończyć się niepowodzeniem. Jeśli aktualizacja zakończy się niepowodzeniem, zostanie przywrócona, a poprzednia wersja plików binarnych zostanie przywrócona. Serwer może być nadal uruchamiany ponownie w oknie obsługi.
Jeśli aktualizacja zostanie anulowana lub nie powiedzie się, system utworzy 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 pięć dni wcześniej.
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.