Przeniesienie danych do nowej bazy

Przeniesienie danych do nowej bazy to skopiowanie ich do świeżo utworzonej struktury, np. przy migracji wersji.

Na czym polega przeniesienie danych do nowej bazy

Przeniesienie danych do nowej bazy, nazywane także migracją danych, polega na odczytaniu rekordów z dotychczasowego źródła, przekształceniu ich do wymagań nowej struktury oraz zapisaniu w świeżo utworzonych tabelach lub kolekcjach. Nowa baza może korzystać z innego schematu, innych nazw pól, odmiennych typów danych albo dodatkowych ograniczeń integralności. Samo skopiowanie plików bazy nie zawsze jest migracją logiczną, ponieważ pliki są zwykle zależne od konkretnego silnika, jego wersji i konfiguracji.

Proces powinien obejmować nie tylko dane użytkowe, lecz także relacje między tabelami, klucze główne, klucze obce, indeksy, wartości domyślne i reguły walidacyjne. Jeżeli tabela orders zawiera odwołanie do tabeli customers, kolejność importu musi uwzględniać tę zależność albo czasowo wyłączyć sprawdzanie kluczy obcych, a następnie wykonać kontrolę spójności. W przypadku dokumentowych baz danych podobną rolę mogą pełnić identyfikatory osadzonych dokumentów i reguły walidacji schematu.

Analiza schematu i przygotowanie mapowania pól

Przed rozpoczęciem migracji porównuje się schemat źródłowy z docelowym. Należy ustalić, które kolumny mają bezpośrednie odpowiedniki, które wymagają zmiany typu, a które nie powinny być przenoszone. Przykładowo pole tekstowe przechowujące datę może wymagać konwersji do typu daty i czasu, natomiast liczba zapisana jako tekst może wymagać oczyszczenia z symboli waluty, spacji lub separatorów używanych w innym formacie. Szczególnej uwagi wymagają wartości puste, wartości domyślne oraz różnica między wartością NULL a pustym ciągiem znaków.

Mapowanie powinno być opisane w sposób pozwalający odtworzyć każdy etap. Dla każdego pola warto określić źródłową nazwę, docelową nazwę, typ danych, regułę konwersji oraz sposób obsługi błędnych rekordów. Jeśli w nowej bazie identyfikatory są generowane automatycznie, trzeba zdecydować, czy zachować stare identyfikatory, czy utworzyć tabelę powiązań między identyfikatorem źródłowym i docelowym. Bez takiego powiązania relacje wskazujące na zmienione identyfikatory mogą zostać zapisane z błędnymi odwołaniami.

Import, integralność i kontrola kompletności

Podczas importu dane często zapisuje się partiami, aby ograniczyć zużycie pamięci i ułatwić ponowienie operacji po błędzie. Każda partia może być zatwierdzana w osobnej transakcji, jeżeli dopuszcza to konkretny silnik bazy. W systemach wymagających atomowej migracji stosuje się jedną większą transakcję albo mechanizm etapowego przełączenia aplikacji na nową bazę. Należy kontrolować błędy konwersji, naruszenia unikalności, brakujące rekordy nadrzędne oraz przekroczenia długości pól tekstowych.

Weryfikacja nie powinna ograniczać się do porównania liczby wierszy. Sprawdza się także liczbę wartości pustych, zakresy dat, sumy kontrolne dla wybranych pól, wartości minimalne i maksymalne oraz liczbę rekordów powiązanych relacjami. Po imporcie warto wykonać zapytania kontrolne, które wykrywają osierocone rekordy, duplikaty kluczy i różnice między sumami wartości liczbowych. Należy również sprawdzić indeksy oraz wydajność najczęściej używanych zapytań, ponieważ poprawna liczba rekordów nie gwarantuje zachowania oczekiwanego działania aplikacji.

Przełączenie aplikacji i postępowanie po migracji

Przełączenie na nową bazę wymaga zmiany konfiguracji połączenia, na przykład adresu, nazwy bazy, portu, użytkownika lub sposobu uwierzytelniania. Przed zmianą trzeba ustalić moment zatrzymania zapisów w starej bazie albo zastosować mechanizm synchronizacji przyrostowej. Jeżeli aplikacja nadal zapisuje dane w źródle podczas kopiowania, wynik migracji może być nieaktualny. Bezpieczny scenariusz obejmuje wykonanie kopii zapasowej, zatrzymanie operacji zmieniających dane, przeniesienie końcowego przyrostu, przeprowadzenie kontroli i dopiero potem uruchomienie aplikacji z nowym połączeniem.

Po przełączeniu obserwuje się logi aplikacji, błędy połączeń, czas odpowiedzi zapytań i poprawność operacji odczytu oraz zapisu. Stara baza powinna pozostać dostępna przez okres potrzebny do potwierdzenia poprawności działania, ale nie należy traktować jej jako aktywnego celu zapisu po udanym przełączeniu. Dokumentacja migracji powinna zawierać użyte mapowanie pól, wyniki kontroli, informacje o pominiętych rekordach, sposób odtworzenia kopii zapasowej oraz warunki ewentualnego powrotu do poprzedniej konfiguracji. Dzięki temu przeniesienie danych jest kontrolowaną zmianą struktury i źródła danych, a nie jednorazowym kopiowaniem bez możliwości sprawdzenia skutków.