Repliki do odczytu w usłudze Azure Database for MySQL

MySQL to jeden z popularnych silników baz danych do obsługi aplikacji internetowych i mobilnych na skalę internetową. 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 silnika MySQL opartej na pozycji pliku dziennika binarnego (binlog). 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. Naliczane są opłaty za każdą replikę do odczytu na podstawie przydzielonej mocy obliczeniowej w vCores oraz magazynu w GB miesięcznie. Aby uzyskać więcej informacji, zobacz cennik.

Funkcja repliki do odczytu jest dostępna tylko dla elastycznych serwerów bazy danych Azure Database for MySQL w warstwach cenowych Ogólnego przeznaczenia lub Optymalizowanej dla pamięci. 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 tworzenia replik odczytu pomaga zwiększać wydajność i skalowalność obciążeń intensywnie korzystających z operacji 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 lekkiego proxy do obsługi połączeń, takiego jak ProxySQL, lub wzorca opartego na mikrousługach do 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 silnika bazy danych MySQL podczas korzystania z wielu replik odczytowych na potrzeby raportowania danych w scenariuszach IoT lub produkcyjnych.

Ponieważ repliki są tylko do odczytu, nie zmniejszają bezpośrednio obciążeń zapisu w źródle. Ta funkcja nie jest zoptymalizowana dla pracy intensywnie wykorzystującej zapis.

Funkcja repliki odczytu używa asynchronicznej replikacji 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 utworzenie repliki do odczytu w dowolnym obsługiwanych przez Azure regionie, w których dostępny jest serwer elastyczny usługi Azure Database for MySQL. Za pomocą tej funkcji serwer źródłowy może mieć replikę w sparowanym regionie lub uniwersalnych regionach replik. 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 rozpoczęciu procesu tworzenia repliki utworzysz nowe wystąpienie serwera elastycznego 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.

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 jej nazwy hosta i prawidłowego konta użytkownika, tak jak w przypadku zwykłego wystąpienia elastycznego serwera 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ę metrykę przy użyciu metryki seconds_behind_master w polecenia 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 wykorzystuje technologię replikacji opartą na magazynie, która już nie używa metryki SLAVE_IO_RUNNING/REPLICA_IO_RUNNING dostępnej w poleceniu MySQL SHOW SLAVESTATUS'/'SHOWREPLICA STATUS. Ta wartość jest zawsze wyświetlana jako "Nie" i nie wskazuje na stan replikacji. Aby poznać prawidłowy stan replikacji, przejdź do sekcji Metryki replikacji — Stan repliki oraz 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. Brak automatycznego przełączenia awaryjnego między serwerem źródłowym a jego serwerami replica.

Ważne

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

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

Przełączanie awaryjne

Nie ma automatycznego przełączania awaryjnego między serwerem źródłowym a serwerami replik.

Repliki do odczytu skalują obciążenia intensywnie korzystające z odczytu i nie zapewniają wysokiej dostępności dla serwera. Ręczne przełączanie na tryb przełączenia awaryjnego można wykonać, zatrzymując replikację na replikacie odczytu i włączając go w trybie odczytu-zapisu.

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 czasu opóźnienia poprzez obserwację opóźnienia repliki w dłuższym okresie czasu. Możesz ustawić alert dotyczący opóźnienia repliki, aby jeśli wykracza poza oczekiwany zakres, możesz podjąć akcję.

Wskazówka

Jeśli przełączysz na replikę, opóźnienie w momencie odłączenia repliki od źródła wskazuje, ile danych zostało utraconych.

Po podjęciu decyzji o przełączeniu do repliki:

1. Zatrzymaj replikację do repliki

   Należy zatrzymać replikację, aby serwer repliki mógł akceptować zapisy. Ten proces odłącza serwer repliki od ź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. Wskaż swoją aplikację na byłą replikę

   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 Azure Database for MySQL domyślnie wyłącza GTID. Wersje 5.7 i 8.0 obsługują identyfikator GTID. Aby uzyskać więcej informacji na temat identyfikatora GTID i jak replikacja używa go, 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_PERMISSIVE>ON)	OFF*	OFF: Zarówno nowe, jak i transakcje replikacji muszą być anonimowe OFF_PERMISSIVE: Nowe transakcje są anonimowe. Zreplikowane transakcje mogą być anonimowymi lub GTID. ON_PERMISSIVE: Nowe transakcje to transakcje GTID. Zreplikowane transakcje mogą być transakcjami anonimowymi 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 sposób gwarantujący bezpieczeństwo transakcji. Ustaw wartość ON przed włączeniem replikacji GTID.	OFF*	OFF: Wszystkie transakcje mogą naruszać spójność GTID. ON: Żadna transakcja nie może naruszać spójności GTID. WARN: Wszystkie transakcje mają pozwolenie na naruszanie spójności identyfikatora GTID, ale wygenerowane zostanie ostrzeżenie.

Uwaga

W przypadku wystąpień serwerów elastycznych 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 zmieniać z jednej wartości na drugą, jednym krokiem na raz, w rosnącej kolejności 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 parametry serwera gtid_mode 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 elastycznej warstwie cenowej	Nieobsługiwany
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	Tworzysz replikę do odczytu jako nowe wystąpienie serwera elastycznego usługi Azure Database for MySQL. Nie można przekształcić istniejącego serwera w replikę. 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 dla 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ą replikowani 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 z AUTO_INCREMENT jako kluczem podstawowym 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ę z bazy i zmień jej nazwę w źródle danych; Takie podejście nie wymaga usunięcia serwera repliki, jednak może to wymagać dużych kosztów wstawiania danych w celu utworzenia tabeli kopii zapasowej. — Utwórz ponownie replikę po dodaniu wszystkich kolumn automatycznego przyrostu.
Inne	— Tworzenie kopii repliki nie jest możliwe. — 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ść

• Tworzenie replik do odczytu i zarządzanie nimi przy użyciu witryny Azure Portal
• Tworzenie replik do odczytu i zarządzanie nimi przy użyciu interfejsu wiersza polecenia platformy Azure