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 1-godzinne 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 1-godzinne 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 7 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 serwerów niestandardowych harmonogramu rozpoczynają się 7 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 z 5 dni wcześniej.

Następne kroki

• Dowiedz się, jak zmienić harmonogram konserwacji.
• Dowiedz się, jak otrzymywać powiadomienia o nadchodzącej konserwacji przy użyciu usługi Azure Service Health.
• Dowiedz się, jak skonfigurować alerty dla nadchodzących zaplanowanych zdarzeń konserwacji.