Versão resumida : se você estiver executando backups em um servidor ocupado, YES.
Se você bloquear o servidor de atualizações, ou seja, é um escravo e fazer mysql -e "STOP SLAVE"
antes do backup, suspeito que o xtrabackup_logfile estaria vazio e apply-log não faria nada.
Versão longa :
Há um documento fornecendo um exemplo de como fazer um backup e restaurá-lo, como parte de um tutorial sobre preparando um escravo para replicação , e isso indica que é necessário adicionar uma etapa para aplicar os logs antes que eles estejam disponíveis para uso;
innobackupex --user=yourDBuser --password=MaGiCdB1 /path/to/backupdir
innobackupex --user=yourDBuser --password=MaGiCdB1 /
--apply-log /path/to/backupdir/$TIMESTAMP/
A página de opções para innobackupex indica que --apply-log
lê as transações da xtrabackup_logfile
Prepare a backup in BACKUP-DIR by applying the transaction log file named xtrabackup_logfile located in the same directory. Also, create new transaction logs. The InnoDB configuration is read from the file backup-my.cnf created by innobackupex when the backup was made.
Eu suspeito que xtrabackup_logfile
contenha as transações durante o período em que o backup estava em execução, mas o banco de dados não estava bloqueado. Penso que, com essa estratégia, o innobackupex pode ser executado com apenas um curto tempo de bloqueio e usar o log binário para aplicar retrospectivamente as atualizações do backup.
A ferramenta xtrabackup-manager aplica o log em uma etapa de registro de aplicação neste arquivo aqui: link
Não está claro o formato desses arquivos ( file xtrabackup_logfile
retorna "data"), embora eles pareçam estar esparsos no meu sistema, mas não estou esperando nenhuma transação pendente nesse caso, porque os backups foram retirados de um arquivo parou escravo. Embora se você quisesse descobrir, o código-fonte do xtrabackup está disponível para inspeção.