I'm afraid your chance to do the incremental has passed.
You need to do two things:
Resize the InnoDB transaction logs
From the messages above, the logs look like 25600K.
You need much bigger logs because writes to the logs are going so fast that incremental backups will lose it place while backing up as you just experienced. You barely have about 512M with ib_logfile0 and ib_logfile1. The fact that an incremental fails shows you are writing more than 512M of transaction info during an incremental backup cycle.
In MySQL, the largest log allowed is 2047M.
Please do the following
STEP01) Run this in the mysql client:
SET GLOBAL innodb_fast_shutdown = 0;
This will cause all transactions to be completely committed to disk. This will shorten mysql startup time because InnoDB Crash Recovery is not needed (or at least drastically minimized).
STEP02) service mysql stop
STEP03) Edit my.cnf with this
[mysqld]
innodb_log_file_size = 2047M
innodb_fast_shutdown = 0
STEP04) Move the logs away
cd /var/lib/mysql
mv ib_logilfe0 ib_logilfe0.bak
mv ib_logilfe0 ib_logilfe0.bak
STEP05) service mysql start (Transaction Logs get recreated sized 2047M)
Please see How to safely change MySQL innodb variable 'innodb_log_file_size'?
Take a fresh Full Backup
Once you take this backup, you now have transaction logs big enough to endure a long-running incremental backup. It is still advisable to do increment backups during offpeak times.
Even with the transaction logs resized to 2047M, the only way an incremental backup's restoration could fail is if more than 4094M of transaction info is written to the log files during the incremental backup cycle.
UPDATE 2012-12-17 11:39 EDT
DISCLAIMER : Not Familiar with MySQL Enterprise Backup
I learned about 1.5 years ago that Percona XtraBackup was similar to MySQL Enteprise Backup. According to the Documentation on XtraBackup's full backup, you are supposed to prepare the Full Backup for restoration. This step is necessary because MySQL may have been writing transactions that are probably present in the double-write buffer that have not been accounted for in any other parts of the InnoDB infrastructure. That way, the following must be done:
- transactions written during the backup are extracted from the double-write buffer
- those transaction are executed
- InnoDB files for the Backups are updated with proper Log Sequence Numbers
As for XtraBackup's Incremental Backup, the Full Backup must be prepared as well.
If the claim that Percona XtraBackup was similar to MySQL Enteprise Backup is indeed true, then there must be a set of preparatory steps that needs to be done once or twice to the Full Backup. Please read in the MySQL Enterprise Backup Documentation and find any reference possible to preparing Full Backups.
UPDATE 2012-12-17 12:55 EDT
After reading the MySQL Documentation on MySQL Enterprise Backup, I noticed something that may help. You stated that you do this:
mysqlbackup --backup-dir=/mnt/testb/full/latest --user=dba backup
mysqlbackup --backup-dir=backupDir/latest apply-log
I think you have a typo:
mysqlbackup --backup-dir=/mnt/testb/full/latest --user=dba backup
mysqlbackup --backup-dir=backupDir/latest --apply-log
I do not see apply-log in the Docs, but I do see these in the Docs
--apply-log--backup-and-apply-log
Please try one of these options and see if it corrects matters
mysqlbackup --backup-dir=/mnt/testb/full/latest --user=dba backup-and-apply-logmysqlbackup --backup-dir=backupDir/latest --apply-log
