Kopia bazy do nowej instancji

Kopia bazy do nowej instancji to przeniesienie danych na inny serwer, zwykle przez backup i przywrócenie.

Zakres pojęcia „kopia bazy do nowej instancji”

Kopia bazy do nowej instancji oznacza utworzenie odrębnego środowiska silnika baz danych i odtworzenie w nim zawartości istniejącej bazy. Nowa instancja może działać na innym serwerze fizycznym, maszynie wirtualnej albo komputerze przeznaczonym do pracy z bazą. Samo skopiowanie plików nie zawsze jest wystarczające, ponieważ pliki danych i pliki dziennika transakcji muszą odpowiadać formatowi używanego silnika, jego wersji oraz konfiguracji. Z tego powodu przeniesienie zwykle wykonuje się przez backup logiczny lub fizyczny, a następnie procedurę restore obsługiwaną przez konkretny system bazodanowy.

Backup logiczny zapisuje strukturę obiektów i dane w formie przeznaczonej do odtworzenia, na przykład definicje tabel, indeksów, ograniczeń oraz rekordy. Backup fizyczny obejmuje pliki bazy albo ich spójny obraz i wymaga zgodności z mechanizmem przechowywania używanym przez dany silnik. Zakres możliwej migracji zależy od produktu: nie każda kopia fizyczna może zostać odtworzona na innym systemie operacyjnym, w starszej wersji silnika lub przy innej architekturze plików. Przed rozpoczęciem trzeba więc ustalić nazwę silnika, wersję źródłową i docelową, kodowanie, układ plików oraz wymagane rozszerzenia.

Przygotowanie spójnego backupu i środowiska docelowego

Podstawowym warunkiem poprawnej kopii jest spójność danych w chwili wykonania backupu. Jeżeli aplikacja zapisuje informacje podczas tworzenia kopii, rezultat musi uwzględniać reguły transakcyjne silnika. W zależności od produktu stosuje się backup wykonywany przy kontrolowanym zatrzymaniu zapisu, mechanizm kopii online albo zestaw kopii pełnej i przyrostowych lub dzienników transakcji. Celem jest uzyskanie punktu odtworzenia, w którym relacje między tabelami, indeksami i zapisami transakcyjnymi pozostają zgodne.

Instancję docelową należy przygotować przed odtworzeniem danych. Obejmuje to instalację właściwej wersji silnika, utworzenie konta usługi, ustawienie lokalizacji plików danych i dzienników oraz zapewnienie wystarczającej przestrzeni dyskowej. Trzeba również sprawdzić ustawienia kodowania znaków, strefę czasową używaną przez aplikację, format sortowania i sposób uwierzytelniania. W przypadku różnicy wersji należy potwierdzić, czy docelowy silnik obsługuje format backupu oraz czy migracja w kierunku z wersji nowszej do starszej jest wspierana. Nie wolno zakładać, że zgodność samej nazwy produktu oznacza zgodność plików i metadanych.

Odtworzenie, uprawnienia i przełączenie aplikacji

Po przekazaniu backupu do nowej instancji wykonuje się odtworzenie zgodnie z dokumentacją danego silnika. Jeżeli backup zawiera ścieżki plików, trzeba wskazać istniejące lokalizacje na serwerze docelowym albo zastosować mechanizm zmiany mapowania plików. Po restore należy odtworzyć konta, role, uprawnienia oraz zależności używane przez aplikację. W wielu systemach użytkownicy zdefiniowani w bazie nie są tym samym co konta uwierzytelniane przez system operacyjny lub usługę katalogową, dlatego migracja danych może wymagać osobnego odtworzenia tożsamości i przypisań.

Przełączenie aplikacji na nową instancję wymaga zmiany parametrów połączenia, takich jak nazwa hosta, port, nazwa bazy, sposób uwierzytelniania i certyfikat używany przez szyfrowane połączenie. Przed zmianą warto zatrzymać zapisy albo zastosować zaplanowane okno migracyjne, aby nie powstały nowe dane pozostawione wyłącznie na serwerze źródłowym. Jeżeli silnik obsługuje odtwarzanie kolejnych dzienników transakcji, można skrócić czas niedostępności, wykonując końcową kopię po zatrzymaniu zapisu. Po zmianie konfiguracji trzeba sprawdzić, czy aplikacja łączy się z właściwą instancją, a nie z lokalnym lub domyślnym serwerem.

Weryfikacja danych po przeniesieniu do nowej instancji

Odtworzenie backupu nie jest równoznaczne z potwierdzeniem poprawności migracji. Najpierw sprawdza się stan bazy przy użyciu narzędzi diagnostycznych właściwych dla danego silnika, w tym integralność struktur, dostępność tabel, indeksów i ograniczeń oraz możliwość odczytu dziennika transakcji. Następnie porównuje się podstawowe parametry ze środowiskiem źródłowym: liczbę tabel, liczbę rekordów w kluczowych tabelach, zakres identyfikatorów, datę najnowszego wpisu i rozmiar plików. Różnice mogą być prawidłowe, jeśli wynikają z wybranego punktu backupu, ale powinny mieć znane wyjaśnienie.

Test funkcjonalny powinien obejmować logowanie aplikacji, odczyt istniejących danych, utworzenie kontrolnego rekordu, aktualizację i usunięcie danych testowych oraz wykonanie operacji korzystających z kluczowych relacji. Należy także zweryfikować zadania cykliczne, procedury, widoki, wyzwalacze i połączenia z usługami zależnymi, o ile są używane przez konkretną aplikację. Warto zmierzyć czas odpowiedzi zapytań, ponieważ brak części indeksów, inny plan wykonania albo odmienne ustawienia pamięci mogą ujawnić problem dopiero pod obciążeniem. Dopiero po pozytywnym teście i potwierdzeniu możliwości wykonania kolejnego backupu można uznać kopię bazy za gotową do pracy produkcyjnej.