Uploaded image for project: 'Percona XtraBackup'
  1. Percona XtraBackup
  2. PXB-1436

LP #1676625: InnoDB: Assertion failure in thread <n> in file log0recv.cc line 2008

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Done
    • Priority: Low
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None

      Description

      **Reported in Launchpad by Ceri WIlliams last update 11-06-2017 04:17:25

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

      2 similar bugs (based on the assertion error) exist but refer to incremental backups. They also relate to earlier versions.

      The following was seen whilst preparing a backup:

      ---------------

      2017-03-27 04:32:41 0x7f1e406f4700 InnoDB: Assertion failure in thread 139767906780928 in file log0recv.cc line 2008
      InnoDB: Failing assertion: Unable to render embedded object: File (page ) not found.!page_is_comp(page) == dict_table_is_comp(index->table)
      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.
      11:32:41 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+0x3b)[0xc98a2b]
      innobackupex(handle_fatal_signal+0x281)[0xa58ac1]
      /lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7f239747e390]
      /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38)[0x7f239544a428]
      /lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7f239544c02a]
      innobackupex[0x6d65c3]
      innobackupex[0x86faba]
      innobackupex(_Z22recv_recover_page_funcmP11buf_block_t+0xa9e)[0x870a7e]
      innobackupex(_Z20buf_page_io_completeP10buf_page_tb+0x339)[0x7577b9]
      innobackupex(_Z12fil_aio_waitm+0x11f)[0x7ede6f]
      innobackupex(io_handler_thread+0x28)[0x931c38]
      /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba)[0x7f23974746ba]
      /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f239551b82d]

      Please report a bug at https://bugs.launchpad.net/percona-xtrabackup

      ---------------

      This backup was restored on 3 other machines without an issue and was successful on the same machine on the second run.

      PS 5.7.17 - 2.4.6-2.xenial (both are the same version as the source server)

      innobackupex --defaults-file=./backup-my.cnf --use-memory=20G --apply-log ./

      ---------------

      backup-my.cnf

      [mysqld]
      innodb_checksum_algorithm=innodb
      innodb_log_checksum_algorithm=strict_crc32
      innodb_data_file_path=ibdata1:12M:autoextend
      innodb_log_files_in_group=2
      innodb_log_file_size=1572864000
      innodb_fast_checksum=false
      innodb_page_size=16384
      innodb_log_block_size=512
      innodb_undo_directory=./
      innodb_undo_tablespaces=0
      server_id=167772931

      redo_log_version=1

      ---------------

      Unfortunately the full output was not captured at the time.

      The only known difference was that the first decompress happened with an earlier version of innobackupex (2.3.7-2.xenial)

        Smart Checklist

          Attachments

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                lpjirasync lpjirasync (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: