Share via

Konfigurowanie replikacji danych w usłudze Azure Database for MariaDB

  • Artykuł

Ważne

Usługa Azure Database for MariaDB znajduje się na ścieżce wycofania. Zdecydowanie zalecamy przeprowadzenie migracji do usługi Azure Database for MySQL. Aby uzyskać więcej informacji na temat migracji do usługi Azure Database for MySQL, zobacz Co się dzieje z usługą Azure Database for MariaDB?.

W tym artykule opisano sposób konfigurowania replikacji danych w usłudze Azure Database for MariaDB 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 MariaDB.

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

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

Uwaga

Jeśli serwer źródłowy jest w wersji 10.2 lub nowszej, zalecamy skonfigurowanie replikacji danych przy użyciu globalnego identyfikatora transakcji.

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.

Tworzenie serwera MariaDB do użycia jako replika

  1. Utwórz nowy serwer usługi Azure Database for MariaDB (na przykład replica.mariadb.database.azure.com). Serwer jest serwerem repliki w replikacji typu data-in.

    Aby dowiedzieć się więcej na temat tworzenia serwera, zobacz Tworzenie serwera usługi Azure Database for MariaDB przy użyciu witryny Azure Portal.

    Ważne

    Musisz utworzyć serwer usługi Azure Database for MariaDB w warstwach cenowych Ogólnego przeznaczenia lub Zoptymalizowane pod kątem pamięci.

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

    Konta użytkowników nie są replikowane z serwera źródłowego do serwera repliki. Aby zapewnić użytkownikowi dostęp do serwera repliki, należy ręcznie utworzyć wszystkie konta i odpowiednie uprawnienia na nowo utworzonym serwerze usługi Azure Database for MariaDB.

  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.

Konfigurowanie serwera źródłowego

Poniższe kroki umożliwiają przygotowanie i skonfigurowanie serwera MariaDB hostowanego lokalnie, na maszynie wirtualnej lub w usłudze bazy danych w chmurze na potrzeby replikacji typu data-in. Serwer MariaDB jest źródłem replikacji typu data-in.

  1. Przed kontynuowaniem zapoznaj się z podstawowymi wymaganiami serwera.

  2. Upewnij się, że serwer źródłowy zezwala zarówno na ruch przychodzący, jak i wychodzący na porcie 3306, a serwer źródłowy ma publiczny adres IP, system DNS jest publicznie dostępny lub 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 usługi Azure Database for MariaDB.

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

    2. Wykonaj poniższe zapytanie.

      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. Wykonaj poniższe polecenie w narzędziu ping, aby uzyskać adres IP.

      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.

    Aby sprawdzić, czy rejestrowanie binarne jest włączone w lokalizacji podstawowej, wprowadź następujące polecenie:

    SHOW VARIABLES LIKE 'log_bin';

    Jeśli zmienna log_bin zwraca wartość ON, rejestrowanie binarne jest włączone na serwerze.

    Jeśli log_bin zwraca wartość OFF, zmodyfikuj plik my.cnf , aby log_bin=ON włączyć rejestrowanie binarne. Uruchom ponownie serwer, aby wprowadzić zmiany.

  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. Parametr lower_case_table_names jest domyślnie 1 ustawiony w usłudze Azure Database for MariaDB.

    SET GLOBAL lower_case_table_names = 1;

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

    Utwórz konto użytkownika na serwerze źródłowym skonfigurowanym z uprawnieniami replikacji. Konto można utworzyć przy użyciu poleceń SQL lub programu MySQL Workbench. Jeśli planujesz replikowanie przy użyciu protokołu SSL, musisz określić to podczas tworzenia konta użytkownika.

    Aby dowiedzieć się, jak dodać konta użytkowników na serwerze źródłowym, zobacz dokumentację bazy danych MariaDB.

    Korzystając z następujących poleceń, nowa rola replikacji może uzyskać dostęp do źródła z dowolnej maszyny, a nie tylko maszyny, która hostuje samo źródło. W przypadku tego dostępu określ syncuser@ '%' w poleceniu, aby utworzyć użytkownika.

    Aby dowiedzieć się więcej na temat dokumentacji bazy danych MariaDB, zobacz określanie nazw kont.

    Polecenie SQL

    • Replikacja przy użyciu protokołu SSL

      Aby wymagać protokołu SSL dla wszystkich połączeń użytkownika, wprowadź następujące polecenie, 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ń, wprowadź następujące polecenie, 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, w okienku Zarządzanie wybierz pozycję Użytkownicy i uprawnienia. Następnie wybierz pozycję Dodaj konto.

    Users and Privileges

    Wprowadź nazwę użytkownika w polu Nazwa logowania.

    Sync user

    Wybierz panel role Administracja istracyjne, a następnie na liście Uprawnień globalnych wybierz pozycję Podrzędny replikacji. Wybierz pozycję Zastosuj , aby utworzyć rolę replikacji.

    Replication Slave

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

    Przed zrzutem bazy danych serwer musi zostać umieszczony w trybie tylko do odczytu. W trybie tylko do odczytu źródło nie może przetworzyć żadnych transakcji zapisu. Aby uniknąć wpływu na działalność biznesową, zaplanuj okno tylko do odczytu w czasie poza szczytem.

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

  7. Pobierz bieżącą nazwę pliku dziennika binarnego i przesunięcie.

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

    show master status;

    Wyniki powinny być podobne do poniższej tabeli:

    Master Status Results

    Zanotuj nazwę pliku binarnego, ponieważ będzie on używany w kolejnych krokach.

  8. Pobierz pozycję GTID (opcjonalnie wymaganą do replikacji za pomocą identyfikatora GTID).

    Uruchom funkcję BINLOG_GTID_POS , aby uzyskać pozycję GTID dla odpowiedniej nazwy pliku binlog i przesunięcia.

    select BINLOG_GTID_POS('<binlog file name>', <binlog offset>);

Zrzut i przywracanie serwera źródłowego

  1. Zrzuć wszystkie bazy danych z serwera źródłowego.

    Użyj narzędzia mysqldump, aby zrzucić wszystkie bazy danych z serwera źródłowego. Nie jest konieczne zrzut biblioteki MySQL i biblioteki testowej.

    Aby uzyskać więcej informacji, zobacz Zrzut i przywracanie.

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

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

    SET GLOBAL read_only = OFF;
UNLOCK TABLES;

  3. Przywróć plik zrzutu na nowy serwer.

    Przywróć plik zrzutu na serwer utworzony w usłudze Azure Database for MariaDB. Zobacz Zrzuty i przywracanie , aby dowiedzieć się, jak przywrócić plik zrzutu na serwer MariaDB.

    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 MariaDB z maszyny wirtualnej.

  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 DB for MariaDB. Następnie ustaw wystąpienie zewnętrzne jako serwer źródłowy przy użyciu mysql.az_replication_change_master procedury składowanej lub mysql.az_replication_change_master_with_gtid na serwerze usługi Azure DB for MariaDB.

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

    lub

    CALL mysql.az_replication_change_master_with_gtid('<master_host>', '<master_user>', '<master_password>', 3306, '<master_gtid_pos>', '<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_log_file: nazwa pliku dziennika binarnego z uruchomionego show master status
    • master_log_pos: pozycja dziennika binarnego z uruchamiania show master status
    • master_gtid_pos: pozycja GTID od uruchomienia select BINLOG_GTID_POS('<binlog file name>', <binlog offset>);
    • master_ssl_ca: kontekst certyfikatu urzędu certyfikacji. Jeśli nie używasz protokołu SSL, przekaż pusty ciąg.*

    *Zalecamy przekazanie parametru master_ssl_ca jako zmiennej. Aby uzyskać więcej informacji, zobacz następujące przykłady.

    Przykłady

    • Replikacja przy użyciu protokołu SSL

      Utwórz zmienną @cert , uruchamiając następujące polecenia:

      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 companya.com domeny i serwerem repliki hostowanym w usłudze Azure Database for MariaDB. Ta procedura składowana jest uruchamiana w repliki.

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

    • Replikacja bez protokołu SSL

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

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

  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;

    Jeśli Slave_IO_Running parametr i Slave_SQL_Running znajduje się w stanie yes, a wartość parametru Seconds_Behind_Master to 0, replikacja działa. Seconds_Behind_Master wskazuje, jak późno jest replika. Jeśli wartość nie 0jest wartością , replika przetwarza aktualizacje.

  4. Zaktualizuj odpowiednie zmienne serwera, aby zapewnić bezpieczniejsze replikację typu data-in (wymagana tylko do replikacji bez identyfikatora GTID).

    Ze względu na ograniczenie replikacji natywnej w usłudze MariaDB należy ustawić sync_master_info zmienne i sync_relay_log_info replikacji bez scenariusza GTID.

    Sprawdź zmienne i sync_relay_log_info zmienne serwera sync_master_info repliki, aby upewnić się, że replikacja danych jest stabilna i ustaw zmienne na 1.

Inne procedury składowane

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 i repliką, użyj następującej procedury składowanej:

CALL mysql.az_replication_remove_master;

Pomiń błąd replikacji

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

CALL mysql.az_replication_skip_counter;

Następne kroki

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