Я использую innobackupex для резервного копирования своих баз данных следующим образом:
usr/local/bin/innobackupex --user=bkpuser --password='example' --rsync \
--no-timestamp /pathtobackup 2> /pathtobackup/innobackupex.log
Сейчас этот на странице говорится: «Однако есть незавершенные транзакции, а также другие транзакции, которые не были сброшены в свои файлы данных. Другими словами, резервная копия как есть будет похожа на datadir, если ваша база данных выйдет из строя. Некоторые дополнительные транзакции все равно должны быть применены». .
Это правда? Я думал, что, по крайней мере, промывочная часть не соответствует действительности, и я не уверен в транзакциях. Моя цель - иметь возможность восстановить свою базу данных, как если бы она никогда не выходила из строя, поэтому, пожалуйста, посоветуйте.
Укороченная версия: если вы выполняете резервное копирование на загруженном сервере, то ДА.
Если вы заблокируете сервер от обновлений, т.е. он является подчиненным и выполните mysql -e "STOP SLAVE" перед резервным копированием я подозреваю, что xtrabackup_logfile будет пустым, и application-log ничего не сделает.
Длинная версия:
Существует документ с примером создания резервной копии и ее восстановления как часть практического руководства по подготовка раба к репликации, и это указывает на то, что НЕОБХОДИМО добавить шаг для применения журналов, прежде чем они станут доступны для использования;
innobackupex --user=yourDBuser --password=MaGiCdB1 /path/to/backupdir
innobackupex --user=yourDBuser --password=MaGiCdB1 /
--apply-log /path/to/backupdir/$TIMESTAMP/
В страница опций для innobackupex указывают, что --apply-log читает транзакции из xtrabackup_logfile
Подготовьте резервную копию в BACKUP-DIR, применив файл журнала транзакций с именем xtrabackup_logfile, расположенный в том же каталоге. Также создайте новые журналы транзакций. Конфигурация InnoDB считывается из файла backup-my.cnf, созданного innobackupex при создании резервной копии.
Я подозреваю что xtrabackup_logfile содержит транзакции за период, когда резервное копирование выполнялось, но база данных не была заблокирована. Я думаю, что с помощью этой стратегии innobackupex может работать только с коротким временем блокировки и использовать binlog для ретроспективного применения обновлений к резервной копии.
Инструмент xtrabackup-manager применяет журнал, здесь в этом файле есть шаг apply-log;
http://code.google.com/searchframe#i12s1rWpN4M/trunk/includes/genericBackupTaker.class.php&q=apply%20log%20package:xtrabackup-manager.googlecode.com
Непонятно, в каком формате эти файлы (file xtrabackup_logfile возвращает «данные»), хотя они кажутся разреженными в моей системе, но я не ожидаю каких-либо ожидающих транзакций в этом случае, потому что резервные копии берутся с остановленного ведомого устройства. Хотя, если вы хотите узнать, исходный код xtrabackup доступен для ознакомления.