Koncepcje związane z wysoką dostępnością w usłudze Azure Database for MySQL — serwer elastyczny

DOTYCZY: Azure Database for MySQL — serwer elastyczny

Serwer elastyczny usługi Azure Database for MySQL umożliwia konfigurowanie wysokiej dostępności z automatycznym trybem failover. Rozwiązanie dotyczące wysokiej dostępności ma na celu zapewnienie, że zatwierdzone dane nigdy nie zostaną utracone z powodu awarii, a baza danych nie będzie pojedynczym punktem awarii w architekturze oprogramowania. Po skonfigurowaniu wysokiej dostępności serwer elastyczny automatycznie aprowizuje replikę rezerwową i zarządza nią. Opłaty są naliczane za aprowizowane zasoby obliczeniowe i magazyn zarówno dla repliki podstawowej, jak i pomocniczej. Istnieją dwa modele architektury wysokiej dostępności:

• Strefowo nadmiarowa wysoka dostępność. Ta opcja jest preferowana w przypadku pełnej izolacji i nadmiarowości infrastruktury w wielu strefach dostępności. Zapewnia najwyższy poziom dostępności, ale wymaga skonfigurowania nadmiarowości aplikacji w różnych strefach. Strefowo nadmiarowa wysoka dostępność jest preferowana, jeśli chcesz osiągnąć najwyższy poziom dostępności w przypadku awarii infrastruktury w strefie dostępności i gdy opóźnienie w strefie dostępności jest akceptowalne. Można ją włączyć tylko po utworzeniu serwera. Strefowo nadmiarowa wysoka dostępność jest dostępna w podzestawie regionów platformy Azure, w których region obsługuje wiele stref dostępności i strefowo nadmiarowe udziały plików Premium są dostępne.

• Wysoka dostępność w tej samej strefie. Ta opcja jest preferowana w przypadku nadmiarowości infrastruktury z mniejszym opóźnieniem sieci, ponieważ serwery podstawowe i rezerwowe będą znajdować się w tej samej strefie dostępności. Zapewnia wysoką dostępność bez konieczności konfigurowania nadmiarowości aplikacji w różnych strefach. Wysoka dostępność w tej samej strefie jest preferowana, gdy chcesz uzyskać najwyższy poziom dostępności w ramach pojedynczej strefy dostępności z najniższym opóźnieniem sieci. Wysoka dostępność w tej samej strefie jest dostępna we wszystkich regionach świadczenia usługi Azure, w których można używać elastycznego serwera usługi Azure Database for MySQL.

Architektura strefowo nadmiarowej wysokiej dostępności

Podczas wdrażania serwera ze strefowo nadmiarową wysoką dostępnością zostaną utworzone dwa serwery:

• Serwer podstawowy w jednej strefie dostępności.
• Serwer repliki rezerwowej, który ma taką samą konfigurację jak serwer podstawowy (warstwa obliczeniowa, rozmiar obliczeniowy, rozmiar magazynu i konfiguracja sieci) w innej strefie dostępności w tym samym regionie świadczenia usługi Azure.

Możesz wybrać strefę dostępności dla repliki podstawowej i rezerwowej. Umieszczenie rezerwowych serwerów bazy danych i aplikacji rezerwowych w tej samej strefie zmniejsza opóźnienie. Pozwala również lepiej przygotować się do sytuacji odzyskiwania po awarii i scenariuszy "stref w dół".

Pliki danych i dziennika są hostowane w magazynie strefowo nadmiarowym (ZRS). Serwer rezerwowy odczytuje i odtwarza pliki dziennika w sposób ciągły z konta magazynu serwera podstawowego, które jest chronione przez replikację na poziomie magazynu.

W przypadku przejścia w tryb failover:

• Replika rezerwowa jest aktywowana.
• Pliki dziennika binarnego serwera podstawowego nadal mają zastosowanie do serwera rezerwowego w celu przełączenia go w tryb online do ostatniej zatwierdzonej transakcji na serwerze podstawowym.

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 bieżący serwer repliki rezerwowej przejmuje rolę serwera podstawowego. System DNS jest aktualizowany tak, aby połączenia klienckie były kierowane do nowego podstawowego po ponownym połączeniu klienta. Tryb failover jest w pełni niewidoczny dla aplikacji klienckiej i nie wymaga żadnej akcji od Ciebie. Następnie rozwiązanie wysokiej dostępności przywraca stary serwer podstawowy, gdy to możliwe, i umieszcza go jako rezerwę.

Nazwa serwera bazy danych służy do łączenia aplikacji z serwerem podstawowym. Informacje o repliki rezerwowej nie są uwidocznione w celu uzyskania bezpośredniego dostępu. Zatwierdzenia i zapisy są potwierdzane po opróżnieniu plików dziennika w magazynach ZRS serwera podstawowego. Ze względu na technologię replikacji synchronizacji używaną w magazynie ZRS można oczekiwać 5–10 procent zwiększonego opóźnienia dla zapisów i zatwierdzeń aplikacji.

Automatyczne kopie zapasowe, zarówno migawki, jak i kopie zapasowe dzienników, są wykonywane w magazynie strefowo nadmiarowym z podstawowego serwera bazy danych.

Architektura wysokiej dostępności w tej samej strefie

Podczas wdrażania serwera z taką samą strefą wysokiej dostępności dwa serwery zostaną utworzone w tej samej strefie:

• Serwer podstawowy
• Serwer repliki rezerwowej, który ma taką samą konfigurację jak serwer podstawowy (warstwa obliczeniowa, rozmiar obliczeniowy, rozmiar magazynu i konfiguracja sieci)

Serwer rezerwowy oferuje nadmiarowość infrastruktury z oddzielną maszyną wirtualną (obliczenia). Ta nadmiarowość zmniejsza czas pracy w trybie failover i opóźnienie sieci między aplikacją a serwerem bazy danych z powodu kolokacji.

Pliki danych i dziennika są hostowane w magazynie lokalnie nadmiarowym (LRS). Serwer rezerwowy odczytuje i odtwarza pliki dziennika w sposób ciągły z konta magazynu serwera podstawowego, które jest chronione przez replikację na poziomie magazynu.

W przypadku przejścia w tryb failover:

• Replika rezerwowa jest aktywowana.
• Pliki dziennika binarnego serwera podstawowego nadal mają zastosowanie do serwera rezerwowego w celu przełączenia go w tryb online do ostatniej zatwierdzonej transakcji na serwerze podstawowym.

Dzienniki w magazynach LRS 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 bieżąca replika rezerwowa przyjmuje rolę serwera podstawowego. System DNS jest aktualizowany w celu przekierowania połączeń do nowego serwera podstawowego podczas ponownego nawiązywania połączenia przez klienta. Tryb failover jest w pełni niewidoczny dla aplikacji klienckiej i nie wymaga żadnej akcji od Ciebie. Następnie rozwiązanie wysokiej dostępności przywraca stary serwer podstawowy, gdy to możliwe, i umieszcza go jako rezerwę.

Nazwa serwera bazy danych służy do łączenia aplikacji z serwerem podstawowym. Informacje o repliki rezerwowej nie są uwidocznione w celu uzyskania bezpośredniego dostępu. Zatwierdzenia i zapisy są potwierdzane po opróżnieniu plików dziennika w magazynach LRS serwera podstawowego. Ponieważ replika podstawowa i rezerwowa znajdują się w tej samej strefie, opóźnienie replikacji jest mniejsze i mniejsze opóźnienie między serwerem aplikacji a serwerem bazy danych. Konfiguracja tej samej strefy nie zapewnia wysokiej dostępności, gdy zależne infrastruktury są wyłączone dla określonej strefy dostępności. Nastąpi przestój do czasu powrotu wszystkich usług zależnych do trybu online dla tej strefy dostępności.

Automatyczne kopie zapasowe, zarówno migawki, jak i kopie zapasowe dzienników, są wykonywane w magazynie lokalnie nadmiarowym z podstawowego serwera bazy danych.

Uwaga

W przypadku strefowo nadmiarowej i tej samej strefy wysoka dostępność:

• Jeśli wystąpi awaria, czas potrzebny repliki rezerwowej do przejęcia roli podstawowej zależy od czasu potrzebnego do odtworzenia dziennika binarnego z konta magazynu podstawowego do rezerwowego. Dlatego zalecamy używanie kluczy podstawowych we wszystkich tabelach w celu skrócenia czasu pracy w trybie failover. Czasy pracy w trybie failover zwykle trwają od 60 do 120 sekund.
• Serwer rezerwowy nie jest dostępny dla operacji odczytu ani zapisu. Jest to pasywna rezerwa umożliwiająca szybkie przejście w tryb failover.
• Zawsze używaj w pełni kwalifikowanej nazwy domeny (FQDN), aby nawiązać połączenie z serwerem podstawowym. Unikaj używania adresu IP do nawiązania połączenia. Jeśli nastąpi przełączenie w tryb failover, po przełączeniu ról serwera podstawowego i rezerwowego rekord DNS A może ulec zmianie. Ta zmiana uniemożliwiłaby aplikacji nawiązanie połączenia z nowym serwerem podstawowym, jeśli w parametry połączenia jest używany adres IP.

Proces trybu failover

Zaplanowane: wymuszone przejście w tryb failover

Usługa Azure Database for MySQL — serwer elastyczny zmuszony do trybu failover umożliwia ręczne wymuszenie przejścia w tryb failover. Ta funkcja umożliwia przetestowanie funkcjonalności za pomocą scenariuszy aplikacji i ułatwia przygotowanie do awarii.

Wymuszone przejście w tryb failover wyzwala przejście w tryb failover, który aktywuje replikę rezerwową, aby stała się serwerem podstawowym z taką samą nazwą serwera baz danych, przez zaktualizowanie rekordu DNS. Oryginalny serwer podstawowy jest uruchamiany ponownie i przełączany do repliki rezerwowej. Połączenia klientów są rozłączane i należy je nawiązać ponownie, aby wznowić ich działanie.

Ogólny czas przejścia w tryb failover zależy od bieżącego obciążenia i ostatniego punktu kontrolnego. Na ogół powinno to zająć 60–120 sekund.

Uwaga

Zdarzenie usługi Azure Resource Health jest generowane w przypadku planowanego przejścia w tryb failover reprezentującego czas pracy w trybie failover, w którym serwer był niedostępny. Wyzwalane zdarzenia można zobaczyć po kliknięciu pozycji "Resource Health" w okienku po lewej stronie. Zainicjowane przez użytkownika/ręczne przejście w tryb failover jest reprezentowane przez stan "Niedostępny" i oznaczone jako "Planowane". Przykład : "Operacja przejścia w tryb failover została wyzwolona przez autoryzowanego użytkownika (Planned)". Jeśli zasób pozostaje w tym stanie przez dłuższy czas, otwórz bilet pomocy technicznej i pomożemy Ci.

Niezaplanowane: automatyczne przejście w tryb failover

Nieplanowany przestój usługi może być spowodowany usterkami oprogramowania lub błędami infrastruktury, takimi jak błędy obliczeniowe, sieciowe lub awarie magazynu albo awarie zasilania wpływające na dostępność bazy danych. Jeśli baza danych stanie się niedostępna, replikacja do repliki rezerwowej zostanie przerwana, a replika rezerwowa zostanie aktywowana jako podstawowa baza danych. System DNS jest aktualizowany, a klienci ponownie łączą się z serwerem bazy danych i wznawiają operacje.

Łączny czas przejścia w tryb failover powinien wynosić 60–120 sekund. Jednak w zależności od działania na podstawowym serwerze bazy danych w momencie przejścia w tryb failover (na przykład dużych transakcji i czasu odzyskiwania) przejście w tryb failover może trwać dłużej.

Uwaga

Zdarzenie usługi Azure Resource Health jest generowane w przypadku nieplanowanego trybu failover reprezentującego czas pracy w trybie failover, w którym serwer był niedostępny. Wyzwalane zdarzenia można zobaczyć po kliknięciu pozycji "Resource Health" w okienku po lewej stronie. Automatyczne przełączanie w tryb failover jest reprezentowane przez stan jako "Niedostępne" i oznaczone jako "Nieplanowane". Przykład : "Niedostępna: operacja przejścia w tryb failover została wyzwolona automatycznie (nieplanowana)". Jeśli zasób pozostaje w tym stanie przez dłuższy czas, otwórz bilet pomocy technicznej i pomożemy Ci.

Jak działa automatyczne wykrywanie trybu failover na serwerach z włączoną wysoką dostępnością

Serwer podstawowy i serwer pomocniczy mają dwa punkty końcowe sieci,

• Punkt końcowy klienta: Klient łączy się i uruchamia zapytanie dotyczące wystąpienia przy użyciu tego punktu końcowego.
• Punkt końcowy zarządzania: używany wewnętrznie do komunikacji między usługami a składnikami zarządzania i nawiązywania połączenia z magazynem zaplecza.

Składnik monitora kondycji stale przeprowadza następujące kontrole

• Monitor wysyła polecenia ping do węzłów Punkt końcowy sieci zarządzania. Jeśli to sprawdzenie zakończy się niepowodzeniem dwa razy w sposób ciągły, wyzwala automatyczną operację trybu failover. Scenariusz, taki jak węzeł jest niedostępny/nie odpowiada z powodu problemu z systemem operacyjnym, problem z siecią między składnikami zarządzania i węzłami itp. zostanie rozwiązany przez tę kontrolę kondycji.
• Monitor uruchamia również proste zapytanie w wystąpieniu. Jeśli nie można uruchomić zapytań, zostanie wyzwolony automatyczny tryb failover. Scenariusze takie jak Demon MySQL uległy awarii/ zatrzymaniu/zawieszaniu się, problem z magazynem zaplecza itp., zostaną rozwiązane przez tę kontrolę kondycji.

Uwaga

Jeśli występuje problem z siecią między aplikacją a punktem końcowym sieci klienta (dostęp prywatny/publiczny), w ścieżce sieciowej , w punkcie końcowym lub problemach z systemem DNS po stronie klienta, kontrola kondycji nie monitoruje tego scenariusza. Jeśli używasz dostępu prywatnego, upewnij się, że reguły sieciowej grupy zabezpieczeń dla sieci wirtualnej nie blokują komunikacji z punktem końcowym sieci klienta wystąpienia na porcie 3306. W przypadku dostępu publicznego upewnij się, że reguły zapory są ustawione, a ruch sieciowy jest dozwolony na porcie 3306 (jeśli ścieżka sieciowa ma inne zapory). Rozpoznawanie nazw DNS po stronie aplikacji klienckiej należy również dbać.

Monitorowanie pod kątem wysokiej dostępności

Stan wysokiej dostępności znajdujący się w okienku wysokiej dostępności serwera w portalu może służyć do określenia stanu konfiguracji wysokiej dostępności serwera.

Stan	Opis
NotEnabled	Wysoka dostępność nie jest włączona.
Replikowanie danych	Serwer rezerwowy jest w trakcie synchronizacji z serwerem podstawowym w momencie aprowizacji serwera wysokiej dostępności lub po włączeniu opcji wysokiej dostępności.
Tryb failover	Serwer bazy danych jest w trakcie przechodzenia w tryb failover z serwera podstawowego do rezerwowego.
Zdrowe	Opcja wysokiej dostępności jest włączona.
Usuwaniestandby	Gdy opcja wysokiej dostępności jest wyłączona, a proces usuwania jest w toku.

Poniższe metryki umożliwiają również monitorowanie kondycji serwera wysokiej dostępności.

Nazwa wyświetlana metryki	Metric	Jednostka	opis
Stan operacji we/wy wysokiej dostępności	ha_io_running	Stan	Stan we/wy wysokiej dostępności wskazuje stan replikacji wysokiej dostępności. Wartość metryki to 1, jeśli wątek we/wy jest uruchomiony i 0, jeśli nie.
Stan ha SQL	ha_sql_running	Stan	Stan ha SQL wskazuje stan replikacji wysokiej dostępności. Wartość metryki to 1, jeśli wątek SQL jest uruchomiony i 0, jeśli nie.
Opóźnienie replikacji wysokiej dostępności	replication_lag	Sekundy	Opóźnienie replikacji to liczba sekund, przez które rezerwa znajduje się w przypadku ponownego odtworzenia transakcji odebranych na serwerze podstawowym.

Ograniczenia

Poniżej przedstawiono kilka kwestii, które należy wziąć pod uwagę podczas korzystania z wysokiej dostępności:

• Wysoką dostępność strefowo nadmiarową można ustawić tylko po utworzeniu serwera elastycznego.
• Wysoka dostępność nie jest obsługiwana w warstwie obliczeniowej z możliwością rozszerzenia.
• Ponowne uruchomienie podstawowego serwera bazy danych w celu pobrania zmian parametrów stat.ycznych powoduje również ponowne uruchomienie repliki rezerwowej.
• Tryb GTID zostanie włączony, ponieważ rozwiązanie wysokiej dostępności używa identyfikatora GTID. Sprawdź, czy obciążenie ma ograniczenia lub ograniczenia dotyczące replikacji przy użyciu identyfikatorów GTID.

Uwaga

Jeśli włączasz tę samą strefę wysokiej dostępności po utworzeniu serwera, przed włączeniem wysokiej dostępności upewnij się, że parametry serwera enforce_gtid_consistency" i "gtid_mode" jest ustawiona na WŁĄCZONE.

Uwaga

Automatyczne dodawanie magazynu jest domyślnie włączone dla skonfigurowanego serwera o wysokiej dostępności i nie można go wyłączyć.

Często zadawane pytania

• Jakie są umowy SLA dla serwera elastycznego z obsługą wysokiej dostępności w tej samej strefie i strefowo nadmiarowej dostępności?

  Informacje o umowie SLA dla serwera elastycznego usługi Azure Database for MySQL można znaleźć w umowie 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 być strefowo nadmiarowa. Opłaty są naliczane za aprowizowane zasoby obliczeniowe i magazyn zarówno dla repliki podstawowej, jak i pomocniczej. Jeśli na przykład masz replikę podstawową z 4 rdzeniami wirtualnymi i 512 GB aprowidowanego magazynu, replika pomocnicza będzie mieć także 4 rdzenie wirtualne i 512 GB aprowidowanego magazynu. Opłata za strefowo nadmiarowy serwer o wysokiej dostępności zostanie obliczona dla 8 rdzeni wirtualnych i 1024 GB magazynu. W zależności od rozmiaru magazynu kopii zapasowych może także zostać naliczona opłata 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?
  Tryby failover są w pełni niewidoczne dla aplikacji klienckiej. 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 wybrana losowo. Będzie on 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 rezerwą jest podobna do trybu semisynchronicznego w programie MySQL. Gdy transakcja zostanie zatwierdzona, nie musi być zatwierdzana w rezerwie. Ale gdy podstawowy jest niedostępny, rezerwa replikuje wszystkie zmiany danych z podstawowego, aby upewnić się, że nie ma utraty danych.
  

• Czy istnieje przejście w tryb failover do repliki rezerwowej dla wszystkich nieplanowanych awarii?
  Jeśli wystąpi awaria bazy danych lub węzeł, maszyna wirtualna serwera elastycznego zostanie ponownie uruchomiona w 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 pracy w trybie failover, operacja trybu failover 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 występuje wpływ na wydajność w przypadku korzystania z wysokiej dostępności?
  W przypadku strefowo nadmiarowej wysokiej dostępności, chociaż nie ma dużego wpływu na wydajność obciążeń odczytu w różnych strefach dostępności, może wystąpić nawet 40-procentowy spadek opóźnienia zapytań zapisu. Wzrost opóźnienia zapisu wynika z synchronicznej replikacji w strefie dostępności. Wpływ opóźnienia zapisu jest zwykle dwa razy w strefowo nadmiarowej wysokiej dostępności w porównaniu do tej samej strefy wysokiej dostępności. W przypadku wysokiej dostępności w tej samej strefie, ponieważ replika podstawowa i rezerwowa znajduje się w tej samej strefie, opóźnienie replikacji i w związku z tym synchroniczne opóźnienie zapisu jest niższe. Podsumowując, jeśli opóźnienie zapisu jest bardziej krytyczne w porównaniu z dostępnością, możesz wybrać wysoką dostępność w tej samej strefie, ale jeśli dostępność i odporność danych jest bardziej krytyczna dla Ciebie kosztem spadku opóźnienia zapisu, musisz wybrać strefowo nadmiarową wysoką dostępność. Aby zmierzyć dokładny wpływ spadku opóźnienia konfiguracji wysokiej dostępności, zalecamy przeprowadzenie testów wydajnościowych dla obciążenia w celu podjęcia świadomej decyzji.
  

• Jak się dzieje konserwacja serwera wysokiej dostępności?
  Planowane zdarzenia, takie jak skalowanie uaktualnień zasobów obliczeniowych i wersji pomocniczych, są wykonywane najpierw w oryginalnym wystąpieniu rezerwowym, a następnie wyzwalane są planowane operacje pracy w trybie failover, a następnie działają na oryginalnym wystąpieniu podstawowym. W przypadku serwerów elastycznych można ustawić zaplanowane okno obsługi dla serwerów wysokiej dostępności. Czas przestoju będzie taki sam jak przestój wystąpienia serwera elastycznego 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żesz zrobić 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, które ma wyłączoną wysoką dostępność. Jeśli serwer źródłowy został utworzony z strefowo nadmiarową wysoką dostępnością, możesz włączyć strefowo nadmiarową wysoką dostępność lub wysoką dostępność w tej samej strefie na przywróconym serwerze później. Jeśli serwer źródłowy został utworzony z wysoką dostępnością tej samej strefy, można włączyć tylko tę samą strefę wysokiej dostępności na przywróconym serwerze.
  

• Czy mogę włączyć wysoką dostępność na serwerze po utworzeniu serwera?
  Po utworzeniu serwera należy włączyć strefowo nadmiarową wysoką dostępność. Po utworzeniu serwera można włączyć wysoką dostępność tej samej strefy. Przed włączeniem tej samej strefy wysokiej dostępności upewnij się, że parametry serwera enforce_gtid_consistency" i "gtid_mode" są ustawione na WŁĄCZONE
  

• Czy mogę wyłączyć wysoką dostępność serwera po jego utworzeniu?
  Po jego utworzeniu można wyłączyć wysoką dostępność 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 do odczytu dla serwera z włączoną wysoką dostępnością?
  Tak, repliki do odczytu są obsługiwane dla serwerów wysokiej dostępności.
  

• Czy mogę używać replikacji typu data-in 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 za pośrednictwem replikacji opartej na gtID. Procedura składowana replikacji przy użyciu identyfikatora GTID jest dostępna na wszystkich serwerach z włączoną wysoką dostępnością według nazwy mysql.az_replication_with_gtid.

• Czy można zmniejszyć przestój, czy mogę przejść w tryb failover na serwer rezerwowy podczas ponownego uruchamiania serwera, czy podczas skalowania w górę lub w dół?
  Obecnie serwer elastyczny usługi Azure Database for MySQL utlizował planowane przejście w tryb failover, aby zdecydować na operacje wysokiej dostępności, w tym skalowanie w górę/w dół, i planowaną konserwację, aby zmniejszyć czas przestoju. Po rozpoczęciu takich operacji najpierw będzie działać na oryginalnym wystąpieniu rezerwowym, a następnie wyzwoleniu planowanej operacji trybu failover, a następnie operacji na oryginalnym wystąpieniu podstawowym.
  

• Czy możemy zmienić tryb dostępności (strefowo nadmiarowa wysoka dostępność/ta sama strefa) serwera
  Jeśli utworzysz serwer z włączonym trybem strefowo nadmiarowej wysokiej dostępności, możesz zmienić strefowo nadmiarową wysoką dostępność na tę samą strefę i na odwrót. 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ć ją z powrotem na Strefowo nadmiarową lub tę samą strefę i wybrać tryb wysokiej dostępności.
  

Następne kroki

• Dowiedz się więcej o ciągłości działalności biznesowej.
• Dowiedz się więcej o wysokiej dostępności strefowo nadmiarowej.
• Dowiedz się więcej o tworzeniu kopii zapasowych i odzyskiwaniu.