Udostępnij za pośrednictwem

Jak skonfigurować replikację danych usługi Azure Database for MySQL — serwer elastyczny

  • Artykuł

DOTYCZY: Azure Database for MySQL — serwer elastyczny

W tym artykule opisano sposób konfigurowania replikacji typu data-in na serwerze elastycznym usługi 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 wystąpieniu serwera elastycznego usługi 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 można skonfigurować przy użyciu replikacji opartej na pozycji pliku dziennika binarnego (binlog) lub replikacji opartej na gtID. Aby dowiedzieć się więcej na temat replikacji binlog, zobacz Replikacja bazy danych MySQL.

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

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

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

  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 w tym nowo utworzonym wystąpieniu serwera elastycznego usługi Azure Database for MySQL.

Konfigurowanie źródłowego serwera MySQL

Poniższe kroki umożliwiają przygotowanie i skonfigurowanie serwera MySQL hostowanego lokalnie, na maszynie wirtualnej lub w usłudze bazy danych hostowanej przez innych dostawców chmury 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. Wymagania dotyczące sieci

    • 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).

    • Jeśli jest używany dostęp prywatny (integracja z siecią wirtualną), upewnij się, że masz łączność między serwerem źródłowym a siecią wirtualną, w której jest hostowany serwer repliki.

    • Upewnij się, że zapewniamy łączność typu lokacja-lokacja z lokalnymi serwerami źródłowymi przy użyciu usługi ExpressRoute lub sieci VPN. Aby uzyskać więcej informacji na temat tworzenia sieci wirtualnej, zobacz dokumentację sieci wirtualnej, a zwłaszcza artykuły Szybki start ze szczegółowymi informacjami krok po kroku.

    • Jeśli dostęp prywatny (integracja z siecią wirtualną) jest używany na serwerze repliki, a źródłem jest maszyna wirtualna platformy Azure, upewnij się, że nawiązana jest łączność między sieciami wirtualnymi. Komunikacja równorzędna sieci wirtualnych jest obsługiwana. Można również użyć innych metod łączności do komunikacji między sieciami wirtualnymi w różnych regionach, takich jak połączenie sieci wirtualnej z siecią wirtualną. Aby uzyskać więcej informacji, zobacz Brama sieci VPN między sieciami wirtualnymi

    • Upewnij się, że reguły sieciowej grupy zabezpieczeń sieci wirtualnej nie blokują portu wychodzącego 3306 (również dla ruchu przychodzącego, jeśli na maszynie wirtualnej platformy Azure działa program MySQL). Aby uzyskać więcej informacji na temat filtrowania ruchu sieciowej grupy zabezpieczeń sieci wirtualnej, zapoznaj się z artykułem Filtrowanie ruchu sieciowego przy użyciu sieciowych grup zabezpieczeń.

    • Skonfiguruj reguły zapory serwera źródłowego, aby zezwolić na adres IP serwera repliki.

  3. Wykonaj odpowiednie kroki w oparciu o to, czy chcesz użyć pozycji bin-log lub replikacji opartej na danych GTID.

    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 jest zwracana 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ć następujące 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 usługę MySQL na serwerze źródłowym (lub uruchom ponownie), 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 na serwerze elastycznym usługi Azure Database for MySQL.

    SET GLOBAL lower_case_table_names = 1;

  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.

    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'@'%';

  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.

    Wyniki stanu wzorca

Zrzut i przywracanie serwera źródłowego

  1. Ustal, które bazy danych i tabele chcesz replikować do elastycznego serwera 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. 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;

    Uwaga

    Zanim serwer zostanie ustawiony z powrotem na tryb odczytu/zapisu, możesz pobrać informacje GTID przy użyciu GTID_EXECUTED zmiennej globalnej. Zostanie on użyty na późniejszym etapie, aby ustawić identyfikator GTID na serwerze repliki.

  3. Przywróć plik zrzutu na nowy serwer.

    Przywróć plik zrzutu na serwerze utworzonym na serwerze elastycznym usługi 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óć je do wystąpienia serwera elastycznego usługi Azure Database for MySQL z maszyny wirtualnej.

Uwaga

Jeśli chcesz uniknąć ustawiania bazy danych na odczyt tylko podczas zrzutu i przywracania, możesz użyć narzędzia mydumper/myloader.

Ustawianie identyfikatora GTID na serwerze repliki

  1. Pomiń krok, jeśli używasz replikacji opartej na pozycji bin-log

  2. Informacje GTID z pliku zrzutu pobranego ze źródła są wymagane do zresetowania historii GTID serwera docelowego (repliki).

  3. Użyj tych informacji GTID ze źródła, aby wykonać resetowanie GTID na serwerze repliki za pomocą następującego polecenia interfejsu wiersza polecenia:

    az mysql flexible-server gtid reset --resource-group  <resource group> --server-name <replica server name> --gtid-set <gtid set from the source server> --subscription <subscription id>

Aby uzyskać więcej informacji, zobacz Resetowanie identyfikatora GTID.

Uwaga

Nie można wykonać resetowania identyfikatora GTID na serwerze z włączoną nadmiarowością geograficzną. Wyłącz nadmiarowość geograficzną, aby przeprowadzić resetowanie identyfikatora GTID na serwerze. Po zresetowaniu identyfikatora GTID można ponownie włączyć opcję nadmiarowości geograficznej. Akcja resetowania identyfikatora GTID unieważnia wszystkie dostępne kopie zapasowe i dlatego po ponownym włączeniu nadmiarowości geograficznej przywracanie geograficzne może potrwać dzień przed wykonaniem przywracania geograficznego na serwerze

  1. Ustaw serwer źródłowy.

    Wszystkie funkcje replikacji typu data-in są wykonywane przez procedury składowane. Wszystkie procedury można znaleźć w artykule Data-in replication Stored Procedures (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 lub mysql.az_replication_change_master_with_gtid 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>');

    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, zapoznaj się z poniższymi przykładami.

    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łączenia. Aby uzyskać więcej informacji, zobacz Zarządzanie regułami zapory przy użyciu portalu.
    • Jeśli użyto narzędzia mydumper/myloader do zrzutu bazy danych, możesz pobrać master_log_file i master_log_pos z pliku /backup/metadata .

    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 na serwerze elastycznym usługi 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);

    CALL mysql.az_replication_change_master_with_gtid('master.companya.com', 'syncuser', 'P@ssword!', 3306, @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 na serwerze elastycznym usługi 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, '');

    CALL mysql.az_replication_change_master_with_gtid('master.companya.com', 'syncuser', 'P@ssword!', 3306, '');

  2. Uruchom replikację.

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

    CALL mysql.az_replication_start;

  3. Sprawdź stan replikacji.

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

    show slave status;

    Aby poznać prawidłowy stan replikacji, zapoznaj się z metrykami replikacji — Stan operacji we/wy repliki i Stan bazy danych SQL repliki na stronie monitorowania.

    Jeśli parametr Seconds_Behind_Master ma wartość "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 typu data-in

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;

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

Pokaż wyniki dziennika binarnego

Następne kroki

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