Przewodnik po aktualizacji samodzielnie hostowanej bazy danych: zrzut, migawka, migracja i wycofanie zmian

Bezpieczne podejście polega na traktowaniu etapowej aktualizacji z użyciem natywnych zrzutów, migawek pamięci masowej, odizolowanej próby odtworzenia i jasno określonego punktu wycofania jako sekwencji obserwowalnych punktów kontrolnych, a nie pojedynczego polecenia.

W przypadku skonteneryzowanej bazy danych PostgreSQL lub MariaDB na serwerze domowym praktyczne ryzyko polega na konieczności zaktualizowania samodzielnie hostowanej bazy danych bez utraty obiektów logicznych ani realnej ścieżki wycofania. Zapisz bieżącą tożsamość i punkt odzyskiwania, zacznij od najmniej inwazyjnego testu rozróżniającego, zinterpretuj wyniki pozytywne i negatywne przed zmianą kolejnej zmiennej oraz zatrzymaj się, gdy pamięć masowa stanie się niestabilna lub jedyna możliwa do odzyskania kopia byłaby narażona. Poniższa procedura kończy się dopiero wtedy, gdy pierwotne obciążenie działa poprawnie albo dowody osiągną granicę wymagającą eskalacji.

Zdefiniuj zgodność i wycofanie przed wykonaniem kopii zapasowej

Zapisz silnik bazy danych i dokładną wersję źródłową, wersję docelową, wersję aplikacji, rozszerzenia lub wtyczki, zestaw znaków, reguły uwierzytelniania, zaplanowane zadania oraz dostępną długość przestoju. Przeczytaj informacje o aktualizacji aplikacji, a także ścieżkę aktualizacji bazy danych, ponieważ migracja aplikacji może sprawić, że stare pliki binarne będą niezgodne z nowym schematem.

Aktualizacje głównej wersji często wymagają logicznego zrzutu i odtworzenia albo obsługiwanego narzędzia migracji, zamiast montowania starego katalogu danych w nowym obrazie. Niezależny proces aktualizacji głównej wersji bazy danych Compose przedstawia aktualizację głównej wersji PostgreSQL w środowisku Compose i pokazuje, dlaczego stary kontener i wolumin muszą pozostać oddzielone od docelowych.

Zapisz teraz termin i warunek wycofania: nieudane kontrole integralności, brakujące role lub rozszerzenia, błędy aplikacji albo niedopuszczalną wydajność. Wycofanie pozostaje możliwe tylko do momentu rozpoczęcia zapisu danych produkcyjnych w systemie docelowym, chyba że przetestowano plan migracji danych w odwrotnym kierunku.

Utwórz dwa niezależne punkty odzyskiwania

Wykonaj natywną dla silnika logiczną kopię zapasową, uwzględniając obiekty globalne, jeśli ma to zastosowanie, a następnie zapisz polecenie, wersję, kod zakończenia, manifest i sumę kontrolną. Sprawdź, czy uwzględniono użytkowników, uprawnienia, rozszerzenia, schematy, zaplanowane zadania i duże obiekty, zamiast zakładać, że pojedynczy zrzut bazy danych zawiera wszystkie zależności na poziomie serwera.

Utwórz skoordynowaną migawkę lub kopię zatrzymanego woluminu bazy danych po potwierdzeniu, że baza działa w obsługiwanym stanie. Logiczny zrzut zapewnia przenośność i kontrolę na poziomie obiektów, a kopia pamięci masowej zachowuje dokładny punkt wycofania do starej wersji. Żadna z tych kopii nie powinna nadpisywać drugiej.

Skorzystaj z listy kontrolnej weryfikacji ZimaSpace, aby sprawdzić, czy kopia zapasowa bazy danych jest kompletna. Punkt kontrolny kopii zapasowej zostaje zaliczony dopiero wtedy, gdy zrzut można odczytać, zidentyfikowano punkt odzyskiwania z pamięci masowej, a obie kopie są przechowywane poza aktualizowanym woluminem.

Przeprowadź próbę migracji w odizolowanym systemie docelowym

Uruchom docelową bazę danych na oddzielnym woluminie i porcie, zainstaluj wymagane rozszerzenia, odtwórz logiczną kopię zapasową i zapisz każde ostrzeżenie. Instrukcja Percony dotycząca ścieżki aktualizacji z użyciem logicznego zrzutu i odtworzenia podkreśla sekwencję zrzutu i odtworzenia oraz konieczność użycia narzędzi zgodnych z planowaną ścieżką aktualizacji PostgreSQL.

Podłącz tymczasową instancję aplikacji do odtworzonej bazy danych. Przetestuj logowanie, odczyty, zapisy, zadania w tle, wyszukiwanie, załączniki, strefy czasowe i ponowne uruchomienie. Porównaj liczbę wierszy i kluczowe wartości zagregowane, zamiast polegać wyłącznie na pomyślnym kodzie zakończenia odtwarzania.

Nie przechodź dalej, jeśli rozszerzenia są niedostępne, zmiany sortowania nie zostały rozwiązane, migracje kończą się niepowodzeniem lub czas odtwarzania przekracza okno serwisowe. Napraw próbę i utwórz nowy zrzut; środowisko produkcyjne nie jest miejscem na wykrywanie niezgodności z wersją docelową.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Przełącz zapisy i zachowaj czystą możliwość wycofania

Włącz tryb konserwacji, zatrzymaj procesy zapisujące dane i zadania, potwierdź opróżnienie aktywnych połączeń, a następnie utwórz końcowy zrzut lub obsługiwaną kopię różnicową. Odtwórz ją w czystym systemie docelowym, przeprowadź kontrole integralności i obiektów, zaktualizuj połączenie aplikacji oraz uruchom usługi w kolejności zależności.

Obserwuj wskaźniki błędów, blokady, wykonywanie zadań, kopie zapasowe i rzeczywiste transakcje aplikacji. Zachowaj starą bazę danych zatrzymaną i tylko do odczytu, wraz z oryginalnym woluminem i skrótem obrazu. Nigdy nie pozwalaj, aby obie bazy danych przyjmowały niezależne zapisy z użyciem tej samej tożsamości aplikacji.

Ogłoś powodzenie dopiero po pomyślnym przejściu testów aplikacji, natywnego zadania kopii zapasowej, ponownego uruchomienia oraz testowego odtworzenia z nowej wersji. Jeśli warunek wycofania zostanie spełniony przed granicą zapisu, skieruj aplikację z powrotem do zachowanej starej instancji; po rozpoczęciu nowych zapisów zatrzymaj się i skorzystaj z udokumentowanego planu uzgadniania zamiast udawać, że zwykłe ponowne uruchomienie cofnie dane.