Udostępnij za pośrednictwem

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.

Cykl konserwacji

Rutynowa konserwacja

Nasz standardowy cykl konserwacji jest zaplanowany nie rzadziej niż co 30 dni. Ten okres pozwala nam zapewnić stabilność i wydajność systemu przy jednoczesnym zminimalizowaniu zakłóceń w Twoich usługach.

Konserwacja krytyczna

W niektórych scenariuszach, takich jak konieczność wdrożenia pilnych poprawek zabezpieczeń lub aktualizacji krytycznych dla utrzymania dostępności i integralności danych, konserwacja może być przeprowadzana częściej. Te wyjątki są tworzone w celu ochrony danych i zapewnienia ciągłej obsługi usług.

Lokalizowanie szczegółów konserwacji

Aby uzyskać szczegółowe informacje o tym, co obejmuje każda aktualizacja konserwacji, zapoznaj się z naszymi informacjami o wersji. Te uwagi zawierają kompleksowe informacje o aktualizacjach stosowanych podczas konserwacji, co pozwala zrozumieć i przygotować się do wszelkich zmian wpływających na środowisko.

Uwaga

Nie wszystkie serwery muszą przejść konserwację podczas zaplanowanych aktualizacji, zarówno rutynowych, jak i krytycznych. Zespół usługi Azure MySQL stosuje określone kryteria w celu określenia, które serwery wymagają konserwacji. Takie podejście selektywne gwarantuje, że konserwacja jest zarówno wydajna, jak i niezbędna, dostosowana do unikatowych potrzeb każdego środowiska serwera i minimalizuje przestoje środowiska produkcyjnego.

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.

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.
  • Gwarancje przestojów: Chociaż staramy się utrzymać czas przestoju konserwacji tak niskie, jak to możliwe, nie gwarantujemy, że zawsze będzie to mniej niż 60 sekund we wszystkich okolicznościach. Różne czynniki, takie jak wysokie obciążenie lub określone konfiguracje serwera, mogą prowadzić do dłuższego przestoju. W najgorszym scenariuszu przestój może być podobny do tego z serwera autonomicznego.

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