Migrowanie usługi Azure Database for MySQL — pojedynczy serwer do usługi Azure Database for MySQL — serwer elastyczny z narzędziami typu open source

Możesz przeprowadzić migrację wystąpienia usługi Azure Database for MySQL — pojedynczy serwer do usługi Azure Database for MySQL — serwer elastyczny z minimalnym przestojem w aplikacjach przy użyciu kombinacji narzędzi typu open source, takich jak mydumper/myloader i replikacja typu data-in.

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.

Replikacja typu data-in to technika, która replikuje zmiany danych z serwera źródłowego na serwer docelowy na podstawie metody położenia pliku dziennika binarnego. W tym scenariuszu wystąpienie programu MySQL działające jako źródło (z którego pochodzą zmiany bazy danych) zapisuje aktualizacje i zmienia się jako "zdarzenia" w dzienniku binarnym. Informacje w dzienniku binarnym są przechowywane w różnych formatach rejestrowania zgodnie ze zmianami w bazie danych rejestrowanymi. Repliki są skonfigurowane do odczytywania dziennika binarnego ze źródła i wykonywania zdarzeń w logowaniu binarnym lokalnej bazy danych repliki.

Jeśli skonfigurujesz replikację typu Data-in w celu synchronizowania danych z jednego wystąpienia usługi Azure Database for MySQL do innego, możesz przeprowadzić selektywne przecięcie aplikacji z podstawowej (lub źródłowej bazy danych) do repliki (lub docelowej bazy danych).

W tym samouczku użyjesz replikacji mydumper/myloader i data-in, aby przeprowadzić migrację przykładowej bazy danych (modelów klasycznych) z wystąpienia usługi Azure Database for MySQL — pojedynczy serwer do wystąpienia usługi Azure Database for MySQL — serwer elastyczny, a następnie zsynchronizować dane.

Z tego samouczka dowiesz się, jak wykonywać następujące czynności:

• Skonfiguruj ustawienia sieciowe na potrzeby replikacji typu data-in dla różnych scenariuszy.
• Skonfiguruj replikację typu data-in między repliką podstawową i repliką.
• Przetestuj replikację.
• Migracja jednorazowa w celu ukończenia migracji.

Wymagania wstępne

Do ukończenia tego samouczka niezbędne są następujące elementy:

• Wystąpienie pojedynczego serwera usługi Azure Database for MySQL w wersji 5.7 lub 8.0.

  Uwaga

  Jeśli używasz usługi Azure Database for MySQL — pojedynczy serwer w wersji 5.6, uaktualnij wystąpienie do wersji 5.7, a następnie skonfiguruj dane w replikacji. Aby dowiedzieć się więcej, zobacz Uaktualnianie wersji głównej w usłudze Azure Database for MySQL — pojedynczy serwer.

• Wystąpienie serwera elastycznego usługi Azure Database for MySQL. Aby uzyskać więcej informacji, zobacz artykuł Tworzenie wystąpienia w usłudze Azure Database for MySQL — serwer elastyczny.

  Uwaga

  Konfigurowanie replikacji danych dla strefowo nadmiarowych serwerów o wysokiej dostępności nie jest obsługiwane. Jeśli chcesz mieć strefowo nadmiarową wysoką dostępność dla serwera docelowego, wykonaj następujące kroki:

  1. Tworzenie serwera z włączoną strefowo nadmiarową wysoką dostępnością
  2. Wyłączanie wysokiej dostępności
  3. Postępuj zgodnie z artykułem, aby skonfigurować replikację typu data-in
  4. Po przejściu jednorazowym usuń konfigurację replikacji typu Data-in
  5. Włączanie wysokiej dostępności

  Upewnij się, że GTID_Mode ma to samo ustawienie na serwerach źródłowych i docelowych.

• Aby nawiązać połączenie i utworzyć bazę danych przy użyciu programu MySQL Workbench. Aby uzyskać więcej informacji, zobacz artykuł Use MySQL Workbench to connect and query data (Używanie aplikacji MySQL Workbench do nawiązywania połączeń i wykonywania zapytań o dane).

• Aby upewnić się, że masz maszynę wirtualną platformy Azure z systemem Linux w tym samym regionie (lub w tej samej sieci wirtualnej z dostępem prywatnym), która hostuje źródłowe i docelowe bazy danych.

• Aby zainstalować klienta mysql lub aplikację MySQL Workbench (narzędzia klienckie) na maszynie wirtualnej platformy Azure. Upewnij się, że można nawiązać połączenie z serwerem podstawowym i repliki. Na potrzeby tego artykułu jest instalowany klient mysql.

• Aby zainstalować narzędzie mydumper/myloader na maszynie wirtualnej platformy Azure. Aby uzyskać więcej informacji, zobacz artykuł mydumper/myloader.

• Aby pobrać i uruchomić przykładowy skrypt bazy danych dla bazy danych classicmodels na serwerze źródłowym.

• Skonfiguruj binlog_expire_logs_seconds na serwerze źródłowym, aby upewnić się, że dzienniki binlogów nie są czyszczone przed zatwierdzeniem zmian przez replikę. Po pomyślnym wycięciu możesz zresetować wartość.

Konfigurowanie wymagań dotyczących sieci

Aby skonfigurować replikację typu Data-in, należy upewnić się, że obiekt docelowy może nawiązać połączenie ze źródłem za pośrednictwem portu 3306. Na podstawie typu punktu końcowego skonfigurowanego w źródle wykonaj odpowiednie kroki.

• Jeśli publiczny punkt końcowy jest włączony w źródle, upewnij się, że obiekt docelowy może nawiązać połączenie ze źródłem, włączając opcję "Zezwalaj na dostęp do usług platformy Azure" w regule zapory. Aby dowiedzieć się więcej, zobacz Reguły zapory — Azure Database for MySQL.
• Jeśli prywatny punkt końcowy i Odmowa dostępu publicznego jest włączony w źródle, zainstaluj łącze prywatne w tej samej sieci wirtualnej, która hostuje obiekt docelowy. Aby dowiedzieć się więcej, zobacz Usługa Private Link — Azure Database for MySQL.

Konfigurowanie replikacji typu data-in

Aby skonfigurować dane w replikacji, wykonaj następujące kroki:

1. Zaloguj się do maszyny wirtualnej platformy Azure, na której zainstalowano narzędzie klienckie mysql.

2. Nawiąż połączenie ze źródłem i obiektem docelowym przy użyciu narzędzia klienckiego mysql.

3. Użyj narzędzia klienckiego mysql, aby określić, czy log_bin jest włączona w źródle, uruchamiając następujące polecenie:

   SHOW VARIABLES LIKE 'log_bin';
   

   Uwaga

   W przypadku pojedynczego serwera usługi Azure Database for MySQL z dużym magazynem, który obsługuje do 16 TB, ta opcja jest domyślnie włączona.

   Napiwek

   W przypadku usługi Azure Database for MySQL — pojedynczy serwer, który obsługuje maksymalnie 4 TB, nie jest to domyślnie włączone. Jeśli jednak podwyższysz poziom repliki do odczytu dla serwera źródłowego, a następnie usuniesz replikę do odczytu, parametr zostanie ustawiony na WŁ.

4. Na podstawie wymuszania protokołu SSL dla serwera źródłowego utwórz użytkownika na serwerze źródłowym z uprawnieniem replikacji, uruchamiając odpowiednie polecenie.

   Jeśli używasz protokołu SSL, uruchom następujące polecenie:

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

   Jeśli nie używasz protokołu SSL, uruchom następujące polecenie:

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

5. Aby utworzyć kopię zapasową bazy danych przy użyciu narzędzia mydumper, uruchom następujące polecenie na maszynie wirtualnej platformy Azure, na której zainstalowano mydumper\myloader:

   mydumper --host=<primary_server>.mysql.database.azure.com --user=<username>@<primary_server> --password=<password> --outputdir=./backup --rows=100000 -G -E -R -z --trx-consistency-only --compress --build-empty-files --threads=16 --compress-protocol --ssl  --regex '^(classicmodels\.)' -L mydumper-logs.txt
   

   Napiwek

   Opcja --trx-consistency-only jest wymagana dla spójności transakcyjnej podczas tworzenia kopii zapasowej.

   • Odpowiednik mydumper --single-transaction mysqldump.
   • Przydatne, jeśli wszystkie tabele są InnoDB.
   • Wątek "główny" musi przechowywać blokadę globalną tylko do momentu uruchomienia transakcji przez wątki "zrzut".
   • Oferuje najkrótszy czas trwania globalnego blokowania

   Wątek "główny" musi przechowywać blokadę globalną tylko do momentu uruchomienia transakcji przez wątki "zrzut".

   Zmienne w tym poleceniu zostały wyjaśnione poniżej:

   HOW-TO-MANAGE-FIREWALL-PORTAL --host: Nazwa serwera podstawowego

   • --user: nazwa użytkownika (w formacie username@servername ponieważ na serwerze podstawowym jest uruchomiona usługa Azure Database for MySQL — pojedynczy serwer). Możesz użyć administratora serwera lub użytkownika z uprawnieniami SELECT i RELOAD.
   • --Password: Hasło użytkownika powyżej

   Aby uzyskać więcej informacji na temat korzystania z narzędzia mydumper, zobacz mydumper/myloader

6. Przeczytaj plik metadanych, aby określić nazwę pliku dziennika binarnego i przesunięcie, uruchamiając następujące polecenie:

   cat ./backup/metadata
   

   W tym poleceniu ./backup odwołuje się do katalogu wyjściowego użytego w poleceniu w poprzednim kroku.

   Wyniki powinny być wyświetlane tak, jak pokazano na poniższej ilustracji:

   

   Pamiętaj, aby zanotować nazwę pliku binarnego do użycia w kolejnych krokach.

7. Przywróć bazę danych przy użyciu narzędzia myloader, uruchamiając następujące polecenie:

   myloader --host=<servername>.mysql.database.azure.com --user=<username> --password=<password> --directory=./backup --queries-per-transaction=100 --threads=16 --compress-protocol --ssl --verbose=3 -e 2>myloader-logs.txt
   

   Zmienne w tym poleceniu zostały wyjaśnione poniżej:

   • --host: nazwa serwera repliki
   • --user: nazwa użytkownika. Możesz użyć administratora serwera lub użytkownika z uprawnieniem do odczytu\zapisu, które umożliwia przywracanie schematów i danych do bazy danych
   • --Password: Hasło dla użytkownika powyżej

8. W zależności od wymuszania protokołu SSL na serwerze podstawowym nawiąż połączenie z serwerem repliki przy użyciu narzędzia klienta mysql i wykonaj następujące kroki.

   • Jeśli wymuszanie protokołu SSL jest włączone, wówczas:

     i. Pobierz certyfikat wymagany do komunikacji za pośrednictwem protokołu SSL z serwerem usługi Azure Database for MySQL z tego miejsca.

     ii. Otwórz plik w Notatniku i wklej zawartość do sekcji "UMIEŚĆ KONTEKST CERTYFIKATU KLUCZA PUBLICZNEGO TUTAJ".

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

     iii. Aby skonfigurować dane w replikacji, uruchom następujące polecenie:

     CALL mysql.az_replication_change_master('<Primary_server>.mysql.database.azure.com', '<username>@<primary_server>', '<password>', 3306, '<File_Name>', <Position>, @cert);
     

     Uwaga

     Określ położenie i nazwę pliku z informacji uzyskanych w kroku 6.

   • Jeśli wymuszanie protokołu SSL nie jest włączone, uruchom następujące polecenie:

     CALL mysql.az_replication_change_master('<Primary_server>.mysql.database.azure.com', '<username>@<primary_server>', '<password>', 3306, '<File_Name>', <Position>, '');
     

9. Aby rozpocząć replikację z serwera repliki, wywołaj poniższą procedurę składowaną.

   call  mysql.az_replication_start;
   

10. Aby sprawdzić stan replikacji, na serwerze repliki uruchom następujące polecenie:

    show slave status \G;
    

    Uwaga

    Jeśli używasz programu MySQL Workbench, modyfikator \G nie jest wymagany.

    Jeśli stan Slave_IO_Running i Slave_SQL_Running to Tak, a wartość Seconds_Behind_Master wynosi 0, replikacja działa prawidłowo. Seconds_Behind_Master wskazuje, jak późno jest replika. Jeśli wartość jest inna niż 0, replika przetwarza aktualizacje.

Testowanie replikacji (opcjonalnie)

Aby upewnić się, że replikacja typu data-in działa prawidłowo, możesz sprawdzić, czy zmiany w tabelach w tabeli podstawowej zostały zreplikowane do repliki.

1. Zidentyfikuj tabelę, która ma być używana do testowania, na przykład tabelę Customers, a następnie upewnij się, że liczba wpisów, które zawiera, jest taka sama na serwerach podstawowych i replik, uruchamiając następujące polecenie na każdym z nich:

   select count(*) from customers;
   

2. Zanotuj liczbę wpisów na potrzeby późniejszego porównania.

   Aby przetestować replikację, spróbuj dodać dane do tabel klientów na serwerze podstawowym, a następnie sprawdź, czy nowe dane są replikowane. W takim przypadku dodasz dwa wiersze do tabeli na serwerze podstawowym, a następnie potwierdzisz, że są replikowane na serwerze repliki.

3. W tabeli Customers na serwerze podstawowym wstaw wiersze, uruchamiając następujące polecenie:

   insert  into `customers`(`customerNumber`,`customerName`,`contactLastName`,`contactFirstName`,`phone`,`addressLine1`,`addressLine2`,`city`,`state`,`postalCode`,`country`,`salesRepEmployeeNumber`,`creditLimit`) values
   (<ID>,'name1','name2','name3 ','11.22.5555','54, Add',NULL,'Add1',NULL,'44000','country',1370,'21000.00');
   

4. Aby sprawdzić stan replikacji, wywołaj stan pokaż podrzędny \G , aby potwierdzić, że replikacja działa zgodnie z oczekiwaniami.

5. Aby potwierdzić, że liczba jest taka sama, na serwerze repliki uruchom następujące polecenie:

   select count(*) from customers;
   

Zapewnianie pomyślnego przejścia jednorazowego

Aby zapewnić pomyślne przeniesienie, wykonaj następujące zadania:

1. Skonfiguruj odpowiednie reguły zapory na poziomie serwera oraz reguły sieci wirtualnej, aby nawiązać połączenie z serwerem docelowym. Reguły zapory dla źródła i obiektu docelowego można porównać z poziomu portalu.
2. Skonfiguruj odpowiednie identyfikatory logowania i uprawnienia na poziomie bazy danych na serwerze docelowym. Aby porównać, możesz uruchomić polecenie SELECT FROM mysql.user. Na serwerach źródłowych i docelowych.
3. Upewnij się, że wszystkie połączenia przychodzące z pojedynczym serwerem usługi Azure Database for MySQL zostały zatrzymane.

   Napiwek

   Można ustawić pojedynczy serwer usługi Azure Database for MySQL na tylko do odczytu.

4. Upewnij się, że replika dogoniła element podstawowy, uruchamiając polecenie pokaż stan podrzędny \G i upewnij się, że wartość parametru Seconds_Behind_Master wynosi 0.
5. Przekieruj klientów i aplikacje klienckie do docelowego wystąpienia serwera elastycznego usługi Azure Database for MySQL.
6. Przeprowadź ostateczne przeniesienie, uruchamiając procedurę składowaną mysql.az_replication_stop, co spowoduje zatrzymanie replikacji z serwera repliki.
7. Wywołaj mysql.az_replication_remove_master , aby usunąć konfigurację replikacji typu data-in.

Na tym etapie aplikacje są połączone z nowym serwerem elastycznym usługi Azure Database for MySQL, a zmiany w źródle nie będą już replikowane do miejsca docelowego. Tworzenie reguł zapory usługi Azure Database for MySQL i zarządzanie nimi za pomocą witryny Azure Portal

Powiązana zawartość

• Replikowanie danych do elastycznego serwera usługi Azure Database for MySQL
• Konfigurowanie replikacji serwera elastycznego usługi Azure Database for MySQL
• rozwiązywanie typowych problemów z błędami w usłudze Azure Database for MySQL
• migrowanie bazy danych MySQL do usługi Azure Database for MySQL w trybie offline przy użyciu usługi Azure Database Migration Service