Жизнеспособно ли обрабатывать резервные копии MySQL с помощью git?

Question

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

Однако я знаю, что умные решения иногда имеют фундаментальные недостатки. Какие проблемы могут возникнуть при сохранении различий mysqldump в git? Стоит ли оно того? Что делает большинство людей, чтобы иметь несколько резервных копий базы данных на сервере и хранить избыточные копии в другом месте?

Answer 1

Обычно вы не сохраняете каждую резервную копию (или снимок) навсегда.Git-репозиторий хранит все проверки, которые вы когда-либо делали.Если вы когда-нибудь решите удалить старые версии (скажем, месячные версии до одного раза в неделю, старые до одного раза в месяц и т. Д.), Вам придется делать это с git filter-branch, который переписывает всю историю.Затем git gc для удаления нежелательных ревизий.

Учитывая, что сильные стороны git - это распределенный контроль версий и сложные рабочие процессы исправлений / веток (ни один из которых не применим к снимкам или резервным копиям), я бы рассмотрел использование другой VCS сболее податливая история.

Answer 2

Этот подход звучит хорошо для меня.Я использую Git для резервного копирования своих важных данных.

Обратите внимание, что вы не храните diff-файлы - Git эффективно сохраняет снимки состояния каталога с каждым коммитом.Вы можете сгенерировать diff из двух коммитов, но сам механизм хранения не имеет ничего общего с diff.

Answer 3

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

Git не имеет каких-либо жестких ограничений на размер файла, но он будет отличать содержимое вашего последнего дампа от ранее сохраненного в хранилище, что потребует как минимум столько же памяти, сколько размеры обоих добавленных файлов вместе - так что я бы предположил, что он начнет работать очень медленно, очень быстро с файлами размером более 100 МБ (или даже 10 МБ).

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

Answer 4

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

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

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