Udostępnij za pośrednictwem

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

  • Artykuł

DOTYCZY: Azure Database for MySQL — serwer elastyczny

Usługa Azure Database for MySQL — elastyczny serwer 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

Należy unikać wszystkich operacji serwera (modyfikacji, zmian konfiguracji, uruchamiania/zatrzymywania serwera) podczas konserwacji serwera elastycznego 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żna 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

Począwszy od 31 sierpnia 2024 r., usługa Azure Database for MySQL nie będzie już obsługiwać niestandardowych okien obsługi dla wystąpień jednostek SKU z możliwością rozszerzenia. Ta zmiana wynika z potrzeby uproszczenia procesów konserwacji, zapewnienia optymalnej wydajności i naszej analizy wskazującej, że liczba użytkowników korzystających z niestandardowych okien obsługi w jednostkach SKU z możliwością zwiększenia wydajności jest minimalna. Istniejące wystąpienia jednostek SKU z możliwością rozszerzenia z niestandardowymi konfiguracjami okna obsługi pozostaną nienaruszone; jednak użytkownicy nie będą mogli modyfikować tych niestandardowych ustawień okna obsługi.

W przypadku klientów wymagających niestandardowych okien obsługi zalecamy uaktualnienie do jednostek SKU ogólnego przeznaczenia lub Krytyczne dla działania firmy, aby nadal korzystać z tej funkcji.

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.

Harmonogram konserwacji

Funkcja zmiany harmonogramu konserwacji zapewnia większą kontrolę nad czasem 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, który zazwyczaj obejmuje od pierwszego do ostatniego dnia okna obsługi dla regionu. 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.
  • Ograniczenie harmonogramów, jeśli zbyt wiele serwerów w tym samym regionie jest zaplanowanych na konserwację w tym samym czasie, ponowne zaplanowanie żądań może zakończyć się niepowodzeniem. Jeśli tak się stanie, użytkownicy otrzymają powiadomienie o błędzie i zaleca się wybranie alternatywnego przedziału czasu. Pomyślnie zaplanowana konserwacja prawdopodobnie nie zostanie anulowana.

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.

Często zadawane pytania

.: Dlaczego niektóre z moich serwerów otrzymały powiadomienia o konserwacji, podczas gdy inne nie?

1: Czasy rozpoczęcia konserwacji różnią się w różnych regionach, więc serwery w różnych regionach mogą otrzymywać powiadomienia o konserwacji w różnym czasie.

.: Dlaczego niektóre serwery w tym samym regionie otrzymały powiadomienia o konserwacji, podczas gdy inne nie?

1: Może to być spowodowane tym, że serwery, które nie otrzymały powiadomień, zostały utworzone ostatnio, a system ustalił, że nie wymaga jeszcze konserwacji.

.: Czy mogę zrezygnować z zaplanowanej konserwacji?

1: Nie, rezygnacja z zaplanowanej konserwacji jest niedozwolona. Można jednak użyć funkcji zmiany harmonogramu konserwacji, aby dostosować czas lub włączyć funkcję wysokiej dostępności (HA), aby zminimalizować przestoje. Jako produkt bazy danych PaaS niezbędne jest przeprowadzenie terminowej konserwacji w celu zapewnienia bezpieczeństwa i niezawodności bazy danych.

Następne kroki