Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Wysoka dostępność to kluczowa funkcja usługi Azure Database for MySQL zaprojektowana w celu zminimalizowania przestojów i zapewnienia dostępności aplikacji nawet podczas planowanej konserwacji lub nieoczekiwanych awarii. Ten artykuł zawiera odpowiedzi na często zadawane pytania dotyczące opcji wysokiej dostępności, rozliczeń, procesów trybu failover, wpływu na wydajność i najlepszych rozwiązań, które ułatwiają podejmowanie świadomych decyzji dotyczących obciążeń MySQL na platformie Azure.
Jakie są umowy o gwarantowanym poziomie usług (SLA) dla elastycznych serwerów z wysoką dostępnością, mających lokalną nadmiarowość w porównaniu z strefową nadmiarowością?
Informacje na temat umowy SLA dla usługi Azure Database for MySQL - serwer elastyczny można znaleźć w sekcji SLA dla usługi Azure Database for MySQL.
Jak są naliczane opłaty za serwery o wysokiej dostępności?
Serwery z włączoną wysoką dostępnością mają replikę podstawową i pomocniczą. Replika pomocnicza może znajdować się w tej samej strefie lub strefie nadmiarowej. Pobierane są opłaty za przydzielone zasoby obliczeniowe i przechowywanie, zarówno w przypadku repliki podstawowej, jak i pomocniczej. Jeśli na przykład masz podstawowy system z 4 vCore jednostkami obliczeniowymi i 512 GB zarezerwowanej pamięci masowej, replika pomocnicza ma 4 vCore jednostki obliczeniowe i 512 GB zarezerwowanej pamięci masowej.
Opłaty za strefowo nadmiarowy serwer wysokiej dostępności są naliczane za 8 rdzeni wirtualnych i 1024 GB miejsca do magazynowania. W zależności od woluminu magazynu kopii zapasowych mogą być również naliczane opłaty za magazyn kopii zapasowych.
Czy mogę użyć repliki rezerwowej na potrzeby operacji odczytu lub zapisu?
Serwer rezerwowy nie jest dostępny dla operacji odczytu ani zapisu. Jest to pasywna rezerwa umożliwiająca szybkie przejście w tryb failover.
Czy po przejściu w tryb failover nastąpi utrata danych?
Dzienniki w magazynach ZRS są dostępne nawet wtedy, gdy serwer podstawowy jest niedostępny. Ta dostępność pomaga zapewnić brak utraty danych. Po aktywowaniu repliki rezerwowej i zastosowaniu dzienników binarnych przyjmuje rolę serwera podstawowego.
Czy muszę wykonać jakiekolwiek działania po przejściu w tryb failover?
Przełączenia awaryjne są w pełni przezroczyste dla aplikacji klienta. Nie musisz podejmować żadnych działań. Aplikacje powinny po prostu używać logiki ponawiania dla swoich połączeń.
Co się stanie, gdy nie wybieram określonej strefy dla repliki rezerwowej? Czy mogę później zmienić strefę?
Jeśli nie wybierzesz strefy, zostanie ona losowo wybrana. Jest to ten, który jest używany dla serwera podstawowego. Aby zmienić strefę później, możesz ustawić opcję Wysoka dostępność na Wyłączone w okienku Wysoka dostępność , a następnie ustawić ją z powrotem na Strefowo nadmiarową i wybrać strefę.
Czy replikacja między replikami podstawowymi i rezerwowymi jest synchroniczna?
Replikacja między serwerem podstawowym a serwerem zapasowym jest podobna do trybu semisynchronicznego w programie MySQL. Gdy transakcja zostanie zatwierdzona, nie musi być zatwierdzana na serwerze zapasowym. Ale gdy główny jest niedostępny, zapasowy przenosi wszystkie zmiany danych z głównego, aby upewnić się, że nie ma żadnej utraty danych.
Czy istnieje przełączenie awaryjne do repliki rezerwowej w przypadku wszystkich nieplanowanych awarii?
Jeśli nastąpi awaria bazy danych lub awaria węzła, maszyna wirtualna serwera elastycznego zostanie uruchomiona ponownie na tym samym węźle. Jednocześnie jest wyzwalany automatyczny tryb failover. Jeśli ponowne uruchomienie maszyny wirtualnej serwera elastycznego zakończy się pomyślnie przed zakończeniem przełączenia awaryjnego, operacja przełączenia awaryjnego zostanie anulowana. Określenie serwera, który ma być używany jako replika podstawowa, zależy od procesu, który zakończy się najpierw.
Czy korzystanie z wysokiej dostępności wpływa na wydajność?
W przypadku wysokiej dostępności z redundancją strefową, chociaż nie ma dużego wpływu na wydajność obciążeń odczytu między strefami dostępności, może nastąpić nawet 40-procentowy wzrost opóźnienia zapytań zapisu. Wzrost opóźnienia zapisu wynika z synchronicznej replikacji w strefie dostępności. Wpływ opóźnienia zapisu jest dwukrotnie większy w nadmiarowej dostępności strefowej w porównaniu do dostępności w tej samej strefie. W przypadku lokalnie nadmiarowej wysokiej dostępności, ponieważ replika podstawowa i replika rezerwowa znajdują się w tej samej strefie, opóźnienie replikacji, a przez to synchroniczne opóźnienie zapisu, jest niższe.
Podsumowując, jeśli dla ciebie opóźnienie zapisu jest ważniejsze niż dostępność, możesz wybrać lokalnie nadmiarową wysoką dostępność. Jednak jeśli dostępność i odporność danych są dla ciebie ważniejsze kosztem zwiększonego opóźnienia zapisu, powinieneś wybrać strefowo nadmiarową wysoką dostępność. Aby zmierzyć dokładny wpływ spadku opóźnienia w konfiguracji wysokiej dostępności, zalecamy przeprowadzenie testowania wydajności obciążenia w celu podjęcia świadomej decyzji.
Jak się dzieje konserwacja serwera wysokiej dostępności?
Planowane zdarzenia, takie jak skalowanie zasobów obliczeniowych i uaktualnienia do mniejszych wersji, są wykonywane najpierw na oryginalnym wystąpieniu rezerwowym, po czym zostaje przeprowadzona planowana operacja failover, a następnie działania są kontynuowane na oryginalnym wystąpieniu podstawowym. Można ustawić zaplanowane okno obsługi dla serwerów wysokiej dostępności tak samo, jak dla serwerów elastycznych. Czas przestoju jest taki sam jak czas przestoju elastycznego serwera usługi Azure Database for MySQL, gdy wysoka dostępność jest wyłączona.
Czy mogę wykonać przywracanie do punktu w czasie (PITR) serwera wysokiej dostępności?
Można wykonać PITR dla wystąpienia serwera elastycznego usługi Azure Database for MySQL z obsługą wysokiej dostępności do nowego wystąpienia serwera elastycznego usługi Azure Database for MySQL z wyłączoną wysoką dostępnością. Jeśli serwer źródłowy został utworzony z użyciem wysokiej dostępności z redundancją strefową, można później włączyć wysoką dostępność z redundancją strefową lub wysoką dostępność z redundancją lokalną na przywróconym serwerze. Jeśli serwer źródłowy został utworzony z lokalnie nadmiarową wysoką dostępnością, można włączyć tylko lokalnie nadmiarową wysoką dostępność na przywróconym serwerze.
Czy mogę włączyć wysoką dostępność na serwerze po utworzeniu serwera?
Podczas tworzenia serwera należy włączyć strefowo nadmiarową wysoką dostępność. Po utworzeniu serwera można włączyć lokalnie nadmiarową HA, ale przed kontynuowaniem upewnij się, że parametry serwera enforce_gtid_consistency i gtid_mode są ustawione na ON.
Czy mogę wyłączyć wysoką dostępność serwera po jego utworzeniu?
Po jego utworzeniu można wyłączyć HA na serwerze. Rozliczenia są natychmiast zatrzymywane.
Jak można ograniczyć przestoje?
Musisz mieć możliwość ograniczenia przestoju aplikacji nawet wtedy, gdy nie używasz wysokiej dostępności. Przestoje usługi, takie jak zaplanowane poprawki, uaktualnienia wersji pomocniczej lub operacje inicjowane przez klienta, takie jak skalowanie zasobów obliczeniowych, można wykonać podczas zaplanowanych okien obsługi. Aby ograniczyć wpływ aplikacji na zadania konserwacji inicjowane przez platformę Azure, możesz zaplanować je w dniu tygodnia i o czasie, który minimalizuje wpływ na aplikację.
Czy mogę użyć repliki odczytowej dla serwera z włączoną funkcją wysokiej dostępności?
Tak, repliki do odczytu są obsługiwane dla serwerów wysokiej dostępności.
Czy mogę używać Data-in Replication dla serwerów wysokiej dostępności?
Obsługa replikacji typu data-in dla serwera z włączoną wysoką dostępnością jest dostępna tylko poprzez replikację opartą na GTID.
Procedura składowana do replikacji przy użyciu identyfikatora GTID jest dostępna na wszystkich serwerach z włączoną wysoką dostępnością pod nazwą mysql.az_replication_with_gtid.
Czy w celu zmniejszenia przestoju mogę przejść w tryb failover na serwer rezerwowy podczas ponownego uruchamiania serwera lub w trakcie skalowania w górę lub w dół?
Obecnie usługa Azure Database for MySQL — Elastyczny Serwer wykorzystała planowane przełączenie awaryjne w celu optymalizacji operacji wysokiej dostępności, w tym skalowanie w górę lub w dół oraz planowaną konserwację, aby zmniejszyć przestoje.
Po rozpoczęciu takich operacji najpierw będzie obsługiwać oryginalne wystąpienie rezerwowe, następnie wyzwoli planowaną operację przełączenia awaryjnego, a potem będzie obsługiwać oryginalne wystąpienie podstawowe.
Czy można zmienić tryb dostępności (strefowo nadmiarowy/lokalnie nadmiarowy) serwera**
Jeśli utworzysz serwer z włączonym trybem strefowo nadmiarowej wysokiej dostępności, możesz zmienić strefowo nadmiarową wysoką dostępność na lokalnie nadmiarową i odwrotnie.
Aby zmienić tryb dostępności, możesz ustawić opcję Wysoka dostępność na Wyłączone w okienku Wysoka dostępność , a następnie ustawić go z powrotem na strefowo nadmiarowy lub lokalnie nadmiarowy i wybrać tryb wysokiej dostępności.