Zaplanowana konserwacja w usłudze Azure Database for MySQL — serwer elastyczny

  • Artykuł

DOTYCZY: Azure Database for MySQL — serwer elastyczny

Serwer elastyczny usługi Azure Database for MySQL 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 MySQL. Angażowanie się w te działania może prowadzić do nieprzewidywalnych wyników, co może mieć wpływ na wydajność i stabilność serwera. Poczekaj na zakończenie konserwacji przed przeprowadzeniem operacji serwera.

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. Tak czy inaczej, system powiadomi Cię o siedmiu dniach przed uruchomieniem jakiejkolwiek konserwacji. System poinformuje Cię 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 na urządzenia przenośne
  • wypychane jako powiadomienie do aplikacji platformy Azure
  • dostarczone jako wiadomość głosowa

Określając preferencje dla harmonogramu konserwacji, można wybrać dzień tygodnia i przedział czasu. Jeśli nie zostanie to określone, system wybierze godzinę między 23:00 a 7:00 czasu regionu serwera. Możesz zdefiniować różne harmonogramy dla każdego serwera elastycznego w ramach subskrypcji platformy Azure.

Ważne

Zwykle między pomyślnymi zdarzeniami konserwacji zaplanowanej dla serwera istnieje odstęp 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ż siedem dni. Aktualizacja krytyczna może zostać zastosowana do serwera, nawet jeśli konserwacja zaplanowana została wykonana w ciągu ostatnich 30 dni.

Ustawienia planowania można aktualizować w dowolnym momencie. Jeśli na serwerze elastycznym zaplanowano konserwację i zaktualizujesz preferencje planowania, bieżące wdrożenie będzie kontynuowane zgodnie z harmonogramem, a zmiana ustawień harmonogramu stanie się skuteczna po pomyślnym zakończeniu następnej zaplanowanej konserwacji.

Można zdefiniować harmonogram zarządzany przez system lub niestandardowy harmonogram dla każdego serwera elastycznego w ramach subskrypcji platformy Azure.

  • Za pomocą niestandardowego harmonogramu można określić okno obsługi serwera, wybierając dzień tygodnia i jednogodzinne okno czasowe.
  • Zgodnie z harmonogramem zarządzanym przez system system system wybierze dowolne jednogodzinne okno między godziną 11:00 a 7:00 w czasie regionu serwera.

Ważne

Wcześniej zachowano 7-dniową lukę wdrożenia między harmonogramami zarządzanymi przez system i niestandardowymi. Ze względu na zmieniające się wymagania dotyczące konserwacji i wprowadzenie funkcji zmiany harmonogramu konserwacji (publiczna wersja zapoznawcza) nie możemy już zagwarantować tej 7-dniowej przerwy.

W rzadkich przypadkach zdarzenie konserwacji może zostać anulowane przez system lub może zakończyć się niepowodzeniem. Jeśli aktualizacja zakończy się niepowodzeniem, aktualizacja zostanie przywrócona, a poprzednia wersja plików binarnych zostanie przywrócona. W takich scenariuszach aktualizacji, które zakończyły się niepowodzeniem, podczas okna obsługi nadal może wystąpić ponowne uruchomienie serwera. Jeśli aktualizacja została anulowana lub nie powiodła się, system utworzy powiadomienie o anulowanym lub nieudanym zdarzeniu konserwacji. Kolejna próba przeprowadzenia konserwacji zostanie zaplanowana zgodnie z bieżącymi ustawieniami planowania i otrzymasz powiadomienie o niej z 5 dni wcześniej.

Konserwacja niemal zerowa przestojów (publiczna wersja zapoznawcza)

Funkcja "Niemal zerowej konserwacji przestojów" serwera elastycznego usługi Azure Database for MySQL to przełomowa funkcja tworzenia serwerów z włączoną wysoką dostępnością. Ta funkcja została zaprojektowana w celu znacznego zmniejszenia przestojów konserwacji, dzięki czemu w większości przypadków oczekuje się, że przestój konserwacji będzie wynosić od 40 do 60 sekund. Ta funkcja jest kluczowa dla firm, które wymagają wysokiej dostępności i minimalnych przerw w działaniu bazy danych.

Dokładne oczekiwania dotyczące przestojów

  • Czas trwania przestoju: w większości przypadków przestój podczas konserwacji waha się od 10 do 30 sekund.
  • Dodatkowe zagadnienia: po wystąpieniu zdarzenia trybu failover istnieje nieodłączny okres czasu wygaśnięcia (TTL) DNS równy około 30 sekund. Ten okres nie jest bezpośrednio kontrolowany przez proces konserwacji, ale jest standardową częścią zachowania DNS. Z perspektywy klienta całkowity przestój podczas konserwacji może wynosić od 40 do 60 sekund.

Ograniczenia i wymagania wstępne

Aby osiągnąć optymalną wydajność obiecaną przez tę funkcję, należy zauważyć pewne warunki i ograniczenia:

  • Klucze podstawowe we wszystkich tabelach: zapewnienie, że każda tabela ma klucz podstawowy, ma kluczowe znaczenie. Brak kluczy podstawowych może znacznie zwiększyć opóźnienie replikacji, co wpływa na przestój.
  • Niskie obciążenie w czasie konserwacji: okresy konserwacji powinny pokrywać się z czasem niskiego obciążenia na serwerze, aby zapewnić, że przestój pozostaje minimalny. Zachęcamy do korzystania z niestandardowej funkcji okna obsługi do planowania konserwacji poza godzinami szczytu.

Zmiana harmonogramu konserwacji (publiczna wersja zapoznawcza)

Ważne

Funkcja zmiany harmonogramu konserwacji jest obecnie dostępna w wersji zapoznawczej. Podlega on ograniczeniom i ciągłemu rozwojowi. Cenimy Twoją opinię, aby pomóc ulepszyć tę funkcję. Należy pamiętać, że ta funkcja nie jest dostępna dla serwerów korzystających z jednostki SKU z możliwością rozszerzenia.

Funkcja zmiany harmonogramu konserwacji zapewnia większą kontrolę nad chronometrażem działań konserwacyjnych w wystąpieniu serwera elastycznego usługi Azure Database for MySQL. Po otrzymaniu powiadomienia o konserwacji można zmienić harmonogram na bardziej wygodny czas, niezależnie od tego, czy był to system, czy niestandardowy.

Zmienianie harmonogramów parametrów i powiadomień

Zmiana terminów nie jest ograniczona do stałych przedziałów czasu; zależy od najwcześniejszych i najnowszych dopuszczalnych czasów bieżącego cyklu konserwacji. Po ponownym harmonogramie zostanie wysłane powiadomienie w celu potwierdzenia zmian zgodnie ze standardowymi zasadami powiadomień.

Rozważania i ograniczenia

Podczas korzystania z tej funkcji należy pamiętać o następujących kwestiach:

  • Ograniczenia dotyczące zapotrzebowania: anulowana ponowna konserwacja może zostać anulowana z powodu dużej liczby działań konserwacyjnych występujących jednocześnie w tym samym regionie.
  • Okres blokady: Zmiana harmonogramu jest niedostępna 15 minut przed początkowym zaplanowanym czasem konserwacji w celu utrzymania niezawodności usługi.

Nie ma żadnych ograniczeń dotyczących tego, ile razy można zaplanować konserwację, o ile konserwacja nie została wprowadzona w stan "Przygotowanie", zawsze można ponownie zaplanować konserwację do innego czasu.

Uwaga

Zalecamy ścisłe monitorowanie powiadomień na etapie podglądu w celu dostosowania potencjalnych zmian.

Użyj tej funkcji, aby uniknąć zakłóceń podczas krytycznych operacji bazy danych. Zachęcamy do przesyłania opinii w miarę kontynuowania opracowywania tej funkcji.

Następne kroki