Можно ли обрабатывать резервные копии MySQL с помощью git?
Сегодня у меня была эта очень аккуратная идея для резервного копирования моей базы данных: поместить файл дампа в репозиторий git, а затем зафиксировать на каждом дампе, чтобы у меня была самая последняя копия, но можно легко откат к предыдущему резервное копирование. Я также могу легко вытащить копию репозитория на регулярной основе, чтобы сохранить копию на моем собственном компьютере в качестве резервной копии резервных копий. Это определенно звучит умно.
Однако я знаю, что у умных решений иногда есть фундаментальные недостатки. Какие проблемы я могу использовать для хранения mysqldump diffs в git? Стоит ли оно того? Что делают большинство людей, чтобы иметь несколько резервных копий базы данных на сервере и сохранять избыточные копии в другом месте?
Ответы
Ответ 1
Обычно вы не сохраняете каждую резервную копию (или моментальный снимок) навсегда. Хранилище git хранит каждую проверку, которую вы когда-либо делали. Если вы когда-нибудь решите сократить старые версии (скажем, месячные версии до одного раза в неделю, год от одного до одного раза в месяц и т.д.), Вам придется сделать это с помощью git filter-branch, который перепишет всю историю. Затем git gc, чтобы удалить нежелательные изменения.
Учитывая, что сильные стороны git - это распределенное управление версиями и сложные рабочие процессы патчей/веток (ни одно из них не применяется к моментальным снимкам или резервным копиям), я бы подумал об использовании другого VCS с более гибкой историей.
Ответ 2
Этот подход звучит отлично для меня. Я использую Git для резервного копирования моих важных данных.
Обратите внимание, что вы не сохраняете diffs - Git эффективно сохраняет моментальные снимки состояния каталога с каждой фиксацией. Вы можете создать diff двух коммитов, но фактический механизм хранения не имеет ничего общего с diff.
Ответ 3
В теории это будет работать, но вы начнете испытывать проблемы, когда базы данных дампов становятся большими.
Git не имеет ограничений жесткого размера файла, но будет отличаться от содержимого вашего последнего дампа с ранее сохраненным в репозитории, для чего потребуется как минимум столько же памяти, сколько размеры обоих этих файлы добавлены вместе, поэтому я бы предположил, что он начнет очень медленно, очень быстро с файлами более 100 МБ (или даже 10 МБ).
Git не был создан для работы с файлами этого типа (т.е. большими файлами данных вместо исходного кода), поэтому я считаю, что это принципиально плохая идея. Тем не менее, вы можете использовать что-то вроде Dropbox для хранения дампов, которые по-прежнему сохраняют историю версий для вас, но более приспособлены к файлам, которые невозможно эффективно разделить.
Ответ 4
Если вы используете MySQL (и, возможно, другие) и активируете двоичное ведение журнала, вам может потребоваться настроить репозиторий git для каталога вашего журнала bin и разработать стратегию для регулярной фиксации обновлений binlog.
В MySQL бинлог хранит запросы, которые изменяют данные в любые таблицы в базе данных. Если вы синхронизируете свои коммиты с регулярными дампами базы данных, вы должны иметь верный способ восстановления данных.
Честно говоря, я думаю, что просто использование собственных инструментов MySQL, вероятно, будет лучшим решением, но то, что я здесь изложил, позволяет вам управлять вашими данными MySQL, что, по-моему, было в первую очередь.
