Czy tworzenie kopii zapasowych bazy danych MySQL w Git jest dobrym pomysłem?

Próbuję poprawić sytuację tworzenia kopii zapasowych mojej aplikacji. Mam aplikację Django i bazę danych MySQL. Przeczytałem artykuł sugerujący utworzenie kopii zapasowej bazy danych w Git.

Z jednej strony podoba mi się to, ponieważ pozwala zachować synchronizację kopii danych i kodu.

Ale Git jest przeznaczony do kodu, a nie do danych. W związku z tym wykona wiele dodatkowej pracy, różnicując zrzut MySQL przy każdym zatwierdzeniu, co nie jest tak naprawdę konieczne. Jeśli skompresuję plik przed zapisaniem, czy nadal będzie różnicował pliki?

(Plik zrzutu jest obecnie 100 MB nieskompresowany, 5,7 MB po skompresowaniu.)

Edycja: definicje kodu i schematu bazy danych są już w Git, to naprawdę dane, których tworzenia kopii zapasowej się obawiam.

Zanim stracisz jakiekolwiek dane, pozwól mi spróbować przedstawić perspektywę sysadmin do tego pytania.

Istnieje tylko jeden powód, dla którego tworzymy kopie zapasowe: aby umożliwić przywracanie, gdy coś pójdzie nie tak, jak zawsze . Jako taki, właściwy system tworzenia kopii zapasowych ma wymagania znacznie wykraczające poza to, co git może rozsądnie obsłużyć.

Oto niektóre problemy, które mogę przewidzieć podczas próby wykonania kopii zapasowej bazy danych w git:

• Repozytorium powiększy się dramatycznie z każdą „kopią zapasową”. Ponieważ git przechowuje całe obiekty (aczkolwiek skompresowane), a następnie różnicuje je później (np. Po uruchomieniu git gc) i zachowuje historię na zawsze , będziesz mieć bardzo dużą ilość przechowywanych danych, których tak naprawdę nie potrzebujesz ani nawet nie chcesz. Może być konieczne ograniczenie ilości lub okresu przechowywania kopii zapasowych, aby zrobić miejsce na dysku lub z powodów prawnych, ale trudno jest usunąć stare wersje z repozytorium git bez dużych szkód ubocznych.
• Przywracanie jest ograniczone do punktów w czasie przechowywanych w repozytorium, a ponieważ dane są tak duże, cofanie się o więcej niż trywialny czas może być powolne. Zaprojektowany w tym celu system tworzenia kopii zapasowych ogranicza ilość przechowywanych danych, potencjalnie zapewniając większą szczegółowość, i zapewnia szybsze przywracanie, zmniejszając przestoje w przypadku awarii. Rozwiązania do tworzenia kopii zapasowych obsługujące bazy danych ( przykład ) mogą również zapewniać ciągłe tworzenie kopii zapasowych, zapewniając, że nie zostanie utracona ani jedna transakcja.
• Zatwierdzenia prawdopodobnie będą również powolne i będą spowalniać w miarę wzrostu bazy danych. Pamiętaj, że git jest zasadniczo magazynem danych klucz-wartość odwzorowanym na system plików , a zatem podlega charakterystyce wydajności bazowego systemu plików. Jest możliwe, że ten czas w końcu przekroczy interwał tworzenia kopii zapasowej, i w tym momencie nie będzie już można spełnić umowy SLA. Odpowiednie systemy tworzenia kopii zapasowych również zajmują więcej czasu, gdy dane rosną, ale nie aż tak dramatycznie, ponieważ automatycznie zarządzają własnym rozmiarem na podstawie skonfigurowanych przez Ciebie zasad przechowywania.

Pomimo faktu, że najwyraźniej istnieje kilka interesujących rzeczy, które możesz zrobić ze zrzutem bazy danych, jeśli umieścisz go w git, ogólnie nie mogę go polecić do przechowywania kopii zapasowych. Zwłaszcza, że systemy tworzenia kopii zapasowych są szeroko dostępne (a wiele z nich jest nawet open source) i działają znacznie lepiej, zapewniając bezpieczeństwo danych i umożliwiając ich jak najszybsze odzyskanie.

Moje dwa centy: nie sądzę, że to dobry pomysł. GIT robi coś podobnego „Zapisywanie migawek z zestawu plików w różnych punktach w czasie”, dzięki czemu można idealnie wykorzystać GIT na coś takiego, ale to nie znaczy, że powinniśmy . GIT został zaprojektowany do przechowywania kodu źródłowego, więc straciłbyś większość jego funkcjonalności, a ty handlowałbyś dużą wydajnością za odrobinę wygody.

Załóżmy, że głównym powodem, dla którego myślisz o tym, jest „zsynchronizowanie kopii danych i kodu”, a to oznacza, że ​​martwisz się, że wersja 2.0 twojego kodu potrzebuje innego schematu bazy danych niż wersja 1.0 . Prostszym rozwiązaniem byłoby przechowywanie schematu bazy danych, jako zestawu skryptów SQL z CREATEinstrukcjami, wzdłuż kodu źródłowego w repozytorium Git. Następnie częścią procedury instalacji byłoby wykonanie tych skryptów na wcześniej zainstalowanym serwerze bazy danych.

Rzeczywista zawartość tych CREATEtabel -d nie ma nic wspólnego z wersją kodu źródłowego. Wyobraź sobie, że instalujesz oprogramowanie w wersji 1.0 na serwerze A i serwerze B, które są używane w różnych firmach przez różne zespoły. Po kilku tygodniach zawartość tabel będzie zupełnie inna, mimo że schematy są dokładnie takie same.

Ponieważ chcesz wykonać kopię zapasową zawartości bazy danych, sugeruję, abyś użył skryptu kopii zapasowej, który otacza zrzut kopii bieżącą wersją oprogramowania, do którego zrzut należy. Skrypt powinien znajdować się w repozytorium GIT (aby miał dostęp do ciągu wersji kodu źródłowego), ale same zrzuty nie należą do systemu kontroli wersji.

EDYCJA :

Po przeczytaniu oryginalnego postu, który uzasadniał pytanie , uważam to za jeszcze bardziej wątpliwy pomysł. Kluczową kwestią jest to, że mysqldumppolecenie przekształca bieżący stan DB w szereg INSERTinstrukcji SQL , a GIT może je różnicować, aby uzyskać tylko zaktualizowane wiersze tabeli.

mysqldumpCzęść jest dobra, ponieważ jest to jedna z metod tworzenia kopii zapasowych wymienionych w dokumentacji MySQL. Część GIT polega na tym, że autor nie zauważa, że ​​serwery bazy danych przechowują dziennik transakcji w celu odzyskiwania po awarii, w tym MySQL . To za pomocą tego dziennika , nie GIT, że należy tworzyć przyrostowe kopie zapasowe w bazie danych. Ma to przede wszystkim tę zaletę, że można obracać lub opróżniać dzienniki po odzyskaniu, zamiast nadmuchiwania repozytorium GIT w nieskończoność i poza nią ...

Osobiście nie sądzę, że dobrym pomysłem jest używanie systemu wersji kontroli źródła do przechowywania plików kopii zapasowych, ponieważ kontrola wersji GIT jest przeznaczona dla plików danych, a nie dla plików binarnych lub plików zrzutu, takich jak plik zrzutu kopii zapasowej MySQL. Fakt, że możesz to zrobić, nie oznacza automatycznie, że powinieneś to zrobić. Co więcej, Twoje repozytorium, biorąc pod uwagę nową kopię zapasową bazy danych dla każdego nowego zatwierdzenia, dramatycznie się powiększy, wykorzystując dużo miejsca na dysku twardym, co wpłynie na wydajność GIT, co spowoduje powolny system kontroli źródła. Dla mnie dobrze jest wykonać strategię tworzenia kopii zapasowych i zawsze mieć gotowy plik kopii zapasowej, gdy trzeba przywrócić bazę danych, gdy coś w kodzie pójdzie nie tak, ale narzędzia kontroli źródła nie są przeznaczone do przechowywania danych binarnych.

Z tych powodów nie widzę żadnego narzędzia do przechowywania plików kopii zapasowej na dzień 1 i na dzień 2, a następnie widzę różnice między dwoma plikami kopii zapasowej. Będzie to wymagało dużo dodatkowej i bezużytecznej pracy. Zamiast używać GIT do przechowywania kopii zapasowych bazy danych podczas zatwierdzania nowego kodu, przechowuj kopie zapasowe bazy danych w innej ścieżce, oddzielone datą i godziną, i wstaw w kodzie odniesienie do nowych kopii zapasowych bazy danych utworzonych dla każdej wersji, używając tagów, jak ktoś już zasugerował.

Moja ostatnia uwaga na temat kopii zapasowych bazy danych i GIT: Administrator bazy danych, gdy musi przywrócić bazę danych, ponieważ niektóre dane zostały utracone, nie musi sprawdzać różnic między plikiem kopii zapasowej dla pierwszego dnia a plikiem kopii zapasowej dla drugiego dnia, musi tylko wiedzieć, która jest ostatni plik kopii zapasowej, który pozwoli mu przywrócić bazę danych, bez błędów i utraty danych, zmniejszając przestoje. W rzeczywistości zadaniem administratora bazy danych jest jak najszybsze udostępnienie danych do odzyskania, gdy system z jakichś powodów ulegnie awarii. Jeśli przechowujesz kopie zapasowe bazy danych w GIT, powiązane ze swoimi zatwierdzeniami, nie pozwalasz administratorowi bazy danych na szybkie przywracanie danych, ponieważ kopie zapasowe są ograniczone do punktów w czasie przechowywanych w repozytorium GIT i skracają przestoje systemu,

Następnie nie zalecam przechowywania kopii zapasowych za pomocą GIT, zamiast tego używaj dobrego oprogramowania do tworzenia kopii zapasowych (jest ich tutaj kilka ), które zapewni większą szczegółowość i pozwoli ci zachować bezpieczeństwo danych odzyskiwanie danych proste i szybkie w przypadku katastrof.

Nie powinieneś przechowywać danych binarnych w Git - szczególnie w bazie danych.
Zmiany kodu i zmiany DML bazy danych to zupełnie inne rzeczy.

MySQL i Oracle mogą zapisywać dzienniki archiwalne w celu przywrócenia do dowolnego momentu w czasie. Po prostu wykonaj kopię zapasową tych dzienników w bezpiecznym miejscu i wszystko będzie dobrze.

Używanie Git do tworzenia kopii zapasowych tych „dzienników archiwów” nie ma sensu. Dzienniki archiwów w środowisku produkcyjnym są dość ciężkie i powinny być usuwane po regularnych pełnych kopiach zapasowych. Również bezużyteczne jest umieszczanie ich w git - są one już w pewnym sensie repozytorium.