Udostępnij za pośrednictwem

Jak skonfigurować replikację danych usługi 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?

W tym artykule opisano sposób konfigurowania replikacji danych w usłudze Azure Database for MySQL przez skonfigurowanie serwerów źródłowych i replik. W tym artykule założono, że masz pewne wcześniejsze doświadczenie z serwerami i bazami danych 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.

Aby utworzyć replikę w usłudze Azure Database for MySQL, replikacja typu data-in synchronizuje dane ze źródłowego serwera MySQL lokalnie, na maszynach wirtualnych lub w usługach bazy danych w chmurze. Replikacja typu data-in jest oparta na pliku dziennika binarnego (binlog) opartego na pozycji lub replikacji opartej na gtID natywnej dla bazy danych MySQL. Aby dowiedzieć się więcej na temat replikacji binlog, zobacz Omówienie replikacji dziennika binlogu MySQL.

Przed wykonaniem kroków opisanych w tym artykule zapoznaj się z ograniczeniami i wymaganiami replikacji typu data-in.

Tworzenie pojedynczego wystąpienia serwera usługi Azure Database for MySQL do użycia jako replika

  1. Utwórz nowe wystąpienie pojedynczego serwera usługi Azure Database for MySQL (na przykład replica.mysql.database.azure.com). Zobacz Tworzenie serwera usługi Azure Database for MySQL przy użyciu witryny Azure Portal w celu utworzenia serwera. Ten serwer jest serwerem "repliki" dla replikacji typu data-in.

    Ważne

    Serwer usługi Azure Database for MySQL musi zostać utworzony w warstwach cenowych Ogólnego przeznaczenia lub Zoptymalizowane pod kątem pamięci, ponieważ replikacja typu data-in jest obsługiwana tylko w tych warstwach. 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).

  2. Utwórz te same konta użytkowników i odpowiednie uprawnienia.

    Konta użytkowników nie są replikowane z serwera źródłowego do serwera repliki. Jeśli planujesz zapewnić użytkownikom dostęp do serwera repliki, musisz ręcznie utworzyć wszystkie konta i odpowiednie uprawnienia na tym nowo utworzonym serwerze usługi Azure Database for MySQL.

  3. Dodaj adres IP serwera źródłowego do reguł zapory repliki.

    Zaktualizuj reguły zapory za pomocą witryny Azure Portal lub interfejsu wiersza polecenia platformy Azure.

  4. Opcjonalnie — jeśli chcesz użyć replikacji opartej na identyfikatorze GTID z serwera źródłowego do serwera repliki usługi Azure Database for MySQL, musisz włączyć następujące parametry serwera na serwerze usługi Azure Database for MySQL, jak pokazano na poniższej ilustracji portalu:

    Enable GTID on Azure Database for MySQL server

Konfigurowanie źródłowego serwera MySQL

Poniższe kroki umożliwiają przygotowanie i skonfigurowanie serwera MySQL hostowanego lokalnie na maszynie wirtualnej lub usłudze bazy danych hostowanej przez innych dostawców usług w chmurze na potrzeby replikacji typu data-in. Ten serwer jest "źródłem" replikacji typu data-in.

  1. Przed kontynuowaniem przejrzyj wymagania dotyczące serwera źródłowego.

  2. Upewnij się, że serwer źródłowy zezwala zarówno na ruch przychodzący, jak i wychodzący na porcie 3306 oraz że ma publiczny adres IP, system DNS jest publicznie dostępny lub że ma w pełni kwalifikowaną nazwę domeny (FQDN).

    Przetestuj łączność z serwerem źródłowym, próbując nawiązać połączenie z poziomu narzędzia, takiego jak wiersz polecenia MySQL hostowany na innej maszynie lub z usługi Azure Cloud Shell dostępnej w witrynie Azure Portal.

    Jeśli twoja organizacja ma ścisłe zasady zabezpieczeń i nie zezwoli wszystkim adresom IP na serwerze źródłowym na włączenie komunikacji z platformy Azure do serwera źródłowego, możesz potencjalnie użyć poniższego polecenia, aby określić adres IP serwera MySQL.

    1. Zaloguj się do serwera usługi Azure Database for MySQL przy użyciu narzędzia, takiego jak wiersz polecenia MySQL.

    2. Wykonaj następujące zapytanie.

      mysql> SELECT @@global.redirect_server_host;

      Poniżej przedstawiono przykładowe dane wyjściowe:

      +-----------------------------------------------------------+
| @@global.redirect_server_host                             |
+-----------------------------------------------------------+
| e299ae56f000.tr1830.westus1-a.worker.database.windows.net |
 +-----------------------------------------------------------+

    3. Wyjdź z wiersza polecenia MySQL.

    4. Aby uzyskać adres IP, wykonaj następujące polecenie w narzędziu ping:

      ping <output of step 2b>

      Na przykład:

      C:\Users\testuser> ping e299ae56f000.tr1830.westus1-a.worker.database.windows.net
Pinging tr1830.westus1-a.worker.database.windows.net (**11.11.111.111**) 56(84) bytes of data.

    5. Skonfiguruj reguły zapory serwera źródłowego, aby uwzględnić wyjściowy adres IP poprzedniego kroku na porcie 3306.

      Uwaga

      Ten adres IP może ulec zmianie z powodu operacji konserwacji/wdrażania. Ta metoda łączności dotyczy tylko klientów, którzy nie mogą sobie pozwolić na zezwolenie na cały adres IP na porcie 3306.

  3. Włącz rejestrowanie binarne.

    Sprawdź, czy rejestrowanie binarne zostało włączone w źródle, uruchamiając następujące polecenie:

    SHOW VARIABLES LIKE 'log_bin';

    Jeśli zmienna log_bin jest zwracana z wartością "WŁ.", rejestrowanie binarne jest włączone na serwerze.

    Jeśli log_bin zostanie zwrócona wartość "OFF", a serwer źródłowy działa lokalnie lub na maszynach wirtualnych, na których można uzyskać dostęp do pliku konfiguracji (my.cnf), możesz wykonać poniższe kroki:

    1. Znajdź plik konfiguracji MySQL (my.cnf) na serwerze źródłowym. Na przykład: /etc/my.cnf

    2. Otwórz plik konfiguracji, aby go edytować i znajdź sekcję mysqld w pliku.

    3. W sekcji mysqld dodaj następujący wiersz:

      log-bin=mysql-bin.log

    4. Uruchom ponownie serwer źródłowy MySQL, aby zmiany zaczęły obowiązywać.

    5. Po ponownym uruchomieniu serwera sprawdź, czy rejestrowanie binarne jest włączone, uruchamiając to samo zapytanie co poprzednio:

      SHOW VARIABLES LIKE 'log_bin';

  4. Skonfiguruj ustawienia serwera źródłowego.

    Replikacja typu data-in wymaga, aby parametr lower_case_table_names był spójny między serwerami źródłowymi i replikami. Ten parametr jest domyślnie 1 w usłudze Azure Database for MySQL.

    SET GLOBAL lower_case_table_names = 1;

    Opcjonalnie — jeśli chcesz użyć replikacji opartej na identyfikatorze GTID, musisz sprawdzić, czy identyfikator GTID jest włączony na serwerze źródłowym. Możesz wykonać następujące polecenie względem źródłowego serwera MySQL, aby sprawdzić, czy gtid_mode jest włączona.

    show variables like 'gtid_mode';

    Ważne

    Wszystkie serwery mają gtid_mode ustawione na wartość domyślną OFF. Nie musisz włączać identyfikatora GTID na źródłowym serwerze MySQL, aby skonfigurować replikację typu data-in. Jeśli identyfikator GTID jest już włączony na serwerze źródłowym, opcjonalnie możesz użyć replikacji opartej na identyfikatorze GTID, aby skonfigurować replikację typu data-in zbyt za pomocą pojedynczego serwera usługi Azure Database for MySQL. Replikacja oparta na plikach umożliwia skonfigurowanie replikacji danych dla wszystkich serwerów niezależnie od konfiguracji gitd_mode na serwerze źródłowym.

  5. Utwórz nową rolę replikacji i skonfiguruj uprawnienie.

    Utwórz konto użytkownika na serwerze źródłowym skonfigurowanym z uprawnieniami replikacji. Można to zrobić za pomocą poleceń SQL lub narzędzia, takiego jak MySQL Workbench. Zastanów się, czy planujesz replikowanie przy użyciu protokołu SSL, ponieważ będzie to konieczne podczas tworzenia użytkownika. Zapoznaj się z dokumentacją programu MySQL, aby dowiedzieć się, jak dodawać konta użytkowników na serwerze źródłowym.

    W poniższych poleceniach nowa utworzona rola replikacji może uzyskiwać dostęp do źródła z dowolnej maszyny, a nie tylko maszyny, która hostuje samo źródło. W tym celu należy określić wartość "syncuser@'%'" w poleceniu tworzenia użytkownika. Zapoznaj się z dokumentacją programu MySQL, aby dowiedzieć się więcej na temat określania nazw kont.

    Polecenie SQL

    Replikacja przy użyciu protokołu SSL

    Aby wymagać protokołu SSL dla wszystkich połączeń użytkowników, użyj następującego polecenia, aby utworzyć użytkownika:

    CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
GRANT REPLICATION SLAVE ON *.* TO 'syncuser'@'%' REQUIRE SSL;

    Replikacja bez protokołu SSL

    Jeśli protokół SSL nie jest wymagany dla wszystkich połączeń, użyj następującego polecenia, aby utworzyć użytkownika:

    CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
GRANT REPLICATION SLAVE ON *.* TO 'syncuser'@'%';

    MySQL Workbench

    Aby utworzyć rolę replikacji w aplikacji MySQL Workbench, otwórz panel Użytkownicy i uprawnienia z panelu Zarządzanie , a następnie wybierz pozycję Dodaj konto.

    Users and Privileges

    Wpisz nazwę użytkownika w polu Nazwa logowania.

    Sync user

    Wybierz panel role Administracja istracyjne, a następnie wybierz pozycję Replikacja podrzędna z listy Uprawnień globalnych. Następnie wybierz pozycję Zastosuj , aby utworzyć rolę replikacji.

    Replication Slave

  6. Ustaw serwer źródłowy na tryb tylko do odczytu.

    Przed rozpoczęciem zrzutu bazy danych należy umieścić serwer w trybie tylko do odczytu. W trybie tylko do odczytu źródło nie będzie mogło przetworzyć żadnych transakcji zapisu. W razie potrzeby oceń wpływ na firmę i zaplanuj okno tylko do odczytu poza godziną szczytu.

    FLUSH TABLES WITH READ LOCK;
SET GLOBAL read_only = ON;

  7. Pobierz nazwę pliku dziennika binarnego i przesunięcie.

    Uruchom polecenie , show master status aby określić bieżącą nazwę pliku dziennika binarnego i przesunięcie.

     show master status;

    Wyniki powinny wyglądać podobnie do poniższych. Pamiętaj, aby zanotować nazwę pliku binarnego do użycia w kolejnych krokach.

    Master Status Results

Zrzut i przywracanie serwera źródłowego

  1. Ustal, które bazy danych i tabele chcesz replikować do usługi Azure Database for MySQL, i wykonaj zrzut z serwera źródłowego.

    Do zrzutu baz danych z serwera podstawowego można użyć narzędzia mysqldump. Aby uzyskać szczegółowe informacje, zobacz Zrzut i przywracanie. Nie trzeba zrzucić biblioteki MySQL i biblioteki testowej.

  2. Opcjonalnie — jeśli chcesz użyć replikacji opartej na gtid, musisz zidentyfikować identyfikator GTID ostatniej transakcji wykonanej w lokalizacji podstawowej. Zanotuj identyfikator GTID ostatniej transakcji wykonanej na serwerze głównym za pomocą następującego polecenia.

    show global variables like 'gtid_executed';

  3. Ustaw serwer źródłowy na tryb odczytu/zapisu.

    Po cenach dumpingowych bazy danych zmień źródłowy serwer MySQL z powrotem na tryb odczytu/zapisu.

    SET GLOBAL read_only = OFF;
UNLOCK TABLES;

  4. Przywróć plik zrzutu na nowy serwer.

    Przywróć plik zrzutu na serwer utworzony w usłudze Azure Database for MySQL. Zobacz Zrzut i przywracanie, aby dowiedzieć się, jak przywrócić plik zrzutu na serwer MySQL. Jeśli plik zrzutu jest duży, przekaż go do maszyny wirtualnej na platformie Azure w tym samym regionie co serwer repliki. Przywróć go na serwerze usługi Azure Database for MySQL z maszyny wirtualnej.

  5. Opcjonalnie — zwróć uwagę na identyfikator GTID przywróconego serwera w usłudze Azure Database for MySQL, aby upewnić się, że jest on taki sam jak serwer podstawowy. Zanotuj identyfikator GTID przeczyszczonej wartości GTID na serwerze repliki usługi Azure Database for MySQL za pomocą następującego polecenia. Wartość gtid_purged powinna być taka sama jak gtid_executed na serwerze głównym zanotowany w kroku 2, aby replikacja oparta na identyfikatorze GTID działała.

    show global variables like 'gtid_purged';

  1. Ustaw serwer źródłowy.

    Wszystkie funkcje replikacji typu data-in są wykonywane przez procedury składowane. Wszystkie procedury można znaleźć w temacie Procedury składowane replikacji danych. Procedury składowane można uruchamiać w powłoce MySQL lub w aplikacji MySQL Workbench.

    Aby połączyć dwa serwery i rozpocząć replikację, zaloguj się do docelowego serwera repliki w usłudze Azure Database for MySQL i ustaw wystąpienie zewnętrzne jako serwer źródłowy. Odbywa się to przy użyciu mysql.az_replication_change_master procedury składowanej na serwerze usługi Azure Database for MySQL.

    CALL mysql.az_replication_change_master('<master_host>', '<master_user>', '<master_password>', <master_port>, '<master_log_file>', <master_log_pos>, '<master_ssl_ca>');

    Opcjonalnie — jeśli chcesz użyć replikacji opartej na gtid, musisz użyć następującego polecenia, aby połączyć dwa serwery

    call mysql.az_replication_change_master_with_gtid('<master_host>', '<master_user>', '<master_password>', <master_port>, '<master_ssl_ca>');

    • master_host: nazwa hosta serwera źródłowego

    • master_user: nazwa użytkownika serwera źródłowego

    • master_password: hasło serwera źródłowego

    • master_port: numer portu, na którym serwer źródłowy nasłuchuje połączeń. (3306 to domyślny port, na którym nasłuchuje program MySQL)

    • master_log_file: nazwa pliku dziennika binarnego z uruchomionego show master status

    • master_log_pos: pozycja dziennika binarnego z uruchamiania show master status

    • master_ssl_ca: kontekst certyfikatu urzędu certyfikacji. Jeśli nie używasz protokołu SSL, przekaż pusty ciąg.

      Zaleca się przekazanie tego parametru jako zmiennej. Aby uzyskać więcej informacji, zobacz następujące przykłady.

    Uwaga

    Jeśli serwer źródłowy jest hostowany na maszynie wirtualnej platformy Azure, ustaw wartość "Zezwalaj na dostęp do usług platformy Azure", aby umożliwić serwerom źródłowym i replikom komunikowanie się ze sobą. To ustawienie można zmienić z opcji zabezpieczeń Połączenie ion. Aby uzyskać więcej informacji, zobacz Zarządzanie regułami zapory przy użyciu portalu .

    Przykłady

    Replikacja przy użyciu protokołu SSL

    Zmienna @cert jest tworzona przez uruchomienie następujących poleceń MySQL:

    SET @cert = '-----BEGIN CERTIFICATE-----
PLACE YOUR PUBLIC KEY CERTIFICATE'`S CONTEXT HERE
-----END CERTIFICATE-----'

    Replikacja przy użyciu protokołu SSL jest konfigurowana między serwerem źródłowym hostowanym w domenie "companya.com" i serwerem repliki hostowanym w usłudze Azure Database for MySQL. Ta procedura składowana jest uruchamiana w repliki.

    CALL mysql.az_replication_change_master('master.companya.com', 'syncuser', 'P@ssword!', 3306, 'mysql-bin.000002', 120, @cert);

    Replikacja bez protokołu SSL

    Replikacja bez protokołu SSL jest konfigurowana między serwerem źródłowym hostowanym w domenie "companya.com" i serwerem repliki hostowanym w usłudze Azure Database for MySQL. Ta procedura składowana jest uruchamiana w repliki.

    CALL mysql.az_replication_change_master('master.companya.com', 'syncuser', 'P@ssword!', 3306, 'mysql-bin.000002', 120, '');

  2. Skonfiguruj filtrowanie.

    Jeśli chcesz pominąć replikowanie niektórych tabel z serwera głównego, zaktualizuj replicate_wild_ignore_table parametr serwera na serwerze repliki. Można podać więcej niż jeden wzorzec tabeli przy użyciu listy rozdzielanej przecinkami.

    Zapoznaj się z dokumentacją programu MySQL, aby dowiedzieć się więcej na temat tego parametru.

    Aby zaktualizować parametr, możesz użyć witryny Azure Portal lub interfejsu wiersza polecenia platformy Azure.

  3. Uruchom replikację.

    Wywołaj procedurę składowaną, mysql.az_replication_start aby rozpocząć replikację.

    CALL mysql.az_replication_start;

  4. Sprawdź stan replikacji.

    Wywołaj show slave status polecenie na serwerze repliki, aby wyświetlić stan replikacji.

    show slave status;

    Jeśli stan parametru Slave_IO_Running i Slave_SQL_Running ma wartość "yes", a wartość Seconds_Behind_Master to "0", replikacja działa prawidłowo. Seconds_Behind_Master wskazuje, jak późno jest replika. Jeśli wartość nie jest "0", oznacza to, że replika przetwarza aktualizacje.

Inne przydatne procedury składowane dla operacji replikacji danych

Zatrzymywanie replikacji

Aby zatrzymać replikację między serwerem źródłowym a serwerem repliki, użyj następującej procedury składowanej:

CALL mysql.az_replication_stop;

Usuwanie relacji replikacji

Aby usunąć relację między serwerem źródłowym a serwerem repliki, użyj następującej procedury składowanej:

CALL mysql.az_replication_remove_master;

Błąd pominięcia replikacji

Aby pominąć błąd replikacji i zezwolić na kontynuowanie replikacji, użyj następującej procedury składowanej:

CALL mysql.az_replication_skip_counter;

Opcjonalnie — jeśli chcesz użyć replikacji opartej na gtid, użyj następującej procedury składowanej, aby pominąć transakcję

call mysql. az_replication_skip_gtid_transaction(‘<transaction_gtid>’)

Procedura może pominąć transakcję dla danego identyfikatora GTID. Jeśli format GTID nie jest prawidłowy lub transakcja GTID została już wykonana, wykonanie procedury zakończy się niepowodzeniem. Identyfikator GTID transakcji można określić przez przeanalizowanie dziennika binarnego w celu sprawdzenia zdarzeń transakcji. MySQL udostępnia narzędzie mysqlbinlog do analizowania dzienników binarnych i wyświetlania ich zawartości w formacie tekstowym, który może służyć do identyfikowania identyfikatora GTID transakcji.

Ważne

Ta procedura może służyć tylko do pomijania jednej transakcji i nie można jej użyć do pomijania zestawu gtid lub ustawiania gtid_purged.

Aby pominąć następną transakcję po bieżącej pozycji replikacji, użyj następującego polecenia, aby zidentyfikować identyfikator GTID następnej transakcji, jak pokazano poniżej.

SHOW BINLOG EVENTS [IN 'log_name'] [FROM pos][LIMIT [offset,] row_count]

Show binary log results

Następne kroki

  • Dowiedz się więcej o replikacji typu data-in dla usługi Azure Database for MySQL.