Przenoszenie baz danych

Przenoszenie baz danych to ich odłączenie, skopiowanie plików i ponowne podłączenie na docelowym serwerze.

Na czym polega przenoszenie baz danych

Przenoszenie baz danych polega na zmianie miejsca, w którym przechowywane są pliki oraz dane zarządzane przez konkretny silnik bazodanowy. Operacja może obejmować przejście na inny dysk, zmianę serwera, odtworzenie bazy na nowej instalacji tego samego silnika albo migrację do innego systemu bazodanowego. W każdym przypadku trzeba zachować nie tylko rekordy, lecz także strukturę tabel, indeksy, klucze główne, ograniczenia integralności, widoki, procedury, wyzwalacze oraz uprawnienia wymagane przez aplikacje.

Najprostszy wariant wykorzystuje odłączenie bazy od usługi, skopiowanie jej plików i ponowne podłączenie w miejscu docelowym. Taka metoda zależy od konkretnego silnika i jego formatu plików, dlatego nie można traktować jej jako uniwersalnej procedury dla wszystkich baz. Alternatywą jest wykonanie kopii zapasowej, przesłanie pliku kopii na serwer docelowy i odtworzenie bazy. Kopia logiczna może polegać na zapisaniu definicji obiektów oraz instrukcji odtwarzających dane, natomiast kopia fizyczna obejmuje pliki używane przez silnik.

Planowanie migracji i kontrola zależności

Przed rozpoczęciem przenoszenia należy ustalić, jakie aplikacje korzystają z bazy, jakimi kontami się łączą oraz gdzie zapisano dane konfiguracyjne zawierające adres serwera, nazwę bazy i parametry połączenia. Warto sprawdzić rozmiar danych, ilość wolnego miejsca na serwerze docelowym, używaną wersję silnika, kodowanie znaków, ustawienia sortowania oraz dostępne mechanizmy uwierzytelniania. Różnice w wersjach mogą powodować problemy z odtworzeniem kopii, działaniem procedur lub interpretacją typów danych.

Istotne jest także zaplanowanie okna migracyjnego. Jeżeli aplikacja zapisuje dane podczas kopiowania, źródło i cel mogą się rozbiec. Z tego powodu przed wykonaniem końcowej kopii zwykle zatrzymuje się procesy zapisujące dane albo przełącza aplikację w tryb serwisowy. Przy systemach wymagających krótkiej przerwy można najpierw wykonać kopię wstępną, a następnie skopiować zmiany zapisane do momentu przełączenia. Po migracji trzeba zaktualizować konfigurację aplikacji, sprawdzić połączenie i upewnić się, że użytkownicy mają odpowiednie uprawnienia.

Spójność danych, kopie zapasowe i test odtworzenia

Bezpośrednie kopiowanie plików bazy podczas normalnej pracy może utworzyć niespójny zestaw danych. Część stron plików może być wtedy zmieniona, a część pozostawać w starszym stanie. Bezpieczna kopia fizyczna wymaga użycia mechanizmu dostarczonego przez silnik albo zatrzymania usługi w sposób zapewniający poprawne zamknięcie plików. Kopia zapasowa powinna zostać zweryfikowana, a przed migracją należy sprawdzić, czy istnieje możliwość powrotu do pierwotnej lokalizacji.

Po odtworzeniu bazy trzeba porównać podstawowe parametry ze źródłem: liczbę tabel, rozmiar danych, liczbę rekordów w kluczowych tabelach oraz obecność indeksów i ograniczeń. Sama możliwość zalogowania się do bazy nie potwierdza poprawności migracji. Należy uruchomić reprezentatywne operacje aplikacji, w tym odczyt, zapis, aktualizację i usuwanie danych, a także zapytania używane w raportach. Warto sprawdzić logi silnika i aplikacji, ponieważ błędne uprawnienia, niezgodne kodowanie lub brak obiektów pomocniczych mogą ujawnić się dopiero podczas konkretnej operacji.

Przełączenie aplikacji na serwer docelowy

Końcowy etap obejmuje przełączenie aplikacji z dotychczasowego adresu bazy na nową lokalizację. Zmiana może dotyczyć nazwy hosta, portu, instancji, nazwy usługi albo wpisu w pliku konfiguracyjnym. Po zmianie należy potwierdzić, że aplikacja korzysta z właściwej bazy, a nie z pustej bazy utworzonej przypadkowo podczas konfiguracji. Pomocne jest wykonanie kontrolnego zapisu oznaczonego identyfikatorem testowym i sprawdzenie, czy pojawił się on w docelowym systemie.

Jeżeli po migracji występują błędy, należy najpierw porównać konfigurację połączenia, status usługi bazodanowej, reguły dostępu oraz uprawnienia konta aplikacyjnego. Następnie można sprawdzić zgodność schematu, brakujące rozszerzenia, procedury i zadania wykonywane automatycznie. Dokumentacja powinna zawierać datę migracji, lokalizację kopii, wersję silnika, wykonane testy oraz sposób powrotu do poprzedniego serwera. Takie informacje ułatwiają odtworzenie środowiska po awarii i ograniczają ryzyko utraty danych przy kolejnych zmianach infrastruktury.