Как я могу поместить базу данных в git (контроль версий)?

Question

Я делаю веб-приложение, и мне нужно сделать ветку для некоторых важных изменений, дело в том, что эти изменения требуют изменений в схеме базы данных, поэтому я бы хотел также поместить всю базу данных в git .

Как мне это сделать? есть ли конкретная папка, которую я могу хранить в репозитории git? Как я узнаю какой? Как я могу быть уверен, что ставлю нужную папку?

Мне нужно быть уверенным, потому что эти изменения не имеют обратной совместимости; Я не могу позволить себе облажаться.

База данных в моем случае - PostgreSQL

Edit:

Кто-то предложил создать резервные копии и поместить файл резервной копии под контроль версий вместо базы данных. Если честно, мне очень трудно это проглотить.

Должен быть лучший путь.

Обновление:

ОК, так что лучшего способа нет, но я все еще не совсем уверен, поэтому я немного изменю вопрос:

Я хотел бы поставить всю базу данных под контроль версий, какой механизм базы данных я могу использовать, чтобы я мог поставить реальную базу данных под контроль версий вместо ее дампа?

Будет ли sqlite дружелюбным к людям?

Поскольку это только среда разработки, я могу выбрать любую базу данных, какую захочу.

Edit2:

Что я действительно хочу, так это не отслеживать историю своего развития, а уметь переключаться с моей ветки «новые радикальные изменения» на «текущую стабильную ветку» и, например, исправлять некоторые ошибки / проблемы и т. Д. с текущей стабильной веткой. Таким образом, когда я переключаю ветки, база автоматически становится совместимой с веткой, в которой я сейчас работаю. Меня не особо волнуют фактические данные.

Answer 1

Вы не можете сделать это без атомарности, и вы не можете получить атомарность без использования pg_dump или файловой системы моментальных снимков.

Мой экземпляр postgres находится на zfs, который я иногда снимаю. Это примерно мгновенно и последовательно.

Answer 2

То, что вы хотите, по духу, возможно, является чем-то вроде Post Facto , который хранит версии базы данных в базе данных. Проверьте это презентация .

Проект, по-видимому, никогда и никуда не делся, поэтому, вероятно, он не поможет вам сразу, но это интересная концепция. Я боюсь, что сделать это правильно было бы очень сложно, потому что даже в версии 1 нужно было бы правильно продумать все детали, чтобы люди доверяли им свою работу.

Answer 3

Мы использовали социальный веб-сайт в стандартной конфигурации LAMP. У нас был Live-сервер, тестовый сервер и сервер разработки, а также машины локальных разработчиков. Все управлялись с помощью GIT.

На каждом компьютере у нас были файлы PHP, а также служба MySQL и папка с изображениями, которые пользователи могли загружать. На сервере Live выросло около 100 КБ (!) Повторных пользователей, дамп был около 2 ГБ (!), Папка с изображениями - около 50 ГБ (!). К тому времени, когда я ушел, наш сервер достиг предела своего ЦП, Ram и, самое главное, ограничения одновременных сетевых соединений (мы даже скомпилировали нашу собственную версию драйвера сетевой карты, чтобы максимально использовать сервер 'lol'). Мы не можем ( и вы не предполагаете, что на вашем сайте ) поместить 2 ГБ данных и 50 ГБ изображений в GIT.

Чтобы легко управлять всем этим в GIT, мы игнорировали бы двоичные папки (папки, содержащие изображения), вставляя эти пути к папкам в .gitignore. У нас также была папка с именем SQL вне пути к корню документа Apache. В этой папке SQL мы бы помещали наши файлы SQL от разработчиков в инкрементные нумерации (001.florianm.sql, 001.johns.sql, 002.florianm.sql и т. Д.). Этими файлами SQL управлял также GIT. Первый файл sql действительно будет содержать большой набор схем БД. Мы не добавляем данные пользователя в GIT (например, записи таблицы пользователей или таблицы комментариев), но такие данные, как конфиги или топология, или другие данные, специфичные для сайта, сохранялись в файлах sql (и, следовательно, GIT). В основном это разработчики (которые лучше знают код), которые определяют, что и что не поддерживается GIT в отношении схемы и данных SQL.

Когда дело доходит до выпуска, администратор входит на сервер dev, объединяет ветку live со всеми разработчиками и необходимыми ветвями на машине dev в ветку обновлений и отправляет ее на тестовый сервер. На тестовом сервере он проверяет, все ли действительный процесс обновления для живого сервера, и в быстрой последовательности направляет весь трафик в Apache на сайт-заполнитель, создает дамп БД, указывает рабочий каталог с «живого» на «обновление». ', выполняет все новые sql-файлы в mysql и перенаправляет трафик обратно на правильный сайт. Когда все заинтересованные стороны согласились после проверки тестового сервера, администратор сделал то же самое с тестового сервера на живой сервер. После этого он объединяет живую ветку на рабочем сервере с главной веткой на всех серверах и перебазирует все живые ветви. Разработчики сами отвечали за перебазирование своих веток, но они обычно знают, что делают.

Если были проблемы на тестовом сервере, например. у слияний было слишком много конфликтов, затем код был возвращен (указывая рабочую ветвь обратно на «живую»), и файлы sql никогда не выполнялись. В тот момент, когда были выполнены sql-файлы, в то время это рассматривалось как необратимое действие. Если файлы SQL не работали должным образом, то БД была восстановлена ​​с использованием дампа (и разработчики отговорили его за предоставление плохо проверенных файлов SQL).

Сегодня мы поддерживаем папки sql-up и sql-down с эквивалентными именами файлов, где разработчики должны проверить, что оба обновляемых файла sql могут быть в равной степени понижены. В конечном итоге это может быть выполнено с помощью bash-скрипта, но это хорошая идея, если человеческий глаз следит за процессом обновления.

Это не здорово, но управляемо. Надеюсь, что это дает представление о реальном, практичном, относительно высоком доступном сайте. Будь это немного устаревшим, но все же последующим.

Answer 4

Вот как я это делаю:

Поскольку у вас есть свободный выбор типа БД, используйте файловую БД, например, например. Жар.

Создайте шаблонную базу данных, которая имеет схему, которая соответствует вашей фактической ветви, и сохраните ее в своем хранилище.

При выполнении приложения программно создайте копию базы данных шаблона, сохраните ее в другом месте и просто работайте с этой копией.

Таким образом, вы можете поставить схему БД под контроль версий без данных. И если вы измените свою схему, вам просто нужно изменить шаблон DB

Answer 5

Хранение каждого уровня изменений базы данных при управлении версиями git похоже на нажатие всей базы данных с каждым коммитом и восстановление всей вашей базы данных при каждом извлечении Если ваша база данных настолько подвержена критическим изменениям, и вы не можете позволить себе их потерять, вы можете просто обновить свои хуки pre_commit и post_merge . Я сделал то же самое с одним из моих проектов, и вы можете найти направления здесь .

Answer 6

Что я делаю в своих личных проектах, я сохраняю всю свою базу данных в dropbox, а затем указываю MAMP, рабочий процесс WAMP, чтобы использовать ее прямо оттуда. Таким образом, база данных всегда актуальна, когда мне нужно сделать некоторые развиваются. Но это только для разработчиков! Живые сайты используют собственный сервер для этого, конечно! :)

Answer 7

Я бы порекомендовал neXtep для управления версиями базы данных, у него есть хороший набор документации и форумов, которые объясняют, как установить и встречающиеся ошибки. Я протестировал его для PostgreSQL 9.1 и 9.3, я смог заставить его работать на 9.1, но на 9.3 он не работает.

Answer 8

Я думаю, что X-Istence находится на правильном пути, но есть еще несколько улучшений, которые вы можете внести в эту стратегию. Сначала используйте:

$pg_dump --schema ... 

для выгрузки таблиц, последовательностей и т. Д. И помещения этого файла под контроль версий. Вы будете использовать это для разделения изменений совместимости между вашими ветками.

Затем выполните дамп данных для набора таблиц, которые содержат конфигурацию , необходимую для работы вашего приложения (вероятно, следует пропустить пользовательские данные и т. Д.), Например значения по умолчанию для формы и другие данные, не изменяемые пользователем. , Вы можете сделать это выборочно, используя:

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

Это хорошая идея, потому что репозиторий может стать очень неуклюжим, когда ваша база данных достигает 100 МБ + при выполнении полного дампа данных. Лучшая идея - создать резервную копию более минимального набора данных, который требуется для тестирования вашего приложения. Однако если ваши данные по умолчанию очень большие, это может вызвать проблемы.

Если вам абсолютно необходимо разместить полные резервные копии в репозитории, рассмотрите возможность сделать это в ветке за пределами вашего исходного дерева. Хотя для этого лучше всего подойдет внешняя система резервного копирования с некоторой ссылкой на соответствующий svn rev.

Кроме того, я предлагаю использовать дампы текстового формата поверх двоичного в целях ревизии (по крайней мере, для схемы), поскольку их легче различать. Вы всегда можете сжать их, чтобы сэкономить место перед регистрацией.

Наконец, взгляните на документацию по резервному копированию postgres , если вы этого еще не сделали. То, как вы комментируете резервное копирование «базы данных», а не дампа, заставляет меня задуматься о том, думаете ли вы о резервном копировании на основе файловой системы (см. Раздел 23.2 , где приведены предупреждения).

Answer 9

На этот вопрос довольно много ответов, но я хотел бы дополнить ответ X-Istence и Dana the Sane небольшим предложением.

Если вам нужен контроль версий с некоторой степенью детализации, скажем, ежедневно, вы можете связать дамп текста обеих таблиц и схемы с помощью инструмента, подобного rdiff-backup , который выполняет инкрементное резервное копирование. Преимущество состоит в том, что вместо хранения снимков ежедневных резервных копий вы просто сохраняете отличия от предыдущего дня.

При этом вы получаете преимущество контроля версий и не тратите слишком много места.

В любом случае, использование git напрямую для больших плоских файлов, которые очень часто меняются, не является хорошим решением. Если ваша база данных станет слишком большой, у git начнутся проблемы с управлением файлами.

Answer 10

Я бы хотел поставить всю базу данных под контроль версий, что ядро базы данных я могу использовать, чтобы я мог поставить фактическую базу данных под контроль версий вместо его дампа?

Это не зависит от ядра базы данных. Microsoft SQL Server предлагает множество программ контроля версий. Я не думаю, что эту проблему можно решить с помощью git, вы должны использовать систему контроля версий для конкретной схемы pgsql. Я не знаю, существует такая вещь или нет ...