Comment 5 for bug 1368846

Joshi,

I have upgraded the xtrabackup to version 2.2.5 and initiated the
incremental backup.

Currently the incremental backup has been completed successfully and the
apply-log process is in progress.

I will update you the details.

# /usr/bin/xtrabackup -v
/usr/bin/xtrabackup version 2.2.5 based on MySQL server 5.6.21 Linux
(x86_64) (revision id: )

On Sun, Oct 12, 2014 at 3:26 PM, Nilnandan Joshi <
<email address hidden>> wrote:

> Unable to reproduce the same with PS 5.6.17 and Xtrabackup 2.2.5
>
> Can you please try to check the same with latest version of Xtrabackup?
> (2.2.5)
>
> Also please provide the exact command of taking full backup, incremental
> backup and apply log. It might helpful to reproduce this bug.
>
> ** Changed in: percona-xtrabackup
> Status: New => Incomplete
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1368846
>
> Title:
> xtrabackup Assertion failure with Apply log process
>
> Status in Percona XtraBackup:
> Incomplete
>
> Bug description:
> While applying the log we are facing an assertion failure issue with
> xtrabackup version 2.1.9 so we decided to upgrade the tool to version
> 2.2.3. But still we are hitting the same error.
>
> The issue is not occurring on every try, last time we found the issue
> when we initiated an incremental backup proceeding to a full backup.
> We have completed the full backup successfully but the incremental
> ended with the same error. Log details are given below.
>
> Version :
> [05:54:02 xxx@xxxx:~]# xtrabackup -v
> xtrabackup version 2.2.3 based on MySQL server 5.6.17 Linux (x86_64)
> (revision id: )
>
> [xxxx@xxxxxx~]$ innobackupex --version
> InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy
>
> mysql version: 5.6.17-66.0-log
>
> Log:
>
> 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: In a MySQL replication slave the last master binlog file
> InnoDB: position 0 329970412, file name data3-bin.001806
> InnoDB: Last MySQL binlog file position 0 883545871, file name
> data1-bin.002972
> InnoDB: 128 rollback segment(s) are active.
> InnoDB: Waiting for purge to start
> InnoDB: 5.6.17 started; log sequence number 13967966489023
>
> [notice (again)]
> If you use binary log and don't use any hack of group commit,
> the binary log position seems to be:
> InnoDB: Last MySQL binlog file position 0 883545871, file name
> data1-bin.002972
>
> xtrabackup: starting shutdown with innodb_fast_shutdown = 1
> InnoDB: FTS optimize thread exiting.
> InnoDB: Starting shutdown...
> 2014-09-12 05:13:40 4a7ee940 InnoDB: Assertion failure in thread
> 1249831232 in file buf0flu.cc line 2503
> InnoDB: Failing assertion: UT_LIST_GET_LEN(buf_pool->flush_list) == 0
> 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.6/en/forcing-innodb-recovery.html
> InnoDB: about forcing recovery.
> innobackupex: Error:
> innobackupex: ibbackup failed at /usr/bin/innobackupex line 2610.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/percona-xtrabackup/+bug/1368846/+subscriptions
>

--
Regards,

Arunjith A, Consulting Team 3
<email address hidden>
Skype percona.aaravindan
Ph: +91 9539992246 (India), IST (UTC +5:30)