So it looks like compact backups still don't work. I can consistently reproduce crashes of compact backups:
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: xtrabackup: Last MySQL binlog file position 663425927, file name mysql-bin.000117
InnoDB: Creating shared tablespace for temporary tables
InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
InnoDB: File './ibtmp1' size is now 12 MB.
InnoDB: 96 redo rollback segment(s) found. 1 redo rollback segment(s) are active.
InnoDB: 32 non-redo rollback segment(s) are active.
InnoDB: page_cleaner: 1000ms intended loop took 48773ms. The settings might not be optimal. (flushed=0 and evicted=0, during the time.)
Starting 4 threads to rebuild indexes.
[01] Checking if there are indexes to rebuild in table some_meta/meta_data (space id: 6)
[04] Checking if there are indexes to rebuild in table teststore_main/like_a_boss_buffer (space id: 9)
[03] Checking if there are indexes to rebuild in table teststore_main/like_a_boss_buffer (space id: 6155)
[03] Found index uc_key
[03] Found index updated_idx
[03] Rebuilding 2 index(es).
06:00:54 UTC - xtrabackup got signal 11 ;
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/xtrabackup(my_print_stacktrace+0x2c)[0xce46fc]
/usr/bin/xtrabackup(handle_fatal_signal+0x261)[0x9d0991]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf8f0)[0x7fbe4312f8f0]
/usr/bin/xtrabackup(_Z22row_merge_create_indexP5trx_tP12dict_table_tPK11index_def_tPK16dict_add_v_col_t+0x95)[0x8f6aa5]
/usr/bin/xtrabackup[0x729d75]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x80ca)[0x7fbe431280ca]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fbe40e0d8ad]
So it looks like compact backups still don't work. I can consistently reproduce crashes of compact backups:
InnoDB: Starting an apply batch of log records to the database... main/like_ a_boss_ buffer (space id: 9) main/like_ a_boss_ buffer (space id: 6155)
InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: xtrabackup: Last MySQL binlog file position 663425927, file name mysql-bin.000117
InnoDB: Creating shared tablespace for temporary tables
InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
InnoDB: File './ibtmp1' size is now 12 MB.
InnoDB: 96 redo rollback segment(s) found. 1 redo rollback segment(s) are active.
InnoDB: 32 non-redo rollback segment(s) are active.
InnoDB: page_cleaner: 1000ms intended loop took 48773ms. The settings might not be optimal. (flushed=0 and evicted=0, during the time.)
Starting 4 threads to rebuild indexes.
[01] Checking if there are indexes to rebuild in table some_meta/meta_data (space id: 6)
[04] Checking if there are indexes to rebuild in table teststore_
[03] Checking if there are indexes to rebuild in table teststore_
[03] Found index uc_key
[03] Found index updated_idx
[03] Rebuilding 2 index(es).
06:00:54 UTC - xtrabackup got signal 11 ;
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 xtrabackup( my_print_ stacktrace+ 0x2c)[0xce46fc] xtrabackup( handle_ fatal_signal+ 0x261)[ 0x9d0991] 64-linux- gnu/libpthread. so.0(+0xf8f0) [0x7fbe4312f8f0 ] xtrabackup( _Z22row_ merge_create_ indexP5trx_ tP12dict_ table_tPK11inde x_def_tPK16dict _add_v_ col_t+0x95) [0x8f6aa5] xtrabackup[ 0x729d75] 64-linux- gnu/libpthread. so.0(+0x80ca) [0x7fbe431280ca ] 64-linux- gnu/libc. so.6(clone+ 0x6d)[0x7fbe40e 0d8ad]
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/
/usr/bin/
/lib/x86_
/usr/bin/
/usr/bin/
/lib/x86_
/lib/x86_
Please report a bug at https:/ /bugs.launchpad .net/percona- xtrabackup