Repliki do odczytu w usłudze Azure Database for MySQL — serwer elastyczny

  • Artykuł

DOTYCZY: Azure Database for MySQL — serwer elastyczny

MySQL to jeden z popularnych aparatów baz danych do uruchamiania internetowych aplikacji internetowych i mobilnych. Wielu naszych klientów korzysta z niego w swoich usługach edukacyjnych online, usługach przesyłania strumieniowego wideo, rozwiązaniach do płatności cyfrowych, platformach handlu elektronicznego, usługach gier, portalach informacyjnych, instytucjach rządowych i witrynach internetowych opieki zdrowotnej. Te usługi są wymagane do obsługi i skalowania w miarę wzrostu ruchu w sieci Web lub aplikacji mobilnej.

Po stronie aplikacji aplikacja jest zwykle opracowywana w języku Java lub PHP i migrowana do uruchamiania w usłudze Azure Virtual Machine Scale Sets lub aplikacja systemu Azure Services lub konteneryzowana do uruchamiania w usłudze Azure Kubernetes Service (AKS). Dzięki zestawowi skalowania maszyn wirtualnych, usłudze App Service lub usłudze AKS jako podstawowej infrastruktury skalowanie aplikacji jest uproszczone dzięki natychmiastowej aprowizacji nowych maszyn wirtualnych i replikowaniu bezstanowych składników aplikacji do obsługi żądań, ale często baza danych stanowi wąskie gardło jako scentralizowany składnik stanowy.

Funkcja repliki do odczytu umożliwia replikowanie danych z elastycznego wystąpienia serwera usługi Azure Database for MySQL do serwera tylko do odczytu. Można replikować z serwera źródłowego do maksymalnie 10 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 do źródłowych wystąpień serwera elastycznego usługi Azure Database for MySQL. Opłaty za rozliczenia są naliczane za każdą replikę do odczytu na podstawie aprowizowanych zasobów obliczeniowych w rdzeniach wirtualnych i magazynie w GB/miesiąc. Aby uzyskać więcej informacji, zobacz cennik.

Uwaga

Funkcja repliki do odczytu jest dostępna tylko dla wystąpień serwera elastycznego usługi Azure Database for MySQL w warstwach cenowych Ogólnego przeznaczenia lub Krytyczne dla działania firmy. Upewnij się, że serwer źródłowy znajduje się w jednej z tych warstw cenowych.

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.

Typowe przypadki użycia 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.

Typowe scenariusze to:

  • Skalowanie obciążeń odczytu pochodzących z aplikacji przy użyciu uproszczonego serwera proxy połączenia, takiego jak ProxySQL lub wzorzec oparty na mikrousługach, aby skalować zapytania odczytu pochodzące z aplikacji do replik do odczytu
  • Obciążenia analizy biznesowej lub raportowania analitycznego mogą używać replik do odczytu jako źródła danych do raportowania
  • W przypadku scenariusza IoT lub produkcji, w którym informacje telemetryczne są pozyskiwane do aparatu bazy danych MySQL, podczas gdy wiele replik do odczytu jest używanych do raportowania danych

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. Istnieje mierzalne opóźnienie między źródłem a repliką. 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 elastyczny usługi Azure Database for MySQL umożliwia aprowizację repliki do odczytu w dowolnym pomoc techniczna platformy Azure regionach, w których jest dostępny elastyczny serwer usługi Azure Database for MySQL. Za pomocą tej funkcji serwer źródłowy może mieć replikę w sparowanym regionie lub regionach uniwersalnej repliki. Zapoznaj się z tym artykułem , aby znaleźć listę regionów świadczenia usługi Azure, w których obecnie jest dostępny serwer elastyczny usługi Azure Database for MySQL.

Tworzenie repliki

Jeśli serwer źródłowy nie ma istniejących serwerów repliki, źródło najpierw uruchamia się ponownie, aby przygotować się do replikacji.

Po uruchomieniu przepływu pracy tworzenia repliki zostanie utworzone puste wystąpienie serwera elastycznego 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.

Uwaga

Repliki do odczytu są tworzone przy użyciu tej samej konfiguracji serwera co źródło. Konfigurację serwera repliki można zmienić po jej utworzeniu. 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. Zaleca się, aby konfiguracja serwera repliki była przechowywana w równych lub większych wartościach niż źródło, aby upewnić się, że replika jest w stanie nadążyć za źródłem.

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

Nawiązywanie połączenia z repliką

Podczas tworzenia replika dziedziczy metodę łączności serwera źródłowego. Nie można zmienić metody łączności repliki. Jeśli na przykład serwer źródłowy ma dostęp prywatny (integracja z siecią wirtualną), replika nie może znajdować się w dostępie publicznym (dozwolonych adresach IP).

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 w przypadku zwykłego wystąpienia serwera elastycznego 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 -p

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

Monitorowanie replikacji

Elastyczny serwer usługi 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.

Ważne

Funkcja Read Replica używa technologii replikacji opartej na magazynie, która nie używa już metryki "SLAVE_IO_RUNNING"/"REPLICA_IO_RUNNING" dostępnej w poleceniu "SHOW SLAVE STATUS"/"SHOW REPLICA STATUS". Ta wartość jest zawsze wyświetlana jako "Nie" i nie wskazuje na stan replikacji. Aby poznać prawidłowy stan replikacji, zapoznaj się z metrykami replikacji — Stan operacji we/wy repliki i Stan bazy danych SQL repliki w bloku Monitorowanie.

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.

Repliki do odczytu są przeznaczone do skalowania obciążeń intensywnie korzystających z odczytu i nie są zaprojektowane tak, aby spełniały potrzeby serwera o wysokiej dostępności. Zatrzymanie replikacji na repliki do odczytu w celu przełączenie jej do trybu zapisu w trybie odczytu jest sposobem, w jaki odbywa się ręczne przejście w tryb failover.

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 przełączysz replikę w tryb failover, opóźnienie podczas odłączania repliki ze źródła wskazuje ilość utraconych danych.

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 jest odłączany 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. Czas przestoju środowiska aplikacji zależy od wykrycia problemu i wykonania kroków 1 i 2 powyżej.

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 na serwerze elastycznym usługi Azure Database for MySQL. Identyfikator GTID jest obsługiwany w wersjach 5.7 i 8.0. 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 .

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.

W przypadku wystąpień serwera elastycznego usługi Azure Database for MySQL z włączoną funkcją wysokiej dostępności wartość domyślna to ON.

Uwaga

  • Po włączeniu identyfikatora GTID nie można go wyłączyć. Jeśli musisz wyłączyć gtID, skontaktuj się z pomocą techniczną.
  • Identyfikatory GTID można zmienić z jednej wartości na jeden krok jednocześnie 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.
  • Zaleca się ustawienie 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 lub interfejsu wiersza polecenia platformy Azure.

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

Rozważania i ograniczenia

Scenariusz Ograniczenie/zagadnienia
Replika na serwerze w warstwie cenowej z możliwością wzrostu wydajności Nieobsługiwane
Cennik Koszt uruchomienia serwera repliki zależy od regionu, w którym działa serwer repliki
Ponowne uruchamianie serwera źródłowego Podczas tworzenia repliki dla źródła, które nie ma istniejących replik, źródło najpierw uruchomi się ponownie, aby przygotować się do replikacji. Weź to pod uwagę i wykonaj te operacje w okresie poza szczytem
Nowe repliki Replika do odczytu jest tworzona jako nowe wystąpienie serwera elastycznego 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ę obliczeniową można również zmienić niezależnie.

WAŻNE — przed zaktualizowaniem konfiguracji serwera źródłowego do nowych wartości zaktualizuj konfigurację repliki tak, aby były równe lub większe. Dzięki temu replika może być na bieżąco ze zmianami wprowadzonymi w źródle.
Połączenie ivity metoda 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:
- innodb_file_per_table
- log_bin_trust_function_creators
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.
Parametry poziomu sesji Podczas konfigurowania parametrów poziomu sesji, takich jak "foreign_keys_checks" w repliki do odczytu, upewnij się, że wartości parametrów ustawiane w repliki do odczytu są zgodne z parametrami serwera źródłowego.
Dodanie kolumny AUTO_INCREMENT Klucz podstawowy do istniejącej tabeli na serwerze źródłowym. Nie zalecamy zmiany tabeli przy użyciu AUTO_INCREMENT po utworzeniu repliki do odczytu, ponieważ przerywa replikację. Jeśli jednak chcesz dodać kolumnę automatycznego przyrostu po utworzeniu serwera repliki, zalecamy następujące dwa podejścia:
— Utwórz nową tabelę z tym samym schematem tabeli, którą chcesz zmodyfikować. W nowej tabeli zmień kolumnę na AUTO_INCREMENT, a następnie z oryginalnej tabeli przywróć dane. Usuń starą tabelę i zmień jej nazwę w źródle. Nie jest to konieczne, aby usunąć serwer repliki, ale może wymagać dużego kosztu wstawiania do utworzenia tabeli kopii zapasowej.
— Drugą szybszą metodą jest ponowne utworzenie repliki po dodaniu wszystkich kolumn automatycznego przyrostu.
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.
— Przejrzyj pełną listę ograniczeń replikacji bazy danych MySQL w dokumentacji programu MySQL

Następne kroki