MySQL applying second incremental backup causes LSN in the ibdata files to be higher than LSN in the ib_logfiles
When I see messages of that nature, I usually blame the redo logs. This is where is LSN is written.

The problem may stem from not preparing the incremental backup.

What seems to be missing is the use of the --prepare option.

What this essentially does is create the backup rolled forward to a specific point in time. This is particularly true if there were transactions occurring during the backup.

It's kind of like the opposite of a mysqldump --single-transaction, which makes a logical dump based on the start time of the backup. Doing a --prepare with xtrabackup will make the redo logs roll forward to match the end time of the backup.

Note what the opening paragraph of Preparing the backup from the XtraBackup Docs says:


  After you make a backup with --backup, the next step is to prepare it. The data files are not point-in-time consistent until they’ve been prepared, because they were copied at different times as the program ran, and they might have been changed while this was happening. If you try to start InnoDB with these data files, it will detect corruption and crash itself to prevent you from running on damaged data. The --prepare step makes the files perfectly consistent at a single instant in time, so you can run InnoDB on them.


This should coalesce the LSN of the incremental after making the incremental.

For more information, please read Preparing the backup from the XtraBackup Docs