Является ли резервное копирование базы данных MySQL в Git хорошей идеей?

57

Я пытаюсь улучшить ситуацию резервного копирования для моего приложения. У меня есть приложение Django и база данных MySQL. Я прочитал статью, в которой предлагается создать резервную копию базы данных в Git.

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

Но Git предназначен для кода, а не для данных. Таким образом, он будет проделывать большую дополнительную работу, анализируя дамп MySQL при каждом коммите, что не является действительно необходимым. Если я сожму файл перед его сохранением, будет ли git по-прежнему различать файлы?

(Файл дампа в настоящее время 100 МБ без сжатия, 5,7 МБ при сжатии.)

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

wobbily_col
источник
13
Если в вашей компании есть отдел ИТ (ops), они должны с этим справиться.
Майкл Хэмптон
1
является частью данных приложения, или что создается с помощью приложения?
Уинстон Эверт
1
Git будет пытаться отразить все файлы при запуске git gc(или в его основе git repack; по конфигурируемым по умолчанию git будет запускать его автоматически). Кроме того, они всегда будут выкачивать их , поэтому лучше хранить их без сжатия.
Ян Худек
1
Что это за база данных: это база данных производства или разработки?
el.pescado
6
viget.com/extend/backup-your-database-in-git , он «старший разработчик».
wobbily_col

Ответы:

101

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

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

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

  • Хранилище будет резко расти с каждой «резервной копией». Так как git хранит целые объекты (пусть и сжатые), а затем разыскивает их позже (например, при запуске git gc) и сохраняет историю навсегда , у вас будет храниться очень большой объем данных, который вам на самом деле не нужен или даже не нужен. Возможно, вам придется ограничить количество или срок хранения резервных копий, которые вы делаете, чтобы сэкономить место на диске или по юридическим причинам, но трудно удалить старые ревизии из git-репозитория без большого сопутствующего ущерба.
  • Восстановление ограничено моментами времени, которые вы сохранили в репозитории, и, поскольку данные настолько велики, возврат назад более чем на тривиальное время может быть медленным. Система резервного копирования, разработанная для этой цели, ограничивает объем хранимых данных, потенциально обеспечивая большую степень детализации, и обеспечивает более быстрое восстановление, сокращая время простоя в случае аварии. Решения резервного копирования с учетом базы данных ( пример ) также могут обеспечить непрерывное резервное копирование, гарантируя, что ни одна транзакция не будет потеряна.
  • Коммиты, вероятно, также будут медленными и медленными по мере роста базы данных. Помните, что git - это, по сути, хранилище данных «ключ-значение», сопоставленное с файловой системой , и, следовательно, зависит от характеристик производительности базовой файловой системы. Возможно, что в течение этого промежутка времени будет превышен интервал резервного копирования, и в этот момент вы больше не сможете соответствовать своему SLA. Надлежащим системам резервного копирования также требуется больше времени для резервного копирования по мере роста данных, но не так резко, поскольку они будут автоматически управлять своим собственным размером в соответствии с политикой хранения, которую вы настроили.

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

Майкл Хэмптон
источник
Это лучший ответ, поскольку Майкл рассмотрел вопросы согласованности. В зависимости от размера и использования базы данных снимок не может надежно воспроизвести данные в данный момент времени, и вы, вероятно, столкнетесь с проблемами ограничения. Репликация может быть чем-то, что вы хотите посмотреть - dev.mysql.com/doc/refman/5.0/en/replication.html
Аарон Ньютон
4
Это не просто лучший ответ, это единственный ответ. Как правило, вы разработчик, поэтому резервное копирование не ваше дело; кто-то еще (или должен быть) уже присматривает за ними, и если вы начнете вмешиваться, возможно, вы вмешиваетесь в систему, которая уже работает. Эти ящики уже должны быть зарезервированы, так что у вас будет резервная копия, ваша собственная резервная копия и резервная копия вашей собственной резервной копии, все с постоянно увеличивающимся размером. Это просто чокнутый. Плюс: вы разработчик: почему вы (вероятно) подходите к производственным коробкам?
Максимус Минимус
2
@JimmyShelter Существует точка зрения, что DevOps означает не то, что Dev и Ops тесно сотрудничают, а то, что Dev на самом деле делает Ops. Обычно это не работает хорошо, но это не мешает людям пробовать это.
Майкл Хэмптон
Это должен быть принятый ответ. Он четко объясняет требования и назначение системы резервного копирования, а затем показывает, как git не подходит. Дополнительные бонусные баллы за обсуждение последовательности и производительности.
Габриэль Бауман
Позвольте мне отметить, что я опубликовал свой ответ, предполагая, что у ОП нет оперативной группы, которая могла бы решить эту проблему для него. Я согласен с вами, что такую ​​задачу лучше оставить тем, кто на самом деле работает с системой и знает, как ее обойти. Но есть ситуации, когда вам нужно надеть шляпу, которая не совсем ваша, и я верю, что в этой ситуации лучше попытаться изучить некоторые лучшие практики, чем просто придумать собственное придуманное решение. Я должен сказать, что я также нашел ваш ответ очень поучительным!
Logc
39

Мои два цента: я не думаю, что это хорошая идея. GIT делает что-то вроде «хранения снимков набора файлов в разные моменты времени», так что вы можете идеально использовать GIT для чего-то подобного, но это не значит, что вы должны это делать . GIT предназначен для хранения исходного кода, поэтому вам будет не хватать большей части его функциональности, и вы будете торговать большой производительностью ради небольшого удобства.

Позвольте мне предположить, что основная причина, по которой вы думаете об этом, заключается в том, чтобы «держать копию данных и код в синхронизации», и это означает, что вы обеспокоены тем, что для версии 2.0 вашего кода требуется схема базы данных, отличная от версии 1.0 , Более простым решением было бы сохранить схему базы данных в виде набора сценариев SQL с CREATEинструкциями вместе с исходным кодом в вашем хранилище Git. Затем частью вашей процедуры установки будет выполнение этих сценариев на ранее установленном сервере базы данных.

Фактическое содержимое этих CREATEтаблиц просто -d не имеет ничего общего с версией вашего исходного кода. Представьте, что вы устанавливаете программное обеспечение версии 1.0 на сервер A и сервер B, которые используются в разных компаниях разными группами. Через несколько недель содержимое таблиц будет сильно отличаться, даже если схемы в точности совпадают.

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

РЕДАКТИРОВАТЬ :

Прочитав оригинальный пост, мотивировавший вопрос , я нахожу это еще более сомнительной идеей. Ключевым моментом является то, что mysqldumpкоманда преобразует текущее состояние БД в серию операторов SQL INSERT, и GIT может их преобразовать, чтобы получить только обновленные строки таблицы.

Эта mysqldumpчасть является надежной, поскольку это один из методов резервного копирования, перечисленных в документации MySQL. В части GIT автор не замечает, что серверы баз данных ведут журнал транзакций для восстановления после сбоев, включая MySQL . Именно используя этот журнал , а не GIT, вы должны создавать инкрементные резервные копии для своей базы данных. Это, в первую очередь, имеет то преимущество, что вы можете вращать или сбрасывать журналы после восстановления, а не раздувать репозиторий GIT до бесконечности и далее ...

logc
источник
2
Я не уверен, что вижу смысл хранить схему базы данных без данных в системе контроля версий. Данные - это самая важная вещь, и это то, что я хочу сделать резервную копию. Однако мне нравится идея пометить резервную копию базы данных текущей версией программного обеспечения. Я постараюсь реализовать что-то подобное.
wobbily_col
10
Смысл хранения схемы без данных заключается в том, что сразу после установки ваше программное обеспечение должно быть «готово к использованию». Если это вики, то он должен быть готов начать создавать вики-страницы и что-то в них писать. Если вы устанавливаете схему и содержимое, то ваша вики уже заполнена X вики-страницами после установки ... Это не совсем «установка вики-системы для написания нашего контента», но «копирование вики откуда-то для ее чтения» ,
журнал
3
Это может быть хорошей идеей для изменения вашего вопроса в соответствии с фактической ситуацией, в которой вы находитесь. Даже если вы не можете опубликовать все детали, важно указать, что вам нужно много данных, чтобы они не изменялись в каждой установке, или есть одна установка ...
logc
2
@wobbily_col Нетекстовый двоичный формат имеет ограниченную ценность в контексте контроля версий. Вы не можете разнести это, вы не можете разветвить / объединить и т. Д. Итак, хотя вы, безусловно, МОЖЕТЕ использовать git для хранения БД, большинство людей предпочитают создавать сценарии структуры БД, а также необходимые данные. Это компромисс между немного большей работой, но предоставлением приведенного выше списка функций. Вам придется взвесить, является ли это хорошей идеей для вашего решения. В противном случае вы можете получить GIT для непосредственного хранения БД, но это не совсем подходит для этой задачи.
Даниэль Б,
3
@RaduMurzea: Я думаю, что это вопрос принципов. Система контроля версий предназначена для управления исходным кодом, а не двоичными файлами, вот и все. Это не вопрос размера. Нет, дампы базы данных не должны регистрироваться в репозитории, также как и обучающие видео тоже не должны регистрироваться. Но никто не мешает вам сделать это. :)
logc
7

Лично я не считаю хорошей идеей использовать систему управления версиями для хранения файлов резервных копий, потому что система контроля версий GIT предназначена для файлов данных, а не для двоичных файлов или файлов дампа, таких как файл дампа резервного копирования MySQL. Тот факт, что вы можете это сделать, не означает автоматически, что вы должны это делать. Более того, ваш репозиторий, с учетом новой резервной копии базы данных для каждого нового коммита, будет резко расти, занимая много места на жестком диске, и это повлияет на производительность GIT, что приведет к медленной системе управления исходным кодом. Для меня хорошо выполнить стратегию резервного копирования и всегда иметь готовый файл резервной копии, когда вам нужно восстановить базу данных, если что-то в вашем коде идет не так, но инструменты контроля версий не предназначены для хранения двоичных данных.

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

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

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

Альберто Солано
источник
Может быть, downvoter объяснит, почему он / она отказался от голосования ..
Альберто Солано
1
Не нижестоящий, но я думаю, что этот подход привносит постоянный конфликт слияний, который не особенно способствует рабочему процессу с частыми слияниями, который предпочитает большинство пользователей git.
Даниэль Б,
@DanielB Я предлагаю не использовать систему контроля версий для хранения файлов резервных копий базы данных. Я думаю, что проблема резервного копирования базы данных может быть легко решена без использования какой-либо системы контроля версий. Системы контроля версий (GIT, TFS, SVN и т. Д.) Предназначены для программного обеспечения, а не для дампа файлов или резервных копий базы данных или просто для хранения данных (для этого существует множество решений).
Альберто Солано
Я думаю, что большинство пользователей читают первые несколько предложений и понижают голос, как вы, вероятно, скажете, что это нормально.
1
@AlbertoSolano я вижу; но читая вопрос («могу ли я сделать резервную копию моей БД в GIT?»), а затем ваше первое утверждение («хорошо, чтобы сохранить файл резервной копии ...»), кажется, что вы говорите обратное. Остальная часть ответа, кажется, говорит о том, что его нет ни здесь, ни там, хотя я подозреваю, что большинство людей думают, что это крушение поезда, которое должно произойти.
Даниэль Б,
1

Вы не должны хранить двоичные данные в Git - особенно в базе данных.
Изменения кода и базы данных DML - это совершенно разные вещи.

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

Использовать Git для резервного копирования этих «архивных журналов» не имеет смысла. Архивные журналы в производственных средах довольно тяжелые и должны быть удалены после регулярного полного резервного копирования. Также бесполезно помещать их в git - в каком-то смысле это уже репозиторий.

Jehy
источник
1
почему нельзя использовать Git для резервного копирования этих «архивных журналов», созданных MySQL?
комнат
1
Просто потому что это не имеет смысла. Архивные журналы в производственных средах довольно тяжелые и должны быть удалены после регулярного полного резервного копирования. Также бесполезно помещать их в git - в каком-то смысле это уже репозиторий. Майкл Хэмптон дает довольно хороший ответ по этому вопросу (на этой странице).
Jehy
1
Зачем беспокоиться о ротации логов, если вы собираетесь хранить копию всего в git? Можно также сохранить один файл журнала монстров.
wobbily_col