Replikowanie danych do usługi Azure Database for MySQL — elastyczny serwer

  • Artykuł

DOTYCZY: Azure Database for MySQL — serwer elastyczny

Replikacja typu data-in umożliwia synchronizowanie danych z zewnętrznego serwera MySQL z elastycznym wystąpieniem serwera usługi Azure Database for MySQL. Serwer zewnętrzny może być lokalny, na maszynach wirtualnych, pojedynczym serwerze usługi Azure Database for MySQL lub usłudze bazy danych hostowanej przez innych dostawców usług w chmurze. Replikacja typu data-in jest oparta na pozycji pliku dziennika binarnego (binlog) lub replikacji opartej na identyfikatorze GTID. Aby dowiedzieć się więcej na temat replikacji binlog, zobacz Replikacja bazy danych MySQL.

Uwaga

Konfigurowanie replikacji danych dla serwerów z włączoną wysoką dostępnością jest obsługiwane tylko za pośrednictwem replikacji opartej na identyfikatorze GTID.

Kiedy należy używać replikacji typu data-in

Główne scenariusze, które należy wziąć pod uwagę podczas korzystania z replikacji typu data-in, to:

  • Synchronizacja danych hybrydowych: dzięki replikacji typu data-in można zachować synchronizację danych między serwerami lokalnymi i elastycznym serwerem usługi Azure Database for MySQL. Ta synchronizacja ułatwia tworzenie aplikacji hybrydowych. Ta metoda jest atrakcyjna, gdy masz istniejący lokalny serwer bazy danych, ale chcesz przenieść dane do regionu bliżej użytkowników końcowych.
  • Synchronizacja z wieloma chmurami: w przypadku złożonych rozwiązań w chmurze użyj replikacji typu data-in, aby synchronizować dane między elastycznym serwerem usługi Azure Database for MySQL i różnymi dostawcami usług w chmurze, w tym maszynami wirtualnymi i usługami baz danych hostowanymi w tych chmurach.
  • Migracja: klienci mogą migrować w minimalnym czasie przy użyciu narzędzi typu open source, takich jak MyDumper/MyLoader z replikacją typu data-in. Selektywne przecięcie obciążenia produkcyjnego ze źródłowej do docelowej bazy danych jest możliwe w przypadku replikacji typu data-in.

W przypadku scenariuszy migracji użyj usługi Azure Database Migration Service (DMS).

Ograniczenia i istotne zagadnienia

Dane nie są replikowane

Systemowa baza danych mysql na serwerze źródłowym nie jest replikowana. Ponadto zmiany kont i uprawnień na serwerze źródłowym nie są replikowane. Jeśli utworzysz konto na serwerze źródłowym i to konto musi uzyskać dostęp do serwera repliki, ręcznie utwórz to samo konto na serwerze repliki. Aby zrozumieć tabele w systemowej bazie danych, zobacz podręcznik MySQL.

Replikacja typu data-in jest obsługiwana na serwerach z obsługą 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_change_master_with_gtid.

Filtr

Parametr replicate_wild_ignore_table tworzy filtr replikacji dla tabel na serwerze repliki. Aby zmodyfikować ten parametr w witrynie Azure Portal, przejdź do wystąpienia serwera elastycznego usługi Azure Database for MySQL używanego jako replika i wybierz pozycję "Parametry serwera", aby wyświetlić/edytować replicate_wild_ignore_table parametr.

Wymagania

  • Wersja serwera źródłowego musi być co najmniej mySQL w wersji 5.7.
  • Naszym zaleceniem jest posiadanie tej samej wersji dla wersji serwera źródłowego i repliki. Na przykład oba muszą mieć wartość MySQL w wersji 5.7 lub oba muszą mieć wartość MySQL w wersji 8.0.
  • Naszym zaleceniem jest posiadanie klucza podstawowego w każdej tabeli. Jeśli mamy tabelę bez klucza podstawowego, może wystąpić spowolnienie replikacji.
  • Serwer źródłowy powinien używać aparatu MySQL InnoDB.
  • Użytkownik musi mieć odpowiednie uprawnienia do konfigurowania rejestrowania binarnego i tworzenia nowych użytkowników na serwerze źródłowym.
  • Pliki dziennika binarnego na serwerze źródłowym nie powinny być czyszczone, zanim replika zastosuje te zmiany. Jeśli źródłem jest serwer elastyczny usługi Azure Database for MySQL, zapoznaj się z instrukcjami konfigurowania binlog_expire_logs_seconds dla serwera elastycznego lub pojedynczego serwera
  • Jeśli serwer źródłowy ma włączony protokół SSL, upewnij się, że certyfikat urzędu certyfikacji SSL podany dla domeny został uwzględniony w procedurze mysql.az_replication_change_master składowanej. Zapoznaj się z poniższymi przykładami i parametrem master_ssl_ca .
  • Upewnij się, że maszyna hostująca serwer źródłowy zezwala zarówno na ruch przychodzący, jak i wychodzący na porcie 3306.
  • W przypadku dostępu publicznego upewnij się, że serwer źródłowy ma publiczny adres IP, że system DNS jest publicznie dostępny lub że serwer źródłowy ma w pełni kwalifikowaną nazwę domeny (FQDN).
  • Dzięki dostępowi prywatnemu upewnij się, że nazwę serwera źródłowego można rozpoznać i jest dostępna z sieci wirtualnej, w której jest uruchomione wystąpienie serwera elastycznego usługi Azure Database for MySQL. (Aby uzyskać więcej informacji, odwiedź stronę Rozpoznawanie nazw zasobów w sieciach wirtualnych platformy Azure).

Wygenerowany niewidoczny klucz podstawowy

W przypadku programu MySQL w wersji 8.0 lub nowszej jest domyślnie włączona funkcja Generated Invisible Primary Keys (GIPK) dla wszystkich wystąpień serwera elastycznego usługi Azure Database for MySQL. Serwery MySQL 8.0 lub nowsze dodaje niewidoczną kolumnę my_row_id do tabel i klucza podstawowego w tej kolumnie, gdzie tabela InnoDB jest tworzona bez jawnego klucza podstawowego. Ta funkcja po włączeniu może mieć wpływ na niektóre przypadki użycia replikacji typu data-in, zgodnie z poniższym opisem:

  • Replikacja typu data-in kończy się niepowodzeniem z powodu błędu replikacji: "BŁĄD 1068 (42000): Zdefiniowano wiele klucza podstawowego", jeśli serwer źródłowy tworzy klucz podstawowy w tabeli bez klucza podstawowego. W celu ograniczenia ryzyka uruchom następujące polecenie sql, pomiń błąd replikacji i uruchom ponownie replikację danych.

    alter table <table name> drop column my_row_id, add primary key <primary key name>(<column name>);

  • Replikacja typu data-in kończy się niepowodzeniem z powodu błędu replikacji: "BŁĄD 1075 (42000): Nieprawidłowa definicja tabeli; Może istnieć tylko jedna kolumna automatyczna i musi być zdefiniowana jako klucz", jeśli serwer źródłowy dodaje kolumnę auto_increment jako unikatowy klucz. W celu ograniczenia ryzyka uruchom następujące polecenie SQL, ustaw wartość "sql_generate_invisible_primary_key" na wartość WYŁ., pomiń błąd replikacji i ponownie uruchom replikację danych.

    alter table <table name> drop column my_row_id, modify <column name> int auto_increment;

  • Replikacja typu data-in kończy się niepowodzeniem, jeśli serwer źródłowy uruchamia inny program SQL, który nie jest obsługiwany, gdy "sql_generate_invisible_primary_key" jest włączony. Na przykład utwórz tabelę partycji. W takim scenariuszu środki zaradcze należy ustawić wartość "sql_generate_invisible_primary_key" jako WYŁ. i ponownie uruchomić replikację typu data-in.

Następne kroki