Powiadomienie o planowanej konserwacji w usłudze Azure Database for MySQL — pojedynczy serwer

  • Artykuł

DOTYCZY: Azure Database for MySQL — pojedynczy serwer

Ważne

Pojedynczy serwer usługi Azure Database for MySQL znajduje się na ścieżce wycofania. Zdecydowanie zalecamy uaktualnienie do serwera elastycznego usługi Azure Database for MySQL. Aby uzyskać więcej informacji na temat migracji do serwera elastycznego usługi Azure Database for MySQL, zobacz Co się dzieje z usługą Azure Database for MySQL — pojedynczy serwer?

Dowiedz się, jak przygotować się do zdarzeń planowanej konserwacji w usłudze Azure Database for MySQL.

Co to jest planowana konserwacja?

Usługa Azure Database for MySQL wykonuje automatyczne stosowanie poprawek podstawowego sprzętu, systemu operacyjnego i aparatu bazy danych. Poprawka zawiera nowe funkcje usługi, zabezpieczenia i aktualizacje oprogramowania. W przypadku aparatu MySQL uaktualnienia wersji pomocniczej są automatyczne i uwzględniane w ramach cyklu stosowania poprawek. W przypadku stosowania poprawek nie jest wymagana żadna akcja użytkownika ani ustawienia konfiguracji. Poprawka jest szeroko testowana i wdrażana przy użyciu bezpiecznych praktyk wdrażania.

Planowana konserwacja to okno obsługi, gdy te aktualizacje usługi są wdrażane na serwerach w danym regionie świadczenia usługi Azure. Podczas planowanej konserwacji jest tworzone zdarzenie powiadomienia informujące klientów o wdrożeniu aktualizacji usługi w regionie świadczenia platformy Azure, w którym serwery są hostowane. Minimalny czas trwania między dwiema planowaną konserwacją wynosi 30 dni. 72 godziny wcześniej otrzymasz powiadomienie o następnym oknie obsługi.

Planowana konserwacja — czas trwania i wpływ na klientów

Planowana konserwacja dla danego regionu świadczenia platformy Azure zazwyczaj trwa 15 godzin. Okno zawiera również czas buforu, aby w razie potrzeby wykonać plan wycofywania. Podczas planowanej konserwacji może istnieć ponowne uruchomienie serwera bazy danych lub przejście w tryb failover, co może prowadzić do krótkiej niedostępności serwerów baz danych dla użytkowników końcowych. Serwery usługi Azure Database for MySQL są uruchomione w kontenerach, więc ponowne uruchomienie serwera bazy danych jest zwykle szybkie, oczekiwane zazwyczaj w ciągu 60–120 sekund. Całe zdarzenie planowanej konserwacji, w tym każde ponowne uruchomienie serwera, jest dokładnie monitorowane przez zespół inżynierów. Czas pracy w trybie failover serwera zależy od czasu odzyskiwania bazy danych, co może spowodować, że baza danych będzie w trybie online dłużej, jeśli w momencie przejścia w tryb failover na serwerze występuje duża aktywność transakcyjna. Aby uniknąć dłuższego czasu ponownego uruchamiania, zaleca się unikanie długotrwałych transakcji (obciążeń zbiorczych) podczas planowanych zdarzeń konserwacji.

Podsumowując, podczas gdy zdarzenie planowanej konserwacji działa przez 15 godzin, wpływ poszczególnych serwerów trwa zazwyczaj 60 sekund w zależności od działania transakcyjnego na serwerze. Powiadomienie jest wysyłane 72 godziny kalendarzowe przed rozpoczęciem planowanej konserwacji, a drugi, gdy konserwacja jest w toku dla danego regionu.

Jak mogę otrzymywać powiadomienia o planowanej konserwacji?

Możesz użyć funkcji powiadomień dotyczących planowanej konserwacji, aby otrzymywać alerty dotyczące nadchodzącego zdarzenia planowanej konserwacji. Otrzymasz powiadomienie o nadchodzącej konserwacji 72 godziny kalendarzowej przed wydarzeniem, a drugie, gdy konserwacja jest w toku dla danego regionu.

Powiadomienie o planowanej konserwacji

Ważne

Powiadomienia o planowanej konserwacji są obecnie dostępne w wersji zapoznawczej we wszystkich regionach z wyjątkiem zachodnio-środkowych stanów USA

Powiadomienia o planowanej konserwacji umożliwiają otrzymywanie alertów dotyczących nadchodzącego zdarzenia planowanej konserwacji w usłudze Azure Database for MySQL. Te powiadomienia są zintegrowane z planowaną konserwacją usługi Service Health i umożliwiają wyświetlanie wszystkich zaplanowanych konserwacji subskrypcji w jednym miejscu. Pomaga to również w skalowaniu powiadomienia do odpowiednich odbiorców w przypadku różnych grup zasobów, ponieważ możesz mieć różne kontakty odpowiedzialne za różne zasoby. Otrzymasz powiadomienie o nadchodzącej konserwacji 72 godziny kalendarzowe przed wydarzeniem.

Podejmiemy każdą próbę dostarczenia powiadomienia o planowanej konserwacji 72 godziny dla wszystkich zdarzeń. Jednakże w przypadku krytycznych poprawek lub poprawek zabezpieczeń powiadomienia mogą być wysyłane bliżej zdarzenia lub zostać pominięte.

Możesz sprawdzić powiadomienie o planowanej konserwacji w witrynie Azure Portal lub skonfigurować alerty do odbierania powiadomień.

Sprawdzanie powiadomienia o planowanej konserwacji w witrynie Azure Portal

  1. W witrynie Azure Portal wybierz pozycję Service Health.
  2. Wybierz kartę Planowana konserwacja
  3. Wybierz pozycję Subskrypcja, Region i Usługa , dla której chcesz sprawdzić powiadomienie o planowanej konserwacji.

Aby otrzymywać powiadomienie o planowanej konserwacji:

  1. W portalu wybierz pozycję Service Health.
  2. W sekcji Alerty wybierz pozycję Alerty dotyczące kondycji.
  3. Wybierz pozycję + Dodaj alert dotyczący kondycji usługi i wypełnij pola.
  4. Wypełnij wymagane pola.
  5. Wybierz typ zdarzenia, wybierz pozycję Planowana konserwacja lub Wybierz wszystko
  6. W obszarze Grupy akcji zdefiniuj sposób odbierania alertu (uzyskiwanie wiadomości e-mail, wyzwalanie aplikacji logiki itp.)
  7. Upewnij się, że ustawienie Włącz regułę po utworzeniu ma wartość Tak.
  8. Wybierz pozycję Utwórz regułę alertu, aby zdefiniować alert

Aby uzyskać szczegółowe instrukcje dotyczące tworzenia alertów dotyczących kondycji usługi, zobacz Tworzenie alertów dziennika aktywności dotyczących powiadomień usługi.

Czy mogę anulować lub odroczyć planowaną konserwację?

Konserwacja jest wymagana, aby zapewnić bezpieczeństwo, stabilność i aktualność serwera. Nie można anulować ani odroczyć zdarzenia planowanej konserwacji. Po wysłaniu powiadomienia do danego regionu świadczenia usługi Azure nie można wprowadzić zmian harmonogramu poprawek dla żadnego pojedynczego serwera w tym regionie. Poprawka jest wdrażana dla całego regionu jednocześnie. Usługa Azure Database for MySQL — pojedynczy serwer została zaprojektowana z myślą o natywnej aplikacji w chmurze, która nie wymaga szczegółowej kontroli ani dostosowywania usługi. Jeśli chcesz mieć możliwość planowania konserwacji serwerów, zalecamy rozważenie serwerów elastycznych.

Czy we wszystkich regionach świadczenia platformy Azure poprawki są stosowane w tym samym czasie?

Nie, wszystkie regiony platformy Azure są poprawiane podczas chronometrażu okna mądrego wdrożenia. Okno mądre wdrożenia zwykle rozciąga się od 17:00 do 8:00 czasu lokalnego następnego dnia w danym regionie świadczenia usługi Azure. Regiony platformy Azure sparowane geograficznie są poprawiane w różnych dniach. W przypadku wysokiej dostępności i ciągłości działania serwerów baz danych zaleca się korzystanie z replik do odczytu między regionami .

Logika ponowień

Błąd przejściowy, znany również jako błąd przejściowy, jest błędem, który sam się rozwiąże. Błędy przejściowe mogą wystąpić podczas konserwacji. Większość z tych zdarzeń jest automatycznie ograniczana przez system w mniej niż 60 sekund. Błędy przejściowe powinny być obsługiwane przy użyciu logiki ponawiania prób.

Następne kroki