Migrowanie lokalnego programu MySQL do usługi Azure Database for MySQL: plany testów

Artykuł
08/15/2024

DOTYCZY: Azure Database for MySQL — pojedynczy serwer usługi Azure Database for MySQL — serwer elastyczny

Wymagania wstępne

Omówienie

WWI utworzył plan testowy zawierający zestaw zadań IT i zadań biznesowych. Pomyślne migracje wymagają wykonania wszystkich testów.

Testy:

Upewnij się, że zmigrowana baza danych ma spójność (te same liczby rekordów i wyniki zapytań) z tabelami lokalnymi.
Upewnij się, że wydajność jest akceptowalna (powinna być zgodna z taką samą wydajnością, jak w przypadku działania lokalnie).
Upewnij się, że wydajność zapytań docelowych spełnia określone wymagania.
Zapewnij akceptowalną łączność sieciową między środowiskiem lokalnym i siecią platformy Azure.
Upewnij się, że wszystkie zidentyfikowane aplikacje i użytkownicy mogą łączyć się z zmigrowanym wystąpieniem danych.

WWI zidentyfikował weekend migracji i przedział czasu, który rozpoczął się o godzinie 10:00 i zakończył się o 2 rano czasu pacyficznego. Jeśli migracja nie została ukończona przed celem 2:00 (docelowy czas przestoju 4-godzinny) ze wszystkimi testami, procedury wycofywania zostały uruchomione. Problemy zostały udokumentowane w przypadku przyszłych prób migracji. Wszystkie okna migracji zostały wypchnięte do przodu i ponownie ułożone na podstawie akceptowalnych harmonogramów biznesowych.

Przykładowe zapytania

Seria zapytań została wykonana na źródle i celu w celu zweryfikowania powodzenia migracji bazy danych. Poniższe zapytania i skrypty pomagają określić, czy akcje migracji przeniosły wszystkie wymagane obiekty bazy danych ze źródła do obiektu docelowego.

Wiersze tabeli

Możesz użyć tego zapytania, aby pobrać wszystkie tabele i szacowaną liczbę wierszy:

SELECT SUM(TABLE_ROWS)
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = '{SchemaName}';

Uwaga

Tabela INFORMATION_SCHEMA zawiera szacowany zestaw wartości w tabelach. Aby uzyskać dokładniejszy widok metryk, takich jak rozmiar tabeli, zwiększ rozmiar próbki strony przy użyciu parametru innodb_stats_transient_sample_pages serwera. Zwiększenie tej wartości serwera wymusza analizowanie większej liczby stron i dostarczanie bardziej dokładnych wyników.

Wykonaj instrukcję count(*) SQL dla każdej tabeli, aby uzyskać dokładną liczbę wierszy. Uruchomienie tego polecenia może zająć dużo czasu na dużych tabelach. Poniższy skrypt generuje zestaw instrukcji SQL, które można wykonać, aby uzyskać dokładne liczby:

SELECT CONCAT(
    'SELECT "',
    table_name,
    '" AS table_name, COUNT(*) AS exact_row_count FROM `',
    table_schema,
    '`.`',
    table_name,
    '` UNION '
)
FROM INFORMATION_SCHEMA.TABLES
WHERE table_schema = '**my_schema**';

Fragmentacja tabeli

Tabele danych mogą nadal rosnąć coraz częściej dzięki ciągłemu użyciu aplikacji. W niektórych przypadkach dane mogą nie rosnąć, ale stale zmieniają się dzięki usunięciom i aktualizacjom. Jeśli tak, istnieje wiele fragmentacji w plikach bazy danych. Instrukcja MySQL OPTIMIZE TABLE może zmniejszyć potrzeby fizycznego miejsca do magazynowania i zwiększyć wydajność operacji we/wy.

Tabele MySQL można zoptymalizować, uruchamiając następujące polecenie:

optimize table TABLE_NAME

Obiekty bazy danych

Użyj następującego zapytania, aby upewnić się, że wszystkie inne obiekty bazy danych są uwzględniane. Chociaż te zapytania mogą obliczyć liczby wierszy tabeli, mogą nie uwzględniać wersji określonego obiektu bazy danych. Na przykład, mimo że może istnieć procedura składowana, może ona ulec zmianie między rozpoczęciem i końcem migracji. Zaleca się blokowanie tworzenia obiektów bazy danych podczas migracji.

Użytkownicy

SELECT DISTINCT
        USER
FROM
        mysql.user
WHERE
        user <> '' order by user

Indeksy

SELECT DISTINCT
        INDEX_NAME
FROM
        information_schema.STATISTICS
WHERE
        TABLE_SCHEMA = '{SchemaName}'

Ograniczenia

SELECT DISTINCT
        CONSTRAINT_NAME
FROM
        information_schema.TABLE_CONSTRAINTS
WHERE
        CONSTRAINT_SCHEMA = '{SchemaName}'

Widoki

SELECT
        TABLE_NAME
FROM
        information_schema.VIEWS
WHERE
        TABLE_SCHEMA = '{SchemaName}'

Procedury składowane

SELECT
        ROUTINE_NAME
FROM
        information_schema.ROUTINES
WHERE
        ROUTINE_TYPE = 'FUNCTION' and
        ROUTINE_SCHEMA = '{SchemaName}'

Funkcje

SELECT
        ROUTINE_NAME
FROM
        information_schema.ROUTINES
WHERE
        ROUTINE_TYPE = 'PROCEDURE' and
        ROUTINE_SCHEMA = '{SchemaName}'

Wydarzenia

SELECT
        EVENT_NAME
FROM
        INFORMATION_SCHEMA.EVENTS
WHERE
        EVENT_SCHEMA = '{SchemaName}'

Strategie wycofywania

Powyższe zapytania zawierają listę nazw obiektów i liczby używanych w decyzji wycofywania. Użytkownicy migracji mogą wykonać pierwszy krok weryfikacji obiektu, sprawdzając liczbę obiektów źródłowych i docelowych. Rozbieżność liczby obiektów może nie oznaczać, że konieczne jest wycofanie. Przeprowadzenie dogłębnej oceny może wskazywać, że różnica jest niewielka i możliwa do odzyskania. Rozwiązaniem może być ręczna migracja kilku nieudanych obiektów. Jeśli na przykład wszystkie tabele i wiersze danych zostały zmigrowane, pominięto tylko kilka funkcji, koryguj te obiekty zakończone niepowodzeniem i finalizuj migrację. Jeśli baza danych jest stosunkowo mała, może być możliwe wyczyszczenie wystąpienia usługi Azure Database for MySQL i ponowne uruchomienie migracji. Duże bazy danych mogą potrzebować więcej czasu niż jest dostępne w oknie migracji, aby określić brakujące obiekty. Migracja musi się zatrzymać i wycofać.

Identyfikowanie brakujących obiektów bazy danych musi nastąpić szybko podczas okna migracji. Każda minuta jest liczone. Jedną z opcji może być wyeksportowanie nazw obiektów środowiskowych do pliku i użycie narzędzia do porównywania danych w celu szybkiego identyfikowania brakujących obiektów. Inną opcją może być wyeksportowanie nazw obiektów źródłowej bazy danych i zaimportowanie danych do docelowej tabeli tymczasowej środowiska bazy danych. Porównaj dane przy użyciu skryptowej i przetestowanej instrukcji SQL. Szybkość i dokładność weryfikacji danych mają kluczowe znaczenie dla procesu migracji. Nie należy polegać na ręcznym odczytywaniu i weryfikowaniu długiej listy obiektów bazy danych podczas okna migracji. Możliwość błędu ludzkiego jest zbyt duża. Najlepiej byłoby zarządzać wyjątkiem przy użyciu narzędzi.

Scenariusz ii wojny światowej

Dyrektor ds. systemów informatycznych WWI otrzymał raport potwierdzający, że wszystkie obiekty bazy danych zostały zmigrowane z lokalnej bazy danych do wystąpienia usługi Azure Database for MySQL. Zespół bazy danych uruchomił powyższe zapytania względem bazy danych przed rozpoczęciem migracji i zapisał wszystkie wyniki w arkuszu kalkulacyjnym.

Informacje o schemacie źródłowej bazy danych zostały użyte do zweryfikowania wierności docelowego obiektu migracji.

Lista kontrolna planów testów

Wykonywanie skryptów, testowania i gotowości do wykonania zapytań testowych.
Dowiedz się, jak długo trwa uruchamianie zapytań testowych i uczynić je częścią udokumentowanej osi czasu migracji.
Przygotuj strategię ograniczania ryzyka i wycofywania dla różnych potencjalnych wyników.
Mają dobrze zdefiniowaną oś czasu zdarzeń migracji.

Następny krok

Punkty odniesienia wydajności

Udostępnij za pośrednictwem