Repliki do odczytu w usłudze Azure Database for MySQL

  • Artykuł

DOTYCZY: Azure Database for MySQL — pojedynczy serwer

Ważne

Pojedynczy serwer usługi Azure Database for MySQL znajduje się na ścieżce wycofania. Zdecydowanie zalecamy uaktualnienie do serwera elastycznego usługi Azure Database for MySQL. Aby uzyskać więcej informacji na temat migracji do serwera elastycznego usługi Azure Database for MySQL, zobacz Co się dzieje z usługą Azure Database for MySQL — pojedynczy serwer?

Funkcja repliki do odczytu umożliwia replikowanie danych z serwera usługi Azure Database for MySQL do serwera tylko do odczytu. Z serwera źródłowego można replikować maksymalnie pięć replik. Repliki są aktualizowane asynchronicznie przy użyciu natywnej technologii replikacji aparatu programu MySQL opartej na pozycji w pliku dziennika binarnego (binlog). Aby dowiedzieć się więcej na temat replikacji binlog, zobacz Omówienie replikacji dziennika binlogu MySQL.

Repliki to nowe serwery, którymi zarządzasz podobnie jak zwykłe serwery usługi Azure Database for MySQL. Dla każdej repliki do odczytu opłaty są naliczane za aprowizowane zasoby obliczeniowe w rdzeniach wirtualnych i magazynie w GB/miesiąc.

Aby dowiedzieć się więcej na temat funkcji replikacji mySQL i problemów, zobacz dokumentację replikacji mySQL.

Uwaga

Ten artykuł zawiera odwołania do terminu slave (element podrzędny), który nie jest już używany przez firmę Microsoft. Po usunięciu terminu z oprogramowania usuniemy go z tego artykułu.

Kiedy używać repliki do odczytu

Funkcja repliki do odczytu ułatwia poprawę wydajności i skalowania obciążeń intensywnie korzystających z odczytu. Obciążenia odczytu można izolować do replik, podczas gdy obciążenia zapisu mogą być kierowane do źródła.

W typowym scenariuszu obciążenia analizy biznesowej i analizy używają replik do odczytu jako źródła danych do raportowania.

Ponieważ repliki są tylko do odczytu, nie zmniejszają bezpośrednio obciążeń związanych z zapisem w źródle. Ta funkcja nie jest przeznaczona dla obciążeń intensywnie korzystających z zapisu.

Funkcja repliki do odczytu używa replikacji asynchronicznej mySQL. Ta funkcja nie jest przeznaczona dla scenariuszy replikacji synchronicznej. Między źródłem a repliką wystąpi wymierne opóźnienie. Dane repliki ostatecznie staną się spójne z danymi w źródle. Użyj tej funkcji w przypadku obciążeń, które mogą uwzględnić to opóźnienie.

Replikacja między regionami

Replikę do odczytu można utworzyć w innym regionie niż serwer źródłowy. Replikacja między regionami może być przydatna w scenariuszach, takich jak planowanie odzyskiwania po awarii lub przybliżanie danych do użytkowników.

Serwer źródłowy można mieć w dowolnym regionie usługi Azure Database for MySQL. Serwer źródłowy może mieć replikę w sparowanym regionie lub w regionach repliki uniwersalnej. Na poniższej ilustracji przedstawiono, które regiony repliki są dostępne w zależności od regionu źródłowego.

Regiony repliki uniwersalnej

Replikę do odczytu można utworzyć w dowolnym z następujących regionów, niezależnie od tego, gdzie znajduje się serwer źródłowy. Obsługiwane regiony repliki uniwersalnej obejmują:

Region (Region) Dostępność repliki
Australia Wschodnia ✔️
Australia Południowo-Wschodnia ✔️
Brazylia Południowa ✔️
Kanada Środkowa ✔️
Kanada Wschodnia ✔️
Środkowe stany USA ✔️
Wschodnie stany USA ✔️
Wschodnie stany USA 2 ✔️
Azja Wschodnia ✔️
Japonia Wschodnia ✔️
Japonia Zachodnia ✔️
Korea Środkowa ✔️
Korea Południowa ✔️
Europa Północna ✔️
Północno-środkowe stany USA ✔️
South Central US ✔️
Azja Południowo-Wschodnia ✔️
Szwajcaria Północna ✔️
Południowe Zjednoczone Królestwo ✔️
Zachodnie Zjednoczone Królestwo ✔️
Zachodnio-środkowe stany USA ✔️
Zachodnie stany USA ✔️
Zachodnie stany USA 2 ✔️
Europa Zachodnia ✔️
Indie Środkowe* ✔️
Francja Środkowa* ✔️
Zjednoczone Emiraty Arabskie* ✔️
Republika Południowej Afryki Północnej* ✔️

Uwaga

*Regiony, w których usługa Azure Database for MySQL ma magazyn ogólnego przeznaczenia w wersji 2 w publicznej wersji zapoznawczej
*W przypadku tych regionów platformy Azure będziesz mieć możliwość utworzenia serwera w magazynie ogólnego przeznaczenia w wersji 1 i 2. W przypadku serwerów utworzonych za pomocą magazynu ogólnego przeznaczenia w wersji 2 w publicznej wersji zapoznawczej można tworzyć serwer repliki tylko w regionach świadczenia usługi Azure, które obsługują magazyn ogólnego przeznaczenia w wersji 2.

Sparowane regiony

Oprócz regionów repliki uniwersalnej można utworzyć replikę do odczytu w sparowanym regionie platformy Azure serwera źródłowego. Jeśli nie znasz pary regionów, możesz dowiedzieć się więcej z artykułu Regiony sparowane platformy Azure.

Jeśli używasz replik między regionami do planowania odzyskiwania po awarii, zalecamy utworzenie repliki w sparowanym regionie zamiast jednego z pozostałych regionów. Sparowane regiony unikają równoczesnych aktualizacji i określania priorytetów izolacji fizycznej i rezydencji danych.

Istnieją jednak ograniczenia, które należy wziąć pod uwagę:

  • Dostępność regionalna: usługa Azure Database for MySQL jest dostępna we Francji Środkowej, Północnej Emiratach Zjednoczonych i Niemczech Środkowych. Jednak ich sparowane regiony nie są dostępne.

  • Pary jednokierunkowe: niektóre regiony platformy Azure są sparowane tylko w jednym kierunku. Regiony te obejmują Indie Zachodnie, Brazylia Południowa i US Gov Wirginia. Oznacza to, że serwer źródłowy w Indiach Zachodnich może utworzyć replikę w Indiach Południowych. Jednak serwer źródłowy w Indiach Południowych nie może utworzyć repliki w Indiach Zachodnich. Dzieje się tak dlatego, że region pomocniczy Indii Zachodnich to Indie Południowe, ale region pomocniczy Indii Południowych nie jest Indiami Zachodnimi.

Tworzenie repliki

Ważne

  • Funkcja repliki do odczytu jest dostępna tylko dla serwerów usługi Azure Database for MySQL w warstwach cenowych Ogólnego przeznaczenia lub Zoptymalizowane pod kątem pamięci. Upewnij się, że serwer źródłowy znajduje się w jednej z tych warstw cenowych.
  • Jeśli serwer źródłowy nie ma istniejących serwerów repliki, serwer źródłowy może wymagać ponownego uruchomienia, aby przygotować się do replikacji w zależności od używanego magazynu (v1/v2). Rozważ ponowne uruchomienie serwera i wykonaj tę operację poza godzinami szczytu. Aby uzyskać więcej szczegółów, zobacz Ponowne uruchamianie serwera źródłowego.

Po uruchomieniu przepływu pracy tworzenia repliki zostanie utworzony pusty serwer usługi Azure Database for MySQL. Nowy serwer jest wypełniony danymi, które znajdowały się na serwerze źródłowym. Czas tworzenia zależy od ilości danych od źródła i czasu od ostatniej cotygodniowej pełnej kopii zapasowej. Czas może wahać się od kilku minut do kilku godzin. Serwer repliki jest zawsze tworzony w tej samej grupie zasobów i tej samej subskrypcji co serwer źródłowy. Jeśli chcesz utworzyć serwer repliki do innej grupy zasobów lub innej subskrypcji, możesz przenieść serwer repliki po utworzeniu.

Każda replika jest włączona do automatycznego zwiększania rozmiaru magazynu. Funkcja automatycznego zwiększania umożliwia replikom nadążanie za replikowanymi danymi i zapobieganie przerwom w replikacji spowodowanej błędami braku pamięci masowej.

Dowiedz się, jak utworzyć replikę do odczytu w witrynie Azure Portal.

Nawiązywanie połączenia z repliką

Podczas tworzenia replika dziedziczy reguły zapory serwera źródłowego. Następnie te reguły są niezależne od serwera źródłowego.

Replika dziedziczy konto administratora z serwera źródłowego. Wszystkie konta użytkowników na serwerze źródłowym są replikowane do replik do odczytu. Można nawiązać połączenie tylko z repliką do odczytu przy użyciu kont użytkowników dostępnych na serwerze źródłowym.

Możesz nawiązać połączenie z repliką przy użyciu jego nazwy hosta i prawidłowego konta użytkownika, tak jak na zwykłym serwerze usługi Azure Database for MySQL. W przypadku serwera o nazwie myreplica z nazwą użytkownika administratora myadmin możesz nawiązać połączenie z repliką przy użyciu interfejsu wiersza polecenia mysql:

mysql -h myreplica.mysql.database.azure.com -u myadmin@myreplica -p

Po wyświetleniu monitu wprowadź hasło dla konta użytkownika.

Monitorowanie replikacji

Usługa Azure Database for MySQL zapewnia opóźnienie replikacji w sekundach w usłudze Azure Monitor. Ta metryka jest dostępna tylko dla replik. Ta metryka jest obliczana przy użyciu metryki dostępnej seconds_behind_masterSHOW SLAVE STATUS w poleceniu mySQL. Ustaw alert informujący o osiągnięciu opóźnienia replikacji, która nie jest akceptowalna dla obciążenia.

Jeśli widzisz zwiększone opóźnienie replikacji, zapoznaj się z tematem Rozwiązywanie problemów z opóźnieniem replikacji, aby rozwiązać problemy i zrozumieć możliwe przyczyny.

Zatrzymywanie replikacji

Replikację między źródłem a repliką można zatrzymać. Po zatrzymaniu replikacji między serwerem źródłowym a repliką do odczytu replika staje się serwerem autonomicznym. Dane na serwerze autonomicznym to dane, które były dostępne w repliki w momencie uruchomienia polecenia zatrzymania replikacji. Serwer autonomiczny nie nadrabia zaległości z serwerem źródłowym.

Gdy zdecydujesz się zatrzymać replikację do repliki, utraci wszystkie łącza do poprzedniego źródła i innych replik. Nie ma automatycznego przejścia w tryb failover między źródłem a repliką.

Ważne

Nie można ponownie utworzyć autonomicznego serwera w repliki. Przed zatrzymaniem replikacji w repliki do odczytu upewnij się, że replika ma wszystkie wymagane dane.

Dowiedz się, jak zatrzymać replikację do repliki.

Tryb failover

Nie ma automatycznego trybu failover między serwerami źródłowymi i replikami.

Ponieważ replikacja jest asynchroniczna, występuje opóźnienie między źródłem a repliką. Wpływ na opóźnienie może mieć wiele czynników, takich jak duże obciążenie uruchomione na serwerze źródłowym i opóźnienie między centrami danych. W większości przypadków opóźnienia repliki wynoszą od kilku sekund do kilku minut. Rzeczywiste opóźnienie replikacji można śledzić przy użyciu metryki Opóźnienie repliki, która jest dostępna dla każdej repliki. Ta metryka pokazuje czas od ostatniej ponownej transakcji. Zalecamy zidentyfikowanie średniego opóźnienia przez zaobserwowanie opóźnienia repliki w danym okresie. Możesz ustawić alert dotyczący opóźnienia repliki, aby jeśli wykracza poza oczekiwany zakres, możesz podjąć akcję.

Napiwek

Jeśli przejdziesz w tryb failover do repliki, opóźnienie podczas odłączania repliki ze źródła wskaże, ile danych zostanie utraconych.

Po podjęciu decyzji o przejściu w tryb failover do repliki:

  1. Zatrzymywanie replikacji do repliki
    Ten krok jest niezbędny, aby serwer repliki mógł akceptować zapisy. W ramach tego procesu serwer repliki zostanie odłączony od źródła. Po zainicjowaniu zatrzymania replikacji proces zaplecza zwykle trwa około 2 minut. Zobacz sekcję Zatrzymywanie replikacji w tym artykule, aby zrozumieć implikacje tej akcji.

  2. Wskazywanie aplikacji na replikę (dawniej)
    Każdy serwer ma unikatowy parametry połączenia. Zaktualizuj aplikację, aby wskazywała (poprzednią) replikę zamiast źródła.

Po pomyślnym przetworzeniu odczytów i zapisów przez aplikację ukończono tryb failover. Ilość przestojów środowiska aplikacji zależy od wykrytego problemu i wykonania kroków 1 i 2 wymienionych wcześniej.

Globalny identyfikator transakcji (GTID)

Globalny identyfikator transakcji (GTID) jest unikatowym identyfikatorem utworzonym przy użyciu każdej zatwierdzonej transakcji na serwerze źródłowym i jest domyślnie wyłączony w usłudze Azure Database for MySQL. Identyfikator GTID jest obsługiwany w wersjach 5.7 i 8.0 i tylko na serwerach obsługujących magazyn do 16 TB (magazyn ogólnego przeznaczenia w wersji 2). Aby dowiedzieć się więcej o identyfikatorze GTID i sposobie jej użycia w replikacji, zapoznaj się z dokumentacją dotyczącą replikacji bazy danych MySQL za pomocą identyfikatora GTID .

Usługa MySQL obsługuje dwa typy transakcji: transakcje GTID (identyfikowane z identyfikatorem GTID) i anonimowe transakcje (nie mają przydzielonego identyfikatora GTID)

Do konfigurowania identyfikatora GTID są dostępne następujące parametry serwera:

Parametr serwera Opis Wartość domyślna Wartości
gtid_mode Wskazuje, czy identyfikatory GTID są używane do identyfikowania transakcji. Zmiany między trybami można wykonać tylko jeden krok w kolejności rosnącej (np. OFF -OFF_PERMISSIVE> -ON>ON_PERMISSIVE>) OFF OFF: Zarówno nowe, jak i transakcje replikacji muszą być anonimowe
OFF_PERMISSIVE: Nowe transakcje są anonimowe. Zreplikowane transakcje mogą być transakcjami anonimowym lub GTID.
ON_PERMISSIVE: Nowe transakcje to transakcje GTID. Zreplikowane transakcje mogą być transakcjami anonimowym lub GTID.
ON: Zarówno nowe, jak i zreplikowane transakcje muszą być transakcjami GTID.
enforce_gtid_consistency Wymusza spójność identyfikatora GTID, zezwalając na wykonywanie tylko tych instrukcji, które mogą być rejestrowane w bezpieczny sposób transakcyjnie. Tę wartość należy ustawić na przed ON włączeniem replikacji GTID. OFF OFF: Wszystkie transakcje mogą naruszać spójność identyfikatora GTID.
ON: Żadna transakcja nie może naruszać spójności GTID.
WARN: Wszystkie transakcje mogą naruszać spójność identyfikatora GTID, ale jest generowane ostrzeżenie.

Uwaga

  • Po włączeniu identyfikatora GTID nie można go wyłączyć. Jeśli musisz wyłączyć gtID, skontaktuj się z pomocą techniczną.

  • Aby zmienić identyfikator GTID z jednej wartości na inną, może być tylko jeden krok w czasie w kolejności rosnącej trybów. Jeśli na przykład gtid_mode jest obecnie ustawiona na OFF_PERMISSIVE, można zmienić wartość na ON_PERMISSIVE, ale nie na WŁ.

  • Aby zachować spójność replikacji, nie można zaktualizować jej dla serwera głównego/repliki.

  • Zalecane ustawienie ustawienia enforce_gtid_consistency na WŁĄCZONE przed ustawieniem gtid_mode=ON

Aby włączyć identyfikator GTID i skonfigurować zachowanie spójności, zaktualizuj gtid_mode parametry serwera i enforce_gtid_consistency przy użyciu witryny Azure Portal, interfejsu wiersza polecenia platformy Azure lub programu PowerShell.

Jeśli identyfikator GTID jest włączony na serwerze źródłowym (gtid_mode = WŁĄCZONE), nowo utworzone repliki będą również miały włączone identyfikator GTID i będą korzystać z replikacji GTID. Aby upewnić się, że replikacja jest spójna, gtid_mode nie można zmienić po utworzeniu serwerów głównych lub replik z włączonym identyfikatorem GTID.

Rozważania i ograniczenia

Warstwy cenowe

Repliki do odczytu są obecnie dostępne tylko w warstwach cenowych Ogólnego przeznaczenia i Zoptymalizowane pod kątem pamięci.

Uwaga

Koszt uruchamiania serwera repliki zależy od regionu, w którym działa serwer repliki.

Ponowne uruchamianie serwera źródłowego

Serwer, który ma magazyn ogólnego przeznaczenia w wersji 1, log_bin parametr będzie domyślnie wyłączony. Wartość zostanie włączona podczas tworzenia pierwszej repliki do odczytu. Jeśli serwer źródłowy nie ma istniejących replik do odczytu, serwer źródłowy najpierw uruchomi się ponownie, aby przygotować się do replikacji. Rozważ ponowne uruchomienie serwera i wykonaj tę operację poza godzinami szczytu.

Serwer źródłowy z magazynem ogólnego przeznaczenia w wersji 2, log_bin parametr będzie domyślnie włączony i nie wymaga ponownego uruchomienia podczas dodawania repliki do odczytu.

Nowe repliki

Replika do odczytu jest tworzona jako nowy serwer usługi Azure Database for MySQL. Nie można utworzyć istniejącego serwera w repliki. Nie można utworzyć repliki innej repliki do odczytu.

Konfiguracja repliki

Replika jest tworzona przy użyciu tej samej konfiguracji serwera co źródło. Po utworzeniu repliki można zmienić kilka ustawień niezależnie od serwera źródłowego: generowanie zasobów obliczeniowych, rdzenie wirtualne, magazyn i okres przechowywania kopii zapasowych. Warstwę cenową można również zmienić niezależnie, z wyjątkiem warstwy Podstawowa lub z warstwy Podstawowa.

Ważne

Przed zaktualizowaniem konfiguracji serwera źródłowego do nowych wartości zaktualizuj konfigurację repliki do takich samych lub wyższych wartości. Dzięki temu replika może być na bieżąco ze zmianami wprowadzonymi w źródle.

Reguły zapory i ustawienia parametrów są dziedziczone z serwera źródłowego do repliki podczas tworzenia repliki. Następnie reguły repliki są niezależne.

Zatrzymane repliki

Jeśli zatrzymasz replikację między serwerem źródłowym a repliką do odczytu, zatrzymana replika stanie się autonomicznym serwerem, który akceptuje zarówno operacje odczytu, jak i zapisu. Nie można ponownie utworzyć autonomicznego serwera w repliki.

Usunięte serwery źródłowe i autonomiczne

Po usunięciu serwera źródłowego replikacja zostanie zatrzymana do wszystkich replik do odczytu. Te repliki stają się automatycznie serwerami autonomicznymi i mogą akceptować zarówno operacje odczytu, jak i zapisu. Sam serwer źródłowy jest usuwany.

Konta użytkowników

Użytkownicy na serwerze źródłowym są replikowane do replik do odczytu. Można nawiązać połączenie tylko z repliką do odczytu przy użyciu kont użytkowników dostępnych na serwerze źródłowym.

Parametry serwera

Aby zapobiec utracie synchronizacji danych i ich możliwej utracie lub uszkodzeniu, aktualizacja niektórych parametrów jest zablokowana w przypadku korzystania z replik do odczytu.

Następujące parametry serwera są zablokowane zarówno na serwerach źródłowych, jak i replikowych:

Parametr event_scheduler jest zablokowany na serwerach repliki.

Aby zaktualizować jeden z powyższych parametrów na serwerze źródłowym, usuń serwery repliki, zaktualizuj wartość parametru w źródle i utwórz ponownie repliki.

IDENTYFIKATOR GTID

Identyfikator GTID jest obsługiwany w:

  • MySQL w wersji 5.7 i 8.0.
  • Serwery obsługujące magazyn do 16 TB. Zapoznaj się z artykułem dotyczącym warstwy cenowej, aby uzyskać pełną listę regionów obsługujących magazyn o pojemności 16 TB.

IDENTYFIKATOR GTID jest domyślnie wyłączony. Po włączeniu identyfikatora GTID nie można go wyłączyć. Jeśli musisz wyłączyć identyfikator GTID, skontaktuj się z pomocą techniczną.

Jeśli identyfikator GTID jest włączony na serwerze źródłowym, nowo utworzone repliki będą również miały włączone identyfikatory GTID i będą używać replikacji GTID. Aby zachować spójność replikacji, nie można aktualizować gtid_mode serwerów źródłowych ani replik.

Inne

  • Tworzenie repliki repliki nie jest obsługiwane.
  • Tabele w pamięci mogą spowodować, że repliki nie będą zsynchronizowane. Jest to ograniczenie technologii replikacji MySQL. Aby uzyskać więcej informacji, przeczytaj więcej w dokumentacji referencyjnej bazy danych MySQL.
  • Upewnij się, że tabele serwera źródłowego mają klucze podstawowe. Brak kluczy podstawowych może spowodować opóźnienie replikacji między źródłem a replikami.
  • Zapoznaj się z pełną listą ograniczeń replikacji mySQL w dokumentacji programu MySQL

Następne kroki