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

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

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

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

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

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

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

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

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

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

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

Мои два цента: я не думаю, что это хорошая идея. 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 до бесконечности и далее ...

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

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

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

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

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

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

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