Это обусловлено тем, что база в любой момент может быть модифицирована. Существует кэш и копирование может совпасть с моментом записи в файл (модификацией файла). В этом случае проблемы возникнут при попытке восстановления базы из backup.
Метод сохранения backup основан на базе механизма бинарных логов MySQL. Бинарные логи содержат полную историю изменений базы данных. Для работы инкрементального backup необходимо, чтобы бинарные логи были включены для требуемой базы данных.
Процесс состоит из двух фаз:
- Создание первоначального полного снимка базы. В параметрах “mysqldump” указывается ключ –flush-logs, который приводит к принудительному сохранению бинарных логов, ротации файлов бинарных логов, чтобы при последующем их сохранении было известно с какого файла начинать синхронизацию.
mysqldump --verbose --single-transaction --quote-names --complete-insert --extended-insert --routines --events --triggers -uLOGIN -PPORT -hHOST -pPASS --flush-logs DBNAME > dump.sql
Такой снимок базы выполняется изначально при запуске всего механизма Backup данных, а также рекомендуется повторно выполнять полные снимки базы один раз в месяц. - Периодический Backup бинарных логов от момента предыдущего Backup. Эта операция выполняется простым копированием файлов (обычно расположены /var/lib/mysql) с момента предыдущего инкрементального или полного Backup по текущий момент, за исключением последнего файла, в который записываются текущие изменения. Такую периодическую процедуру рекомендуется выполнять один раз в неделю.
Восстановление backup из инкрементальных логов происходит следующим образом:
- Восстанавливаем базы из последнего полного backup.
- Накатывание инкрементальных обновлений. Последовательно применяются к базе бинарные логи:
mysqlbinlog binlog_files | mysql -uLOGIN -pPASS
