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

Ознакомьтесь с рефакторингом баз данных (http://databaserefactoring.com/) за кучу хороших методов для поддержки вашей базы данных в тандеме с изменениями кода.

Достаточно сказать, что вы задаете неправильные вопросы. Вместо того чтобы помещать вашу базу данных в git, вы должны разлагать свои изменения на небольшие проверяемые шаги, чтобы с легкостью изменять параметры переноса/отката.

Если вы хотите иметь полную возможность восстановления, вам следует рассмотреть возможность архивирования ваших журналов WAL-сообщений postgres и использовать PITR (время восстановления по времени), чтобы воспроизводить транзакции в определенных известных состояниях.

Я начинаю думать о действительно простом решении, не знаю, почему я не думал об этом раньше!

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

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

EDIT:

В двух экземплярах я имею в виду создание другой базы данных с другим именем (например, my_db_2); не делая дампа или что-то в этом роде.

Вместо того, чтобы вручную сбросить вашу БД и сохранить ее в git, используйте Offscale DataGrove.

DataGrove - это, в основном, элемент управления версией DB - он отслеживает изменения во всей БД (данные схемы и данных) и позволяет вам помечать версии в репозитории. Вы можете использовать его вместе с git и при этом терять версию каждый раз, когда вы регистрируете код, и загружать правильное состояние БД всякий раз, когда вы извлекаете код.

В частности, в отношении "Редактировать 2" - с помощью DataGrove вы можете просто иметь две ветки БД, по одной для каждой из ветвей кода. Когда вы загружаете определенную ветвь кода, DataGrove автоматически заново создаст все состояние БД со всеми данными внутри этой версии/ветки. Это означает, что вы можете переключаться между ветвями разработки с помощью простой простой команды.

Используйте что-то вроде LiquiBase, это позволяет вам контролировать ревизию файлов Liquibase. вы можете пометить изменения только для производства и иметь lb, чтобы ваша БД была актуальной для производства или разработки (или любой другой схемы, которую вы хотите).

Существует инструмент, который находится под тяжелым развитием под названием Klonio, чья бета-версия доступна для использования. Он поддерживает MongoDB и MySQL на данный момент.

Конечно, он имеет интеграцию git, и вы можете сделать снимок либо вашей схемы в отдельности, либо даже включенных данных.

Существует большой проект под названием "Миграции в доктрине", который был создан именно для этой цели.

Его все еще в альфа-состоянии и построено для php.

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

Взгляните на RedGate SQL Source Control.

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

Этот инструмент представляет собой оснастку SQL Server Management Studio, которая позволит вам разместить вашу базу данных под контролем источника с помощью Git.

Это немного дорого стоит 495 долларов США за пользователя, но есть 28-дневная бесплатная пробная версия.

Примечание Я никоим образом не связан с RedGate.

Я столкнулся с этим вопросом, так как у меня есть аналогичная проблема, где что-то приближается к структуре каталогов на основе DB, хранит "файлы", и мне нужно git, чтобы управлять им. Он распространялся через облако с использованием репликации, поэтому точка доступа будет через MySQL.

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

Git - это система, которая по существу хранит базу данных дельт (различий), которую можно повторно собрать, чтобы воспроизвести контекст. Обычное использование git предполагает, что контекст является файловой системой, и эти дельта различаются в этой файловой системе, но на самом деле все git есть иерархическая база данных дельт (иерархическая, поскольку в большинстве случаев каждая дельта является фиксацией с по меньшей мере 1 родителем, расположенным на дереве).

Пока вы можете генерировать дельта, теоретически git может ее хранить. Обычно проблема git предполагает контекст, в котором он генерирует дельта как файловую систему, и аналогичным образом, когда вы проверяете точку в иерархии git, она ожидает генерации файловой системы.

Если вы хотите управлять изменением, в базе данных у вас есть две дискретные проблемы, и я буду обращаться к ним отдельно (если бы я был вами). Первая - это схема, вторая - данные (хотя в вашем вопросе вы указываете данные не о чем-то, что вас беспокоит). Проблема, с которой я столкнулся в прошлом, - это база данных Dev и Prod, где Dev мог бы внести дополнительные изменения в схему, и эти изменения должны были быть задокументированы в CVS и переданы для жизни вместе с дополнениями к одному из нескольких "статических", столы. Мы сделали это, имея 3-ю базу данных под названием Cruise, в которой содержались только статические данные. В любой момент можно сравнить схему из Dev и Cruise, и мы использовали script, чтобы проанализировать эти два файла и создать SQL файл, содержащий инструкции ALTER, для его применения. Аналогичным образом и новые данные могут быть перенаправлены на файл SQL, содержащий команды INSERT. Пока поля и таблицы добавляются и никогда не удаляются, процесс может автоматизировать создание операторов SQL для применения дельта.

Механизм, посредством которого git создает дельта, diff, и механизм, по которому объединяется 1 или более дельт с файлом, называется merge. Если вы можете придумать метод для различения и слияния из другого контекста, git должен работать, но, как уже обсуждалось, вы можете предпочесть инструмент, который сделает это за вас. Моя первая мысль о решении этой проблемы - это https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#External-Merge-and-Diff-Tools, в котором подробно описывается, как заменить git внутренний инструмент разграничения и слияния. Я обновлю этот ответ, так как я придумал лучшее решение проблемы, но в моем случае я ожидаю, что мне нужно будет только управлять изменениями данных, так как-далеко, поскольку файл-хранилище на базе базы данных может измениться, поэтому мое решение может быть не совсем то, что вам нужно.

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

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

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

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

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

Я буду следить за идеями в этом посте от Владимира Хорикова "Лучшие практики управления версиями баз данных" . В заключение я буду

• хранить как свою схему, так и контрольные данные в системе управления версиями.
• для каждой модификации мы создадим отдельный SQL script с изменениями

В случае, если это поможет!

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

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

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

Когда он дойдет до релиза, администратор войдет на сервер dev, объединит прямую ветвь со всеми разработчиками и необходимые ветки на машине dev в ветку обновлений и вытолкнул ее на тестовый сервер. На тестовом сервере он проверяет, действительно ли процесс обновления для Live-сервера по-прежнему действителен, и быстро передает все трафик в Apache на сайт-заполнитель, создает дамп базы данных, указывает рабочий каталог с "живого" на "обновление" ', выполняет все новые sql файлы в mysql и перенаправляет трафик на правильный сайт. Когда все заинтересованные стороны согласились после проверки тестового сервера, администратор сделал то же самое с тестового сервера на сервер Live. Затем он объединяет живую ветвь на производственном сервере, в ведущую ветку по всем серверам и сворачивает все живые ветки. Разработчики несли ответственность за перераспределение своих веток, но обычно знают, что они делают.

Если на тестовом сервере возникли проблемы, например. в слияниях было слишком много конфликтов, затем код был отменен (указав, что рабочая ветвь вернулась к "live" ), и файлы sql никогда не выполнялись. В тот момент, когда исполнялись файлы sql, в то время это считалось необратимым. Если файлы SQL не работали должным образом, то DB был восстановлен с помощью Dump (и разработчики сказали, для обеспечения плохо протестированных файлов SQL).

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

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

Что я делаю:

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

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

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

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

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

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

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

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

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

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

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

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

$pg_dump --schema ... 

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

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

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

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

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

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

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

Я выпустил инструмент для sqlite, который делает то, о чем вы просите. Он использует настраиваемый драйвер различий, используя инструмент sqlite project 'sqldiff', UUID в качестве первичных ключей и покидает sqlite rowid. Он по-прежнему находится в альфа, поэтому отзывы приветствуются.

Postgres и mysql сложнее, поскольку двоичные данные хранятся в нескольких файлах и могут даже не быть действительными, если вы смогли сделать снимок.

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

Вот что я пытаюсь сделать в своих проектах:

• отдельные данные и схемы и данные по умолчанию.

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

По умолчанию базы данных (для создания новых проектов) - это простой файл SQL под управлением версии.

Для схемы базы данных создайте дамп схемы базы данных под управлением версии.

Наиболее распространенным способом является наличие сценариев обновления, содержащих SQL-выражения, (ALTER Table.. или UPDATE). Вы также должны иметь место в своей базе данных, где вы сохраняете текущую версию вашей схемы)

Взгляните на другие крупные проекты с открытым исходным кодом (piwik или ваша любимая система cms), все они используют updatecripts (1.sql, 2.sql, 3.sh, 4.php.5.sql)

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

Итак, теоретически (и это то, что я ищу) вы могли бы выгрузили схему базы данных после каждого изменения (вручную, conjob, git hooks (возможно, до фиксации)) (и только в некоторых очень особых случаях создаются обновленные сценарии)

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

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

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

Используйте инструмент, например iBatis Migrations (руководство, короткий учебник видео), который позволяет вам управлять версиями изменений, внесенных в базу данных на протяжении всего жизненного цикла проекта, а не самой базы данных.

Это позволяет выборочно применять индивидуальные изменения в разных средах, вести изменения, изменения которых в каких средах, создавать сценарии для применения изменений от A до N, изменения отката и т.д.