Jak Mogę umieścić bazę danych pod git (Kontrola wersji)?

Sprawdź Refaktoryzacyjne bazy danych ( http://databaserefactoring.com/) za kilka dobrych technik utrzymania bazy danych w połączeniu ze zmianami kodu.

Wystarczy powiedzieć, że zadajesz złe pytania. Zamiast umieszczać swoją bazę danych w git powinieneś rozkładać swoje zmiany na małe możliwe do zweryfikowania kroki, dzięki czemu możesz łatwo migrować/wycofywać zmiany schematu.

Jeśli chcesz mieć pełną możliwość odzyskiwania powinieneś rozważyć archiwizację swojego postgres Wal loguje i używa PITR (point in time recovery) do odtwarzania transakcji back / forward do określonych znanych stanów dobrych.

Zaczynam myśleć o naprawdę prostym rozwiązaniu, Nie wiem dlaczego nie pomyślałem o tym wcześniej!!

• Duplikuj bazę danych, (zarówno schemat, jak i dane).
• w gałęzi dla new-major-changes, po prostu zmień konfigurację projektu, aby użyć nowej duplikowanej bazy danych.

W ten sposób mogę przełączać gałęzie bez martwienia się o zmiany schematu bazy danych.

EDIT:

Przez duplikat, mam na myśli utworzenie innej bazy danych o innej nazwie (np. my_db_2); nie robiąc śmietnika ani nic w tym stylu.

Zamiast ręcznego wrzucania DB i zapisywania go w git, użyj Offscale DataGrove .

DataGrove jest w zasadzie kontrolą wersji DB - śledzi zmiany w całym DB (schemacie i danych) i pozwala na tagowanie wersji do jego repozytorium. Możesz używać go razem z Gitem i kazać mu oznaczać wersję za każdym razem, gdy sprawdzasz kod, i ładować odpowiedni stan DB za każdym razem, gdy ściągasz kod.

Konkretnie odnośnie "Edit 2" - z DataGrove można po prostu mieć dwie gałęzie DB, po jednym dla każdej z gałęzi kodu. Po załadowaniu określonej gałęzi kodu, DataGrove automatycznie utworzy cały stan DB, ze wszystkimi danymi wewnątrz tej wersji / gałęzi. Oznacza to, że możesz przełączać się między gałęziami rozwoju za pomocą jednego, prostego polecenia.

Użyj czegoś w rodzaju LiquiBase to pozwala zachować kontrolę nad poprawkami plików Liquibase. możesz oznaczyć zmiany tylko dla produkcji i poprosić lb o aktualizowanie bazy danych dla produkcji lub rozwoju(lub dowolnego schematu).

Istnieje narzędzie, które jest w fazie rozwoju o nazwie Klonio , którego wersja beta jest dostępna do użytku. Od teraz obsługuje MongoDB i MySQL.

Oczywiście, posiada integrację z git i możesz zrobić migawkę albo samego schematu, albo nawet zawartych w nim danych.

Istnieje wielki projekt o nazwie migracje w doktrynie, który zbudowany właśnie w tym celu.

Its still in alpha state and built for php.

Http://docs.doctrine-project.org/projects/doctrine-migrations/en/latest/index.html

Spójrz na RedGate SQL Source Control.

Http://www.red-gate.com/products/sql-development/sql-source-control/

To narzędzie jest przystawką SQL Server Management Studio, która pozwoli Ci umieścić bazę danych pod kontrolą źródła za pomocą Gita.

Uwaga Nie jestem związany z RedGate w żaden sposób.

Natknąłem się na to pytanie, ponieważ mam podobny problem, gdzie coś zbliżonego do struktury katalogów bazującej na DB, przechowuje 'pliki' i potrzebuję git do zarządzania nim. Jest rozproszony, w chmurze, za pomocą replikacji, stąd jego punkt dostępu będzie przez MySQL.

Treść powyższych odpowiedzi wydaje się podobnie sugerować alternatywne rozwiązanie zadanego problemu, który trochę mija się z celem użycia Gita do zarządzania czymś w bazie danych, więc postaram się odpowiedzieć to pytanie.

Git jest systemem, który w istocie przechowuje bazę delt (różnic), którą można ponownie złożyć, aby odtworzyć kontekst. Normalne użycie git zakłada, że context jest systemem plików, a delty są diffami w tym systemie plików, ale tak naprawdę wszystko git jest hierarchiczną bazą danych delt (hierarchiczną, ponieważ w większości przypadków każda delta jest commitem z co najmniej 1 rodzicami, ułożonymi w drzewie).

Tak długo, jak można wygenerować deltę, w teoria, git może ją przechowywać. Problem polega na tym, że git spodziewa się, że kontekst, na którym generuje pliki delta, będzie systemem plików, i podobnie, gdy wykupujesz punkt w hierarchii git, oczekuje wygenerowania systemu plików.

Jeśli chcesz zarządzać zmianami, w bazie danych, masz 2 dyskretne problemy ,a ja bym je rozwiązał osobno (gdybym był tobą). Pierwszy to schemat, drugi to dane (chociaż w twoim pytaniu dane nie są czymś, o co się martwisz). A problemem, który miałem w przeszłości, była baza danych Dev i Prod, gdzie Dev mógł wprowadzać przyrostowe zmiany do schematu, a te zmiany musiały być udokumentowane w CVS i propogowane do życia, wraz z dodatkami do jednej z kilku "statycznych" tabel. Zrobiliśmy to, mając trzecią bazę danych, zwaną Cruise, która zawierała tylko dane statyczne. W każdym momencie można było porównać schemat z Dev i Cruise, a my mieliśmy skrypt, który pobierał różnice między tymi 2 plikami i produkował plik SQL zawierający ALTER oświadczenia, aby go zastosować. Podobnie wszelkie nowe dane mogą być wydestylowane do pliku SQL zawierającego polecenia INSERT. Dopóki pola i tabele są tylko dodawane i nigdy nie usuwane, proces może zautomatyzować generowanie poleceń SQL w celu zastosowania delty.

Mechanizm, za pomocą którego git generuje delty to diff, a mechanizm, za pomocą którego łączy 1 lub więcej delt z plikiem, nazywa się merge. Jeśli możesz wymyślić metodę różnicowania i scalania z innego kontekstu, git powinno działać, ale jak już zostało omówione, możesz preferować narzędzie, które robi to za Ciebie. Moja pierwsza myśl do rozwiązania jest to https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#External-Merge-and-Diff-Tools który opisuje jak zastąpić wewnętrzne narzędzie do różnicowania i scalania Gita. Zaktualizuję tę odpowiedź, ponieważ wymyślę lepsze rozwiązanie problemu, ale w moim przypadku spodziewam się tylko zarządzać zmianami danych, w-jak na razie - ponieważ plik bazujący na DB może się zmienić, więc mój rozwiązanie może nie być dokładnie tym, czego potrzebujesz.

Nie można tego zrobić bez atomicity, i nie można uzyskać atomicity bez użycia pg_dump lub snapshotting systemu plików.

Moja instancja postgres jest na zfs, który migawkę od czasu do czasu. Jest w przybliżeniu natychmiastowy i spójny.

To, co chcesz, w duchu, jest być może czymś w rodzaju Post Facto, który przechowuje wersje bazy danych w bazie danych. Sprawdź prezentację .

Projekt najwyraźniej nigdzie się nie udał, więc prawdopodobnie nie pomoże ci od razu, ale to ciekawa koncepcja. Obawiam się, że zrobienie tego właściwie byłoby bardzo trudne, ponieważ nawet Wersja 1 musiałaby dobrze znać wszystkie szczegóły, aby ludzie zaufali jej swojej pracy.

Wydałem narzędzie do sqlite, które robi to, o co prosisz. Używa niestandardowego sterownika różnicowego wykorzystującego narzędzie projektów SQLite 'sqldiff', uuid jako klucze podstawowe i pozostawia SQLite rowid. Jest nadal w alfie, więc opinie są mile widziane.

Postgres i mysql są trudniejsze, ponieważ dane binarne są przechowywane w wielu plikach i mogą nawet nie być poprawne, jeśli udało Ci się zrobić migawkę.

Https://github.com/cannadayr/git-sqlite

Chcę zrobić coś podobnego, dodać zmiany w bazie danych do mojego systemu kontroli wersji.

• przechowuje zarówno jego schemat, jak i dane referencyjne w systemie kontroli źródła.
• dla każdej modyfikacji stworzymy osobny skrypt SQL ze zmianami

Na wypadek, gdyby to pomogło!

Myślę, że X-Istence jest na dobrej drodze, ale jest jeszcze kilka ulepszeń, które możesz wprowadzić do tej strategii. Pierwsze użycie:

$pg_dump --schema ... 

Aby zrzucić tabele, sekwencje itp. i umieścić ten plik pod kontrolą wersji. Użyjesz tego do oddzielenia zmian zgodności między gałęziami.

Następnie wykonaj zrzut danych dla zestawu tabel zawierających konfigurację wymaganą do działania aplikacji( prawdopodobnie powinna pomijać dane użytkownika itp.), np. i inne dane, które nie mogą być modyfikowane przez użytkownika. Można to zrobić selektywnie, używając:

$pg_dump --table=.. <or> --exclude-table=..

Jest to dobry pomysł, ponieważ repo może stać się naprawdę niezgrabny, gdy baza danych osiągnie 100Mb + podczas robienia pełnego zrzutu danych. Lepszym pomysłem jest utworzenie kopii zapasowej bardziej minimalnego zestawu danych potrzebnych do przetestowania aplikacji. Jeśli domyślne dane są bardzo duże, może to nadal powodować problemy.

Jeśli koniecznie musisz umieścić pełne kopie zapasowe w repo, rozważ zrobienie tego w oddziale Na Zewnątrz z twojego drzewa źródeł. Zewnętrzny system tworzenia kopii zapasowych z pewnym odniesieniem do pasującego SVN rev jest prawdopodobnie najlepszy do tego.

Sugeruję również użycie zrzutów w formacie tekstowym nad binarnymi do celów rewizji (przynajmniej dla schematu), ponieważ są one łatwiejsze do odróżnienia. Zawsze możesz je skompresować, aby zaoszczędzić miejsce przed odprawą.

Na koniec zajrzyj do dokumentacji postgres backup Jeśli jeszcze tego nie zrobiłeś. Sposób, w jaki komentujesz tworzenie kopii zapasowej "bazy danych" raczej niż zrzut sprawia, że zastanawiam się, czy myślisz o kopii zapasowych opartych na systemie plików (patrz sekcja 23.2 za zastrzeżenia).

To pytanie jest dość dużo odpowiedzi, ale chciałbym uzupełnić X-Istence i Dana Sane ' s odpowiedź z małą sugestią.

Jeśli potrzebujesz kontroli wersji z pewnym stopniem szczegółowości, powiedzmy codziennie, możesz połączyć zrzut tekstu zarówno tabel, jak i schematu za pomocą narzędzia rdiff-backup, które wykonuje przyrostowe kopie zapasowe. Zaletą jest to, że zamiast zapisywać migawki codziennych kopii zapasowych, po prostu przechowujesz różnice w stosunku do poprzednich dzień.

Dzięki temu masz zarówno przewagę kontroli wersji, jak i nie marnujesz zbyt dużo miejsca.

W każdym razie używanie Gita bezpośrednio na dużych płaskich plikach, które zmieniają się bardzo często, nie jest dobrym rozwiązaniem. Jeśli twoja baza danych stanie się zbyt duża, git zacznie mieć problemy z zarządzaniem plikami.

Polecam neXtep dla wersji kontrolującej bazę danych posiada dobry zestaw dokumentacji i forów, które wyjaśniają jak zainstalować i napotkane błędy. Testowałem go dla postgreSQL 9.1 i 9.3, udało mi się go uruchomić dla 9.1, ale dla 9.3 nie wydaje się działać.

To, co robię w moich osobistych projektach, to przechowywanie całej mojej bazy danych w dropbox, a następnie wskazywanie MAMP, WAMP workflow, aby z niego korzystać.. W ten sposób baza danych jest zawsze aktualna, gdzie kiedykolwiek muszę zrobić trochę rozwoju. Ale to tylko dla Deva! Live sites używa do tego własnego serwera! :)

Przechowywanie każdego poziomu zmian w bazie danychpod kontrolą wersjonowania git jest jak przepychanie całejbazy danych z każdym zatwierdzeniem i Przywracanie całej bazy danych z każdym wyciągnięciem. Jeśli twoja baza danych jest tak podatna na istotne zmiany i nie możesz sobie pozwolić na ich utratę, możesz po prostu zaktualizować swoje Hooki pre_commiti post_merge. To samo zrobiłem z jednym z moich projektów, a wskazówki znajdziesz tutaj .

Tak to robię:

Ponieważ masz wolny wybór o typie DB użyj pliku DB, jak np. firebird.

Utwórz szablon DB, który ma schemat pasujący do Twojej gałęzi i zapisz go w repozytorium.

Podczas programowego wykonywania aplikacji Utwórz kopię szablonu DB, przechowuj ją gdzie indziej i po prostu pracuj z tą kopią.

W ten sposób możesz umieścić swój schemat DB pod kontrolą wersji bez danych. A jeśli zmienisz swój schemat wystarczy zmienić szablon DB

Prowadziliśmy stronę społecznościową, w standardowej konfiguracji LAMP. Mieliśmy serwer na żywo, serwer testowy i serwer programistyczny, a także lokalne maszyny programistyczne. Wszystko było zarządzane za pomocą Gita.

Na każdej maszynie mieliśmy Pliki PHP, ale także usługę MySQL i folder z obrazami, które użytkownicy przesyłali. Serwer Live urósł do około 100K (!) użytkowników, zrzut wynosił około 2GB (!), folder Obrazkowy miał około 50GB (!). Zanim wyjechałem, nasz serwer był osiągnięcie limitu CPU, pamięci Ram, a przede wszystkim jednoczesnych limitów połączeń sieciowych (skompilowaliśmy nawet własną wersję sterownika karty sieciowej, aby maksymalnie wykorzystać serwer "lol"). Nie możemy (ani nie powinieneś zakładać, że ze swoją stroną internetową) umieścić 2GB danych i 50GB obrazów w GIT.

Aby łatwo zarządzać tym wszystkim pod Gitem, zignorowalibyśmy binarne foldery (foldery zawierające obrazy), wstawiając te ścieżki do folderów .gitignore. Mieliśmy również folder o nazwie SQL poza Ścieżka documentroot Apache. W tym folderze SQL umieszczamy nasze pliki SQL od programistów w numerach przyrostowych (001.florianm.sql, 001.johns.sql, 002.florianm.sql, itp.). Te pliki SQL były zarządzane przez GIT, jak również. Pierwszy plik sql rzeczywiście zawiera duży zestaw schematu DB. Nie dodajemy danych użytkownika w GIT (np. rekordów tabeli users, czy tabeli comments), ale dane takie jak configs, topologia czy inne dane specyficzne dla witryny, były przechowywane w plikach sql (a więc przez GIT). Głównie jego deweloperzy (którzy znają kod najlepiej), które określają, co i co nie jest utrzymywane przez GIT w odniesieniu do schematu SQL i danych.

Kiedy pojawiła się wersja, administrator loguje się do serwera deweloperskiego, łączy gałąź live ze wszystkimi deweloperami i potrzebnymi gałęziami na maszynie deweloperskiej z gałęzią aktualizacji i przenosi ją na serwer testowy. Na serwerze testowym sprawdza, czy proces aktualizacji dla serwera aktywnego jest nadal ważny i szybko wskazuje cały ruch w Apache do witryny zastępczej tworzy zrzut DB, wskazuje katalog roboczy z "live" na "update", wykonuje wszystkie nowe pliki sql do mysql i ponownie przenosi ruch z powrotem do właściwej strony. Gdy wszyscy interesariusze zgodzili się po przejrzeniu serwera testowego, Administrator zrobił to samo z serwera testowego na serwer aktywny. Następnie łączy live branch na serwerze produkcyjnym, do master branch across all servers I rebased all live Branch. Deweloperzy byli odpowiedzialni sami rebase swoje gałęzie, ale na ogół wiedzą, co robią.

Jeśli wystąpiły problemy na serwerze testowym, np. połączenia miały zbyt wiele konfliktów, następnie kod został przywrócony (wskazując działającą gałąź z powrotem na "live") i pliki sql nigdy nie zostały wykonane. W momencie, gdy pliki sql zostały wykonane, było to uważane za nieodwracalne działanie w tym czasie. Jeśli pliki SQL nie działały poprawnie, to DB został przywrócony za pomocą zrzutu (a deweloperzy za dostarczenie źle przetestowanych plików SQL).

Obecnie utrzymujemy zarówno folder SQL-up, jak i SQL-down, z równoważnymi nazwami plików, w których programiści muszą sprawdzić, czy zarówno aktualizujące się pliki sql mogą być równie obniżone. To może być ostatecznie wykonane ze skryptem bash, ale jego dobry pomysł, jeśli ludzkie oczy przechowywane monitorowanie procesu aktualizacji.

Nie jest świetny, ale da się go opanować. Mam nadzieję, że daje to wgląd w rzeczywistą, praktyczną, stosunkowo wysoką dostępność witrynę. Być nieco przestarzałe, ale nadal przestrzegane.

Użyj narzędzia takiego jak iBatis Migrations (manual, Krótki film instruktażowy), który pozwala na kontrolę wersji zmian wprowadzanych do bazy danych w całym cyklu życia projektu, a nie samej bazy danych.

Pozwala to na selektywne stosowanie poszczególnych zmian w różnych środowiskach, prowadzenie dziennika zmian, w których są zmiany, tworzenie skryptów do stosowania zmian od A do N, wycofywanie zmian itp.

Chciałbym umieścić całą bazę danych pod kontrolą wersji, co silnik bazy danych mogę użyć tak, że mogę umieścić rzeczywistą bazę danych pod Kontrola wersji zamiast zrzutu?

Nie jest to zależne od silnika bazy danych. Przez Microsoft SQL Server istnieje wiele programów do kontroli wersji. Nie wydaje mi się, aby ten problem można było rozwiązać za pomocą Gita, musisz użyć specyficznego dla pgsql systemu kontroli wersji schematu. Nie wiem, czy coś takiego istnieje, czy nie...

Oto co staram się robić w moich projektach:

• oddzielne Dane i schemat i dane domyślne.

Konfiguracja bazy danych jest przechowywana w pliku konfiguracyjnym, który nie jest pod kontrolą wersji (.gitignore)

Domyślną bazą danych (do tworzenia nowych projektów) jest prosty plik SQL pod kontrolą wersji.

Dla schematu bazy danych utwórz zrzut schematu bazy danych pod kontrolą wersji.

Najczęstszym sposobem jest posiadanie skryptów update, które zawiera polecenia SQL, (ALTER Table.. lub aktualizacji). Musisz również mieć miejsce w bazie danych, gdzie zapisujesz bieżącą wersję schematu)

Spójrz na inne duże projekty baz danych open source (piwik, lub twój ulubiony system cms), wszystkie używają skryptów updatescripts (1.sql,2. sql,3.sh,4. php. 5. sql)

Ale to bardzo czasochłonne zadanie, musisz stworzyć i przetestować Skrypty updatescript i musisz uruchomić wspólny skrypt updatescript, który porównuje wersję i uruchamia wszystkie niezbędne Aktualizuj Skrypty.

Więc teoretycznie (i tego właśnie szukam) można zrzucił schemat bazy danych po każdej zmianie (ręcznie, conjob, Git Hooki (może przed zatwierdzeniem)) (i tylko w niektórych bardzo szczególnych przypadkach tworzyć skrypty updatescripts)

Następnie we wspólnym skrypcie updatescript (Uruchom normalne Skrypty updatescripty, dla szczególnych przypadków), a następnie porównaj Schematy (zrzut i bieżąca baza danych), a następnie automatycznie Wygeneruj nessesary Alter. Jest kilka narzędzi, które mogę to zrobić, ale nie znalazłem jeszcze dobrego.

W obliczu podobnej potrzeby i oto co moje badania nad systemami kontroli wersji baz danych wyrzuciły:

1. sqitch-oparte na perlu open source; dostępne dla wszystkich głównych baz danych, w tym PostgreSQL https://github.com/sqitchers/sqitch
2. Mahout-tylko dla PostgreSQL; Kontrola wersji schematu bazy danych open source. https://github.com/cbbrowne/mahout
3. Liquibase-kolejny open source db version control SW. darmowa wersja Datical. http://www.liquibase.org/index.html
4. Datical-komercyjna wersja Liquibase- https://www.datical.com/
Flyway by BoxFuse-commercial sw. https://flywaydb.org/
5. kolejny projekt open source https://gitlab.com/depesz/Versioning Autor dostarcza poradnik tutaj: https://www.depesz.com/2010/08/22/versioning/
6. Automatyka zmiany Red Gate - tylko dla SQL Server. https://www.red-gate.com/products/sql-development/sql-change-automation/