Udostępnij przez

Repliki do odczytu w usłudze Azure Database for MySQL

MySQL to jeden z popularnych aparatów baz danych do uruchamiania internetowych aplikacji internetowych i mobilnych. Wielu klientów korzysta z usługi Azure Database for MySQL dla szerokiej gamy aplikacji, w tym edukacji online, przesyłania strumieniowego wideo, płatności cyfrowych, handlu elektronicznego, gier, portali informacyjnych, instytucji rządowych i witryn internetowych opieki zdrowotnej. Te usługi muszą być w stanie obsługiwać i skalować w miarę wzrostu ruchu w internecie lub aplikacji mobilnej.

Po stronie aplikacji deweloperzy zazwyczaj używają języka Java lub PHP. Migrują aplikację do uruchamiania w usłudze Azure Virtual Machine Scale Sets, Azure App Services lub konteneryzują ją, aby była uruchamiana 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ń. Jednak baza danych często staje się wąskim gardłem jako scentralizowany składnik stanowy.

Funkcja repliki do odczytu umożliwia replikowanie danych z wystąpienia serwera elastycznego 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 opartej na pozycji pliku dziennika binarnego (binlog) aparatu MySQL. Aby dowiedzieć się więcej na temat replikacji binlogów, zobacz Omówienie replikacji binlogów MySQL.

Repliki są zarządzane jako nowe serwery, podobnie jak w przypadku ź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 aprowizowanej mocy obliczeniowej w rdzeniach wirtualnych i magazynie w GB miesięcznie. Aby uzyskać więcej informacji, zobacz cennik.

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 podrzędnego , termin, którego firma Microsoft już nie używa. Gdy usuniemy termin z oprogramowania, usuniemy go z tego artykułu.

Typowe przypadki użycia repliki do odczytu

Funkcja repliki do odczytu pomaga zwiększyć wydajność i skalę obciążeń intensywnie korzystających z odczytu. Obciążenia odczytu można odizolować do replik, a jednocześnie kierować obciążenia zapisu do źródła.

Typowe scenariusze obejmują:

  • 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 w celu skalowania zapytań odczytu pochodzących z aplikacji do replik do odczytu
  • Używanie replik do odczytu jako źródła danych dla obciążeń analizy biznesowej lub raportowania analitycznego
  • Pozyskiwanie informacji telemetrycznych do aparatu bazy danych MySQL podczas korzystania z wielu replik do odczytu na potrzeby raportowania danych w scenariuszach IoT lub Manufacturing

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 obsługiwanym regionie świadczenia usługi Azure Database for MySQL — serwer elastyczny. Za pomocą tej funkcji serwer źródłowy może mieć replikę w sparowanym regionie lub regionach uniwersalnej repliki. Zobacz tutaj , 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

Po uruchomieniu przepływu pracy tworzenia repliki utworzysz puste wystąpienie serwera elastycznego usługi Azure Database for MySQL. Nowy serwer zawiera dane, 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 z tą samą konfiguracją serwera co źródło. Konfigurację serwera repliki można zmienić po utworzeniu. Zawsze należy utworzyć serwer repliki w tej samej grupie zasobów i subskrypcji co serwer źródłowy. Jeśli chcesz utworzyć serwer repliki w innej grupie zasobów lub innej subskrypcji, możesz przenieść serwer repliki po utworzeniu . Zachowaj konfigurację serwera repliki z równymi lub większymi wartościami niż źródło, aby upewnić się, że replika może nadążyć za źródłem.

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

Nawiązywanie połączenia z repliką

Podczas tworzenia repliki dziedziczy ona metodę łączności serwera źródłowego. Nie można zmienić metody łączności repliki. Jeśli na przykład serwer źródłowy korzysta z dostępu prywatnego (integracja z siecią wirtualną), replika nie może używać dostępu publicznego (dozwolonych adresów 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

Usługa Azure Database for MySQL Flexible Server zapewnia metrykę opóźnienia replikacji w sekundach w usłudze Azure Monitor. Ta metryka jest dostępna tylko dla replik. Usługa Azure Monitor oblicza tę metryę przy użyciu seconds_behind_master metryki w poleceniu mySQL SHOW SLAVE STATUS . Ustaw alert, aby otrzymywać powiadomienia, gdy opóźnienie replikacji przekracza niedopuszczalny próg 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

Replika do odczytu używa technologii replikacji opartej na magazynie, która nie używa SLAVE_IO_RUNNING/REPLICA_IO_RUNNING już metryki dostępnej SHOW SLAVESTATUS'/'SHOWREPLICA STATUS w poleceniu mySQL. Ta wartość jest zawsze wyświetlana jako "Nie" i nie wskazuje na stan replikacji. Aby poznać prawidłowy stan replikacji, zobacz Metryki replikacji — Stan repliki IO i Stan sql repliki na stronie Monitorowanie.

Zatrzymywanie replikacji

Replikację między serwerem źródłowym i serwerem repliki można zatrzymać. Po zatrzymaniu replikacji między serwerem źródłowym a repliką do odczytu serwer repliki staje się serwerem autonomicznym. Serwer autonomiczny zawiera dane, które były dostępne na serwerze repliki po uruchomieniu polecenia zatrzymania replikacji. Autonomiczny serwer nie synchronizuje żadnych brakujących danych z serwera źródłowego.

Po zatrzymaniu replikacji do serwera repliki serwer repliki utraci wszystkie łącza do poprzedniego serwera źródłowego i innych serwerów repliki. Nie ma automatycznego trybu failover między serwerem źródłowym a serwerami repliki.

Ważne

Nie można przekonwertować autonomicznego serwera z powrotem na serwer repliki. Przed zatrzymaniem replikacji w repliki do odczytu upewnij się, że serwer repliki zawiera wszystkie potrzebne dane.

Aby uzyskać więcej informacji, zobacz Zatrzymywanie replikacji do repliki.

Tryb failover

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

Repliki do odczytu skalują obciążenia intensywnie korzystające z odczytu i nie zapewniają wysokiej dostępności dla serwera. Ręczne przechodzenie w tryb failover można wykonać, zatrzymując replikację w repliki do odczytu, przenosząc ją do trybu odczytu i zapisu w trybie online.

Ponieważ replikacja jest asynchroniczna, występuje opóźnienie między źródłem a repliką. Wiele czynników wpływa na opóźnienie, takie jak obciążenie na serwerze źródłowym i opóźnienie między centrami danych. W większości przypadków opóźnienie repliki waha się 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 obserwowanie opóźnienia repliki w czasie. 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łączenia 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

    Należy zatrzymać replikację, aby serwer repliki mógł akceptować zapisy. Ten proces delinkuje serwer repliki ze źródła. Po zainicjowaniu zatrzymania replikacji proces zaplecza zwykle trwa około dwóch 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 zakończeniu pracy w trybie failover aplikacja pomyślnie przetwarza operacje odczytu i zapisu. Czas przestoju środowiska aplikacji zależy od momentu wykrycia problemu i wykonania kroków 1 i 2.

Globalny identyfikator transakcji (GTID)

Globalny identyfikator transakcji (GTID) to unikatowy identyfikator tworzony przez serwer źródłowy przy użyciu każdej zatwierdzonej transakcji. Serwer elastyczny usługi Azure Database for MySQL domyślnie wyłącza identyfikator GTID. Wersje 5.7 i 8.0 obsługują identyfikator GTID. Aby uzyskać więcej informacji na temat identyfikatora GTID i sposobu jej użycia, zobacz dokumentację replikacji mySQL z identyfikatorem GTID .

Użyj następujących parametrów serwera, aby skonfigurować identyfikator GTID:

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. Ustaw wartość ON przed 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

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.

Po włączeniu identyfikatora GTID nie można go wyłączyć. Jeśli musisz wyłączyć identyfikator 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 parametr jest obecnie ustawiony na OFF_PERMISSIVE, możesz go zmienić na ON_PERMISSIVE , ale nie na ON.

Aby zachować spójność replikacji, nie można zaktualizować jej dla serwera podstawowego lub repliki.

Ustaw enforce_gtid_consistency wartość na ON przed ustawieniem gtid_mode na ON.

Aby włączyć identyfikator GTID i skonfigurować zachowanie spójności, zaktualizuj gtid_mode parametry serwera i enforce_gtid_consistency . Użyj opcji Konfigurowanie parametrów serwera w usłudze Azure Database for MySQL — serwer elastyczny przy użyciu witryny Azure Portal lub Konfigurowanie parametrów serwera w usłudze Azure Database for MySQL — serwer elastyczny przy użyciu interfejsu wiersza polecenia platformy Azure.

Jeśli serwer źródłowy włącza identyfikator GTID (gtid_mode = ON), nowo utworzone repliki włączają również identyfikator GTID i używają replikacji GTID. Aby zapewnić spójność replikacji, nie można zmienić gtid_mode po utworzeniu serwerów podstawowych lub replik 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.
Przestój/ponowne uruchomienie serwera źródłowego Podczas tworzenia repliki do odczytu nie jest konieczne ponowne uruchomienie ani przestój. Ta operacja jest operacją online.
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 Replikę można utworzyć 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. Możesz również niezależnie zmienić warstwę obliczeniową.

WAŻNE — przed zaktualizowaniem konfiguracji serwera źródłowego do nowych wartości zaktualizuj konfigurację repliki na równe lub większe wartości. Dzięki temu replika może być na bieżąco ze zmianami wprowadzonymi w źródle.
Metoda łączności 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 replikę.
Usunięte serwery źródłowe 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 replice do odczytu, upewnij się, że wartości parametrów ustawianych w replice do odczytu są zgodne z tymi z serwera źródłowego.
Dodawanie kolumny AUTO_INCREMENT Klucz podstawowy do istniejącej tabeli na serwerze źródłowym Nie zalecamy zmiany tabeli AUTO_INCREMENT za pomocą polecenia po utworzeniu repliki do odczytu, ponieważ ta akcja przerywa replikację. Jeśli chcesz dodać kolumnę automatycznego zwiększania po utworzeniu serwera repliki, rozważ następujące podejścia:
— Utwórz nową tabelę z tym samym schematem co tabela, którą chcesz zmodyfikować. W nowej tabeli zmień kolumnę na AUTO_INCREMENT, a następnie przywróć dane z oryginalnej tabeli. Usuń starą tabelę i zmień jej nazwę w źródle; Takie podejście nie wymaga usunięcia serwera repliki, ale może wiązać się z dużymi kosztami wstawiania w celu utworzenia tabeli kopii zapasowej.
— Utwórz ponownie replikę 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. To ograniczenie jest spowodowane technologią replikacji MySQL. Aby uzyskać więcej informacji, zobacz dokumentację referencyjną 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 mySQL w dokumentacji programu MySQL.

Powiązana zawartość

  • Last updated on