На наших серверах баз данных MySQL размещено несколько десятков баз данных с размером файла дампа от 1 до ~ 100 МБ.
В настоящее время наш подход к резервному копированию mysqldump, завернутый в сценарий оболочки и запускаемый из crontab. Это отлично сработало для нас. Единственный главный недостаток - это большой объем памяти для хранения файлов дампа.
Поскольку дамп базы данных MySQL - это текстовый файл, естественно, я рассматриваю возможность сохранения его в системе контроля версий, например Subversion. Я помню, что Subversion сохраняет только дельту файла в каждой фиксации.
Рекомендуется ли этот подход? Есть ли некоторые подводные камни, о которых нам следует знать?
В документации MySQL может быть именно то, что вам нужно. Двоичные инкрементные резервные копии! (Также отлично подходит для подчиненного сервера бедняков через rsync / ftp / и т. Д.).
MySQL поддерживает инкрементное резервное копирование:
Вы должны запустить сервер с параметром --log-bin, чтобы включить ведение двоичного журнала; см. Раздел 5.2.4, «Двоичный журнал». Бинарные файлы журнала предоставляют вам информацию, необходимую для репликации изменений в базе данных, которые вносятся после того, как вы выполнили резервное копирование. В тот момент, когда вы хотите сделать инкрементную резервную копию (содержащую все изменения, произошедшие с момента последней полной или инкрементной резервной копии), вам следует повернуть двоичный журнал с помощью FLUSH LOGS. После этого вам необходимо скопировать в хранилище резервных копий все двоичные журналы, начиная с момента последнего полного или инкрементного резервного копирования до предпоследнего. Эти двоичные журналы представляют собой инкрементную резервную копию; во время восстановления вы применяете их, как описано в Раздел 6.3, «Восстановление на определенный момент времени». В следующий раз, когда вы сделаете полную резервную копию, вам также следует повернуть двоичный журнал с помощью FLUSH LOGS, mysqldump --flush-logs или mysqlhotcopy --flushlog. См. Раздел 4.5.4, «mysqldump - Программа резервного копирования базы данных» и Раздел 4.6.9, «mysqlhotcopy - Программа резервного копирования базы данных».
binlog, упомянутый SirStan, - хороший подход.
в качестве альтернативы вы можете запустить mysqldumps, а затем использовать rdiff-резервное копирование для создания резервной копии файла дампа. rdiff сохранит n последних резервных копий [вы решаете, сколько], и будет достаточно экономным, так как он сохраняет только полный снимок последней версии файла + набор различий, позволяющий восстановить предыдущие версии.
все, что вы вставляете в svn, остается в svn. репозиторий только растет - так что это хорошее место для хранения ваших схем sql, исходного кода и, возможно, документации; но не фактические данные из sql.
использование svn заняло бы огромное количество места.
скажем, вы фиксируете файл размером 100 МБ, а svn становится версией 1, тогда, если вы добавляете новый файл размером 200 МБ, версия будет 2.
Ваш svn-репозиторий будет 300 МБ.
если вам нравится ваш файл в версии 1, вам нужно будет svn co -r 1 svnrepourl
Я знаю, что этот вопрос немного устарел, но в моей компании мы экспериментировали с чем-то похожим. Мы извлекали резервные копии в формате xml (не из MySQL, а просто текстовые файлы) размером ~ 300 МБ и фиксировали их в репозиторий SVN каждую ночь в течение чуть более недели. Первая фиксация поместила репозиторий в 41 МБ, но с тех пор каждая фиксация была меньше. Сейчас мы находимся на версии 8, а общий размер репозитория составляет лишь 57 МБ. Это примерно 2,5% от размера всей истории, которую он содержит!
Я только что попробовал rdiff-backup, используя те же данные; ниже приведено сравнение (все размеры в МБ):
Backup # Backup Size repo size delta rdiff size delta 0 0 0.03 0.03 0 0 1 286.05 41.49 41.46 286.05 286.05 2 285.93 45.97 4.49 322.13 36.08 3 286.23 50.52 4.54 323.27 1.14 4 286.63 50.79 0.27 324.54 1.26 5 287.46 55.52 4.73 326.54 2.00 6 287.76 55.77 0.25 327.72 1.19 7 288.15 56.14 0.37 328.98 1.26 8 288.41 56.63 0.50 330.36 1.38
Похоже, что дельты примерно одинаковы (иногда svn лучше, иногда rdiff-backup), поэтому по общему размеру SVN выигрывает. Преимущество rdiff заключается в том, что старые резервные копии легко удалять, тогда как с SVN вам придется свнадмин дамп и svnadmin load избавиться от старых ревизий. Я думаю, это вопрос предпочтений, но SVN прост в использовании и имеет массу инструментов для его поддержки.
Ознакомьтесь с этим сценарием, который автоматизирует процесс, позволяя выбирать базы данных и исключать таблицы [отказ от ответственности, я являюсь автором] - http://mysql-svn-backup.redant.com.au/
Percona XtraBackup поддерживает инкрементное горячее резервное копирование баз данных MySQL.