Migrowanie lokalnego programu MySQL do usługi Azure Database for MySQL: migracja danych

Migracja danych to kluczowy aspekt przenoszenia baz danych MySQL ze środowisk lokalnych do baz danych azure database for MySQL. Ten artykuł zawiera szczegółowe informacje na temat zawiłości migracji danych, oferując kompleksowy przewodnik po różnych technikach i najlepszych rozwiązaniach w celu zapewnienia bezproblemowego transferu danych. Strategię migracji można skutecznie zaplanować i wykonać, rozumiejąc różne metody migracji danych, takie jak migracja logiczna i fizyczna, oraz podejmując potencjalne wyzwania, takie jak integralność danych i przestoje. Ten przewodnik zawiera wiedzę na temat obsługi dużych zestawów danych, minimalizowania zakłóceń i używania niezawodnych funkcji platformy Azure w celu zoptymalizowania wydajności i niezawodności bazy danych. Niezależnie od tego, czy celem jest modernizacja infrastruktury, czy zwiększenie możliwości zarządzania danymi, ten artykuł zapewni szczegółowe informacje potrzebne do pomyślnej migracji danych.

Wymagania wstępne

Migrowanie lokalnego programu MySQL do usługi Azure Database for MySQL: plany bazowe wydajności

Tworzenie kopii zapasowej bazy danych

Rozsądnym krokiem przed uaktualnieniem lub migracją danych jest wyeksportowanie bazy danych przed uaktualnieniem przy użyciu programu MySQL Workbench lub ręcznie za pomocą mysqldump polecenia .

Offline a online

Przed wybraniem narzędzia migracji należy określić, czy migracja powinna być w trybie online, czy w trybie offline.

• Migracje w trybie offline powodują, że system nie działa podczas migracji. Ta opcja gwarantuje, że żadne transakcje nie występują, a stan danych jest dokładnie taki, jaki jest oczekiwany po przywróceniu na platformie Azure.

• Migracje online migrują dane niemal w czasie rzeczywistym. Ta opcja jest odpowiednia w przypadku niewielkiego przestoju dla użytkowników lub aplikacji korzystających z obciążenia danych. Proces polega na replikowaniu danych przy użyciu metody replikacji, takiej jak binlog lub podobnej.

W przypadku ii wojny światowej ich środowisko ma pewne złożone wymagania dotyczące sieci i zabezpieczeń, które nie zezwalają na stosowanie odpowiednich zmian w przypadku łączności przychodzącej i wychodzącej w docelowym przedziale czasowym migracji. Te złożoność i wymagania zasadniczo eliminują podejście online.

Dryf danych

Strategie migracji w trybie offline mogą dryfować dane. Dryf danych występuje, gdy nowo zmodyfikowane dane źródłowe stają się nieaktualne z migrowanych danych. W takim przypadku potrzebny jest pełny eksport lub eksport różnicowy. Ten problem można rozwiązać, zatrzymując cały ruch do bazy danych, a następnie wykonując eksport. Jeśli zatrzymanie całego ruchu modyfikacji danych nie jest możliwe, musisz uwzględnić dryf.

Określenie zmian może stać się skomplikowane, jeśli tabele bazy danych nie mają kolumn, takich jak klucze podstawowe oparte na liczbach, lub jakiś typ modyfikacji i tworzenia daty w każdej tabeli, która musi zostać zmigrowana.

Jeśli na przykład istnieje klucz podstawowy oparty na liczbach, a migracja jest importowana w kolejności sortowania, stosunkowo proste jest określenie, gdzie import został zatrzymany i ponownie uruchomiony z tej pozycji. Jeśli nie ma żadnego klucza liczbowego, można użyć daty modyfikacji i utworzenia, a następnie zaimportować w sposób posortowany, aby można było ponownie uruchomić migrację z ostatniej daty widocznej w obiekcie docelowym.

Zalecenia dotyczące wydajności

Eksport

• Korzystanie z narzędzia eksportu, które może działać w trybie wielowątkowym, takim jak mydumper

• W przypadku korzystania z programu MySQL 8.0 użyj tabel partycjonowanych, jeśli jest to konieczne, aby zwiększyć szybkość eksportu.

Importuj

• Po załadowaniu danych utwórz indeksy klastrowane i klucze podstawowe. Załaduj dane w kolejności klucza podstawowego lub inne, jeśli klucz podstawowy zawiera kolumnę dat (na przykład modyfikowanie daty lub daty utworzenia) w kolejności sortowania.

• Opóźnij tworzenie indeksów pomocniczych do momentu załadowania danych. Utwórz wszystkie indeksy pomocnicze po załadowaniu.

• Wyłącz ograniczenia klucza obcego przed załadowaniem. Wyłączenie kontroli kluczy obcych zapewnia znaczne wzrosty wydajności. Włącz ograniczenia i zweryfikuj dane po załadowaniu, aby zapewnić integralność referencyjną.

• Ładowanie danych równolegle. Unikaj zbyt dużej równoległości, która może spowodować rywalizację o zasoby i monitorować zasoby przy użyciu metryk dostępnych w witrynie Azure Portal.

Przeprowadzanie migracji

• Tworzenie kopii zapasowej bazy danych

• Tworzenie i weryfikowanie strefy docelowej platformy Azure

• Konfigurowanie parametrów serwera źródłowego

• Konfigurowanie parametrów serwera docelowego

• Eksportowanie obiektów bazy danych (schematu, użytkowników itp.)

• Eksportowanie danych

• Importowanie obiektów bazy danych

• Importowanie danych

• Walidacja

• Resetuj parametry serwera docelowego

• Migrowanie co najmniej jednej aplikacji

Typowe kroki

Pomimo podjętej ścieżki istnieją typowe kroki, które należy wykonać:

• Uaktualnianie do obsługiwanej wersji usługi Azure MySQL

• Obiekty bazy danych spisu

• Eksportowanie użytkowników i uprawnień

Migrowanie do najnowszej wersji programu MySQL

Ponieważ baza danych konferencji WWI działa w wersji 5.5, należy przeprowadzić uaktualnienie. Dyrektor ds. systemów informatycznych poprosił o uaktualnienie do najnowszej wersji programu MySQL (obecnie 8.0).

Istnieją dwa sposoby uaktualniania do wersji 8.0:

• W miejscu

• Eksportowanie/importowanie

Podczas podejmowania decyzji o uaktualnieniu ważne jest, aby uruchomić narzędzie do sprawdzania uaktualnienia, aby określić, czy występują jakieś konflikty. Na przykład podczas uaktualniania do programu MySQL Server 8.0 narzędzie sprawdza następujące konflikty:

• Nazwy obiektów bazy danych, które powodują konflikt z słowami rezerwowymi w programie MySQL 8.0

• Użycie zestawu znaków utf8mb3

• Użycie atrybutów typu ZEROFILL/display length

• Nazwy tabel, które powodują konflikt z tabelami w wersji 8.0

• Użycie typu czasowego

• Nazwy ograniczeń klucza obcego dłuższe niż 64 znaki

Jeśli kontroler uaktualniania nie zgłasza żadnych problemów, można bezpiecznie przeprowadzić uaktualnienie w miejscu, zastępując pliki binarne MySQL. Bazy danych z problemami należy wyeksportować i rozwiązać problemy.

Scenariusz ii wojny światowej

Po pomyślnym przeprowadzeniu migracji wystąpienia mySQL do wersji 8.0 zespół migracji WWI zdał sobie sprawę, że oryginalna lokalna migracja bazy danych MySQL do usługi Azure Database for MySQL nie może być już używana, ponieważ narzędzie DMS obsługuje obecnie tylko 5.6 i 5.7. Usługa DMS wymaga dostępu do sieci. Zespół migracji WWI nie był gotowy do obsługi złożonych problemów z siecią. Te problemy środowiskowe zawęziły wybór narzędzia migracji do aplikacji MySQL Workbench.

Obiekty bazy danych

Jak opisano w sekcji Plany testów, przed migracją należy wykonać spis obiektów bazy danych i po nim, aby upewnić się, że wszystko zostało zmigrowane.

Jeśli chcesz wykonać procedurę składowaną w celu wygenerowania tych informacji, możesz użyć czegoś podobnego do następującego:

DELIMITER //
CREATE PROCEDURE `Migration_PerformInventory`(IN schemaName CHAR(64))
BEGIN

        DECLARE finished INTEGER DEFAULT 0;
          DECLARE tableName varchar(100) DEFAULT "";

        #get all tables
            DECLARE curTableNames
                CURSOR FOR
                    SELECT TABLE_NAME FROM information_schema.tables where TABL
E_SCHEMA = schemaName;

            -- declare NOT FOUND handler
            DECLARE CONTINUE HANDLER
                FOR NOT FOUND SET finished = 1;

            DROP TABLE IF EXISTS MIG_INVENTORY;

                CREATE TABLE MIG_INVENTORY
                (
                      REPORT_TYPE VARCHAR(1000),
                      OBJECT_NAME VARCHAR(1000),
                  PARENT_OBJECT_NAME VARCHAR (1000),
                      OBJECT_TYPE VARCHAR(1000),
                      COUNT INT
                )
                ROW_FORMAT=DYNAMIC,
                ENGINE='InnoDB';
              INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
                SELECT
                     'OBJECTCOUNT', 'TABLES', 'TABLES', COUNT(*)
              FROM
                     information_schema.tables
                where
                     TABLE_SCHEMA = schemaName;
                #### Constraints
              INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
                SELECT
                      'OBJECTCOUNT', 'STATISTICS', 'STATISTICS', COUNT(*)
                FROM
                      information_schema.STATISTICS
                WHERE
                      TABLE_SCHEMA = schemaName;
                INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
                SELECT
                      'OBJECTCOUNT', 'VIEWS', 'VIEWS', COUNT(*)
                FROM
                      information_schema.VIEWS
                WHERE
                      ROUTINE_TYPE = 'FUNCTION' and
                      ROUTINE_SCHEMA = schemaName;

                INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
                SELECT
                      'OBJECTCOUNT', 'PROCEDURES', 'PROCEDURES', COUNT(*)
                FROM
                      information_schema.ROUTINES
                WHERE
                      ROUTINE_TYPE = 'PROCEDURE' and
                      ROUTINE_SCHEMA = schemaName;

                INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
                SELECT
                       'OBJECTCOUNT', 'EVENTS', 'EVENTS', COUNT(*)
                FROM
                       information_schema.EVENTS
                WHERE
                       EVENT_SCHEMA = schemaName;

                INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
                SELECT
                       'OBJECTCOUNT', 'USER DEFINED FUNCTIONS', 'USER DEFINED FUNCTIONS'
        , COUNT(*)
                FROM
                        mysql.func;

                INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
                SELECT
                        'OBJECTCOUNT', 'USERS', 'USERS', COUNT(*)
                FROM
                        mysql.user
                WHERE
                        user <> '' order by user;

                OPEN curTableNames;

                getTableName: LOOP
                        FETCH curTableNames INTO tableName;
                        IF finished = 1 THEN
                              LEAVE getTableName;
                        END IF;

                   SET @s = CONCAT('SELECT COUNT(*) into @TableCount FROM ', schemaName,
'.', tableName);
        #SELECT @s;
            PREPARE stmt FROM @s;
        EXECUTE stmt;
        INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)

                SELECT
                    'TABLECOUNT', tableName, 'TABLECOUNT', @TableCount;
        DEALLOCATE PREPARE stmt;

     END LOOP getTableName;
     CLOSE curTableNames;

   SELECT * FROM MIG_INVENTORY;
END //

DELIMITER ;

CALL Migration_PerformInventory('reg_app');

• Wywołanie tej procedury w źródłowej bazie danych ujawnia następujące dane (obcięte dane wyjściowe):

• Wynik procedury docelowej bazy danych powinien wyglądać podobnie do poniższego obrazu po zakończeniu migracji. Zwróć uwagę, że w bazie danych nie ma żadnych funkcji. Funkcje zostały wyeliminowane przed migracją.

Użytkownicy i uprawnienia

Pomyślna migracja wymaga migracji skojarzonych użytkowników i uprawnień do środowiska docelowego.

Eksportuj wszystkich użytkowników i ich granty przy użyciu następującego skryptu programu PowerShell:

$username = "yourusername";
$password = "yourpassword";
mysql -u$username -p$password --skip-column-names -A -e"SELECT CONCAT('SHOW G
RANTS FOR ''',user,'''@''',host,''';') FROM mysql.user WHERE user<>''" > Show
Grants.sql;

$lines = get-content "ShowGrants.sql"

foreach ($line in $lines)
{
mysql -u$username -p$password --skip-column-names -A -e"$line" >> AllGrants.sql
}

• Tworzenie nowego skryptu programu PowerShell przy użyciu programu PowerShell ISE (zapoznaj się z dokumentem Instalatora)

• Ustaw nazwę użytkownika na root i hasło na hasło użytkownika głównego

Następnie możesz uruchomić AllGrants.sql skrypt przeznaczony dla nowej usługi Azure Database for MySQL:

$username = "yourusername";
$password = "yourpassword";
$server = "serverDNSname";
$lines = get-content "AllGrants.sql"

foreach ($line in $lines)
{
mysql -u$username -p$password -h$server --ssl-ca=c:\temp\BaltimoreCyberTrus
tRoot.crt.cer --skip-column-names -A -e"$line"
}

Możesz również tworzyć użytkowników w usłudze Azure Database for MySQL przy użyciu programu PowerShell: /azure/mysql/howto-create-users

Wykonywanie migracji

Dzięki podstawowym składnikom migracji można teraz kontynuować migrację danych. Wcześniej wprowadzono kilka narzędzi i metod. W przypadku ii wojny światowej użyją ścieżki MySQL Workbench do wyeksportowania danych, a następnie zaimportują je do usługi Azure Database for MySQL.

Lista kontrolna migracji danych

• Zapoznaj się ze złożonością środowiska i jeśli podejście online jest możliwe.

• Konto dryfu danych. Zatrzymanie usługi bazy danych może wyeliminować potencjalny dryf danych.

• Konfigurowanie parametrów źródłowych na potrzeby szybkiego eksportu.

• Skonfiguruj parametry docelowe na potrzeby szybkiego importowania.

• Przetestuj wszystkie migracje, które mają inną wersję źródłową, a docelową.

• Migrowanie wszelkich obiektów niezwiązanych z danymi, takich jak nazwy użytkowników i uprawnienia.

• Upewnij się, że wszystkie zadania są udokumentowane i wyewidencjonowane podczas wykonywania migracji.

Następny krok