Najlepsze praktyki migracji baz danych

Migracja bazy danych jest bardziej złożona niż przeniesienie maszyny wirtualnej, ponieważ bazy danych są stanowe i często mają aktywne połączenia przez całą dobę. Naiwne podejście polegające na skopiowaniu i odtworzeniu bazy wymagałoby wielogodzinnego przestoju, co jest niedopuszczalne w systemach produkcyjnych. Najlepsze praktyki migracji baz danych obejmują ciągłą replikację danych, która utrzymuje synchronizację źródła i celu podczas weryfikacji celu, a następnie krótkie, zaplanowane przełączenie, podczas którego ruch zostaje przekierowany do nowej bazy danych na platformie Azure.

Azure Database Migration Service (DMS) to w pełni zarządzana usługa, która koordynuje migracje online (z niemal zerowym przestojem) i offline (oparte na przestoju) z popularnych lokalnych silników baz danych do zarządzanych usług baz danych platformy Azure. DMS obsługuje źródła takie jak SQL Server, MySQL, PostgreSQL, MongoDB, Oracle oraz cele takie jak Azure SQL Database, Azure SQL Managed Instance, Azure Database for MySQL i Azure Cosmos DB. Usługa integruje się z narzędziem Data Migration Assistant (DMA) w celu przeprowadzania kontroli zgodności przed migracją.

Przed migracją programu SQL Server uruchom narzędzie Data Migration Assistant (DMA) dla źródłowej bazy danych. DMA identyfikuje: problemy ze zgodnością (funkcje używane w bazie danych, które nie są obsługiwane przez docelowy produkt Azure SQL), zmiany powodujące niezgodność, przestarzałe funkcje oraz rekomendacje dotyczące wydajności. Generuje szczegółowy raport HTML, w którym problemy są uporządkowane według ważności, aby zespół mógł je rozwiązać przed rozpoczęciem okna migracji.

Migracja offline wyłącza źródłową bazę danych na czas migracji — jest to akceptowalne w przypadku małych baz danych lub systemów niekrytycznych, dla których można zaplanować okno konserwacji. Migracja online wykorzystuje przechwytywanie zmienionych danych (CDC) lub wysyłanie dziennika transakcji, aby nieprzerwanie replikować zmiany podczas ładowania nowej bazy danych, ograniczając przestój do samego końcowego etapu przełączenia. Migracja online jest zalecana w przypadku baz danych większych niż 1 GB lub objętych umowami SLA wymagającymi przestoju krótszego niż 1 godzina.

Projekt migracji DMS określa połączenie źródłowe (nazwę serwera, uwierzytelnianie i nazwy baz danych), połączenie docelowe (parametry połączenia z Azure SQL) oraz tryb migracji (online lub offline). Należy również wybrać bazy danych i tabele do migracji. DMS sprawdza łączność przed rozpoczęciem migracji. Projekt migracji jest zachowywany w portalu Azure, dzięki czemu można monitorować postęp, ponawiać migrację tabel, których nie udało się przenieść, i wyświetlać szczegółowe dzienniki aktywności.

Zawsze należy przeprowadzić migrację schematu przed danymi. Narzędzia DMA lub SQL Server Management Studio (SSMS) należy użyć do utworzenia skryptów i wdrożenia tabel, widoków, procedur składowanych, funkcji i indeksów w docelowej bazie danych Azure SQL Database. Przed zezwoleniem usłudze DMS na rozpoczęcie transferu danych należy sprawdzić, czy wszystkie obiekty schematu istnieją i kompilują się bez błędów. Błędy schematu wykryte w trakcie migracji mogą uszkodzić proces migracji i zmusić do jego ponownego rozpoczęcia od zera.

DMS wykonuje pełne ładowanie danych, odczytując źródłową bazę danych tabela po tabeli i zapisując wiersze w miejscu docelowym Azure SQL za pomocą operacji bulk insert. Podczas pełnego ładowania usługa obsługuje duże tabele, dzieląc je na partie. Indeksy w miejscu docelowym są wyłączane na czas ładowania w celu maksymalizacji przepustowości, a następnie odbudowywane. W przypadku bardzo dużych baz danych (w skali TB) warto rozważyć użycie Azure Data Factory lub eksportów bacpac do wstępnego załadowania danych i skrócenia czasu działania DMS.

W przypadku migracji online DMS włącza funkcję SQL Server Change Data Capture (CDC) w źródłowej bazie danych, aby przechwytywać operacje INSERT, UPDATE i DELETE wykonywane podczas pełnego ładowania. Po zakończeniu pełnego ładowania DMS odtwarza przechwycone zmiany w miejscu docelowym, stopniowo zmniejszając różnicę. Gdy opóźnienie spadnie niemal do zera, baza danych jest gotowa do przełączenia. Funkcja CDC wymaga uruchomienia SQL Server Agent oraz ustawienia źródłowej bazy danych w trybie full recovery.

Gdy opóźnienie CDC jest minimalne, zainicjuj przełączenie w portalu DMS. DMS przestaje przyjmować nowe zdarzenia CDC, stosuje pozostałe zmiany i oznacza migrację jako ukończoną. Następnie należy przekierować parametry połączeń aplikacji do punktu końcowego Azure SQL. Uruchom zapytania weryfikujące dane, porównując liczbę wierszy i agregaty sum kontrolnych między źródłem a miejscem docelowym dla tabel krytycznych. Pozostaw źródłową bazę danych w trybie tylko do odczytu przez 24–48 godzin po przełączeniu, na wypadek konieczności wycofania zmian.

Po migracji Azure SQL Database może działać inaczej niż lokalny SQL Server ze względu na różnice w pamięciach podręcznych planów zapytań, statystykach i sprzęcie. Uruchom Database Experimentation Assistant (DEA), aby odtworzyć ślady obciążenia w miejscu docelowym Azure i porównać plany wykonania. Włącz funkcję Automatic Tuning w Azure SQL, aby usługa automatycznie tworzyła lub usuwała indeksy oraz wymuszała plany zapytań, które nie powodują regresji, poprawiając wydajność z czasem bez ręcznej ingerencji.

DMS obsługuje również migrację aparatów open source: MySQL do Azure Database for MySQL przy użyciu wzorca mysqldump + binlog replication oraz PostgreSQL do Azure Database for PostgreSQL z użyciem slotów replikacji logicznej. W przypadku migracji MongoDB do Cosmos DB użyj interfejsu API Cosmos DB for MongoDB oraz natywnego potoku mongodump / mongorestore albo konektora MongoDB usługi Azure Data Factory na potrzeby przyrostowego CDC. Zawsze testuj migrację na kopii nieprodukcyjnej przed uruchomieniem jej dla danych działającego systemu.

W tej lekcji poznali Państwo następujące zagadnienia: Azure Database Migration Service koordynuje migracje baz danych online i offline, ocena przed migracją za pomocą DMA pozwala wykryć problemy ze zgodnością przed rozpoczęciem okna migracji, a przechwytywanie zmian danych umożliwia przełączenie produkcyjnych baz danych z niemal zerowym przestojem. W następnej części skupimy się na optymalizacji kosztów Azure.