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

Ответ 1

Вместо этого возьмите дамп базы данных и контроль версий. Таким образом, это текстовый файл.

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

EDIT:

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

Ответ 4

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

Ответ 5

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

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

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

Ответ 6

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

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

Ответ 7

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

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

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

Ответ 8

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

1. Sqitch - открытый исходный код на основе Perl; доступно для всех основных баз данных, включая PostgreSQL https://github.com/sqitchers/sqitch
2. Mahout - только для PostgreSQL; контроль версий схемы базы данных с открытым исходным кодом. https://github.com/cbbrowne/mahout
3. Liquibase - еще один с открытым исходным кодом управления версиями SW. бесплатная версия Datical. http://www.liquibase.org/index.html
4. Datical - коммерческая версия Liquibase - https://www.datical.com/
5. Flyway by BoxFuse - коммерческий sw. https://flywaydb.org/
6. Еще один проект с открытым исходным кодом https://gitlab.com/depesz/Versioning Автор предоставляет руководство здесь: https://www.depesz.com/2010/08/22/versioning/
7. Red Gate Change Automation - только для SQL Server.https://www.red-gate.com/products/sql-development/sql-change-automation/

Ответ 9

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

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

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

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

Если вы хотите управлять изменениями в базе данных, у вас есть две отдельные проблемы, и я бы решил их отдельно (на вашем месте). Первый - это схема, второй - данные (хотя в вашем вопросе вы заявляете, что данные вас не беспокоят). В прошлом у меня была проблема с базой данных Dev и Prod, в которой Dev мог вносить постепенные изменения в схему, и эти изменения должны были документироваться в CVS и распространяться на них, наряду с дополнениями к одному из нескольких "статических". столы. Мы сделали это, имея третью базу данных под названием Cruise, которая содержала только статические данные. В любой момент можно было сравнить схему из Dev и Cruise, и у нас был сценарий, чтобы взять разность этих двух файлов и создать файл 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 и инструмент слияния. Я обновлю этот ответ, так как я придумаю лучшее решение проблемы, но в моем случае я ожидаю, что мне придется только управлять изменениями данных, поскольку база данных на базе БД может измениться, поэтому мое решение может быть не совсем то, что вам нужно.

Ответ 10

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

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

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

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

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

Ответ 11

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

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

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

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

Ответ 12

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

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

Ответ 13

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

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

Ответ 14

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

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

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

Ответ 15

• Irmin
• Flur.ee
• Crux DB

Некоторое время я искал ту же функцию для Postgres (или баз данных SQL в целом), но не нашел подходящих инструментов (простых и интуитивно понятных). Вероятно, это связано с бинарным характером хранения данных. Клонио звучит идеально, но выглядит мертвым. Noms DB выглядит интересно (и живой). Также взгляните на Irmin (на основе OCaml с Git-свойствами).

Хотя это не дает ответа на вопрос о том, что он будет работать с Postgres, проверьте базу данных Flur.ee. Он имеет функцию "путешествия во времени", которая позволяет запрашивать данные с произвольного момента времени. Я предполагаю, что он должен работать с моделью "ветвления".

Эта база данных была недавно разработана для целей блокчейна. Из-за природы блокчейнов, данные должны записываться с приращением, как и работает git. Они нацелены на релиз с открытым исходным кодом во втором квартале 2019 года.

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

Обновление: также ознакомьтесь с базой данных Crux, которая может выполнять запросы по временному измерению вставок, которые вы можете видеть как "версии". Похоже, что Crux - это реализация высоко оцененной Datomic с открытым исходным кодом.

Crux - это битемпоральная база данных, которая хранит время транзакций и действительные истории времени. В то время как временная база данных [uni] позволяет выполнять запросы "путешествия во времени" через транзакционную последовательность состояний базы данных с момента создания базы данных до ее текущего состояния, Crux также обеспечивает запросы "путешествия во времени" для отдельной действительной оси времени без ненужной сложности проектирования или влияние на производительность. Это означает, что пользователь Crux может заполнить базу данных прошлой и будущей информацией независимо от порядка поступления информации и внести исправления в прошлые записи, чтобы построить постоянно улучшающуюся временную модель данного домена.

Ответ 16

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

$pg_dump --schema ... 

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

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

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

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

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

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

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

Ответ 17

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

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

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

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

Ответ 18

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

Ответ 19

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

Ответ 20

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

Ответ 21

Что я делаю:

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

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

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

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

Ответ 22

Мы использовали веб-сайт социального назначения в стандартной конфигурации 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, но это хорошая идея, если человеческие глаза постоянно контролируют процесс обновления.

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

Ответ 23

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

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

Ответ 24

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

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

Ответ 25

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

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

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

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

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

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

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

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

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

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

Ответ 26

Обновление от 26 августа 2019 года:

Netlify CMS делает это с GitHub, пример реализации можно найти здесь со всей информацией о том, как они это реализовали netlify-cms-backend-github