InnoDB: An optimized(without redo logging) DDLoperation has been performed.

[prashantk]

Please refer error dump of xtrabackup :

170103 00:27:52 >> log scanned up to (555158512370)
170103 00:27:53 >> log scanned up to (555158512411)
170103 00:27:54 >> log scanned up to (555158512452)
170103 00:27:55 >> log scanned up to (555158512493)
170103 00:27:56 >> log scanned up to (555158512534)
InnoDB: Last flushed lsn: 555157588339 load_index lsn 555158512534
[FATAL] InnoDB: An optimized(without redo logging) DDLoperation has been performed. All modified pages may not have been flushed to the disk yet.
    PXB will not be able take a consistent backup. Retry the backup operation
2017-01-03 00:27:57 0x7f2519c07700 InnoDB: Assertion failure in thread 139797322561280 in file ut0ut.cc line 916
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
18:57:57 UTC - xtrabackup got signal 6 ;
This could be because you hit a bug or data is corrupted.
This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x10000
/usr/bin/innobackupex(my_print_stacktrace+0x3b)[0xc26d2b]
/usr/bin/innobackupex(handle_fatal_signal+0x281)[0xa981f1]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x113d0)[0x7f251c9f83d0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38)[0x7f251a9c4418]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7f251a9c601a]
/usr/bin/innobackupex(_Z22trx_undo_free_preparedP5trx_t+0x0)[0x6d827a]
/usr/bin/innobackupex(_ZN2ib5fatalD1Ev+0x145)[0x9aecc5]
/usr/bin/innobackupex[0x7525a7]
/usr/bin/innobackupex(_Z19recv_parse_log_recsm7store_tb+0x281)[0x757221]
/usr/bin/innobackupex[0x6fb140]
/usr/bin/innobackupex[0x6fb368]
/usr/bin/innobackupex[0x6fb83b]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x76fa)[0x7f251c9ee6fa]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f251aa95b5d]

[prashantk (softenter)]

Just noticed that, there was an INDEX creation in progress while backup was in progress.
Could that be a reason for backup failure?
It seems that the bug was fixed though, as per percona release note:

https://www.percona.com/doc/percona-xtrabackup/2.4/release-notes/2.4/2.4.3.html

Please let me know if more input is needed to investigate further.

[Shahriyar Rzayev (rzayev-sehriyar)]

Seems to be duplicate of:

https://bugs.launchpad.net/percona-xtrabackup/+bug/1532878

[Sergei Glushchenko (sergei.glushchenko)]

The cause for this failure is that MySQL skipping redo logging for some DDL operations (https://dev.mysql.com/doc/refman/5.7/en/sorted-index-builds.html). Currently, if you run such DDL during the backup, xtrabackup will abort to prevent creation of corrupted backup.

We are working towards making xtrabackup to retry copying of altered tables or making it block DDLs on server for the duration of the backup.

Current workaround is to retry the backup manually and try to avoid DDLs during the backup.

[monty solomon (monty+launchpad)]

170508 07:43:10 >> log scanned up to (5464322826085)
InnoDB: Last flushed lsn: 5463932380446 load_index lsn 5464322854907
[FATAL] InnoDB: An optimized(without redo logging) DDLoperation has been performed. All modified pages may not have been flushed to the disk yet.
    PXB will not be able take a consistent backup. Retry the backup operation
2017-05-08 07:43:11 0x7f548ff82700 InnoDB: Assertion failure in thread 140001169385216 in file ut0ut.cc line 916
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
07:43:12 UTC - xtrabackup got signal 6 ;
This could be because you hit a bug or data is corrupted.
This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x10000
innobackupex(my_print_stacktrace+0x35)[0xebe3d5]
innobackupex(handle_fatal_signal+0x273)[0xa1a733]
/lib64/libpthread.so.0[0x3eb000f7e0]
/lib64/libc.so.6(gsignal+0x35)[0x3eafc32625]
/lib64/libc.so.6(abort+0x175)[0x3eafc33e05]
innobackupex(_Z21btr_corruption_reportPK11buf_block_tPK12dict_index_t+0x0)[0x7318b0]
innobackupex(_ZN2ib5fatalD1Ev+0xb3)[0x81afb3]
innobackupex[0x796801]
innobackupex(_Z19recv_parse_log_recsm7store_tb+0x4df)[0x79944f]
innobackupex[0x73bc00]
innobackupex[0x73c216]
innobackupex[0x73c5c3]
/lib64/libpthread.so.0[0x3eb0007aa1]
/lib64/libc.so.6(clone+0x6d)[0x3eafce893d]

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXB-1423