3

I am attempting to prepare and restore a full backup taken through xtrabackup via a scheduling script called surrogate.

I have tarred and gzipped the backup, transferred to a local machine running the same setup (aside from a slight version difference in xtrabackup - 2.2.12 on source, 2.3.9 local).

Upon extracting I am running the following command to prepare the backup for restore:

innobackupex --use-memory=1G --apply-log /home/matthew/full_2017-08-13_0700/

This is responding:

  innobackupex version 2.3.9 based on MySQL server 5.6.24 Linux (x86_64) (revision id: fde0e3e)
  xtrabackup: cd to /home/matthew/full_2017-08-13_0700/
  xtrabackup: This target seems to be not prepared yet.
  xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(661464509389)
  xtrabackup: using the following InnoDB configuration for recovery:
  xtrabackup:   innodb_data_home_dir = ./
  xtrabackup:   innodb_data_file_path = ibdata1:12M:autoextend
  xtrabackup:   innodb_log_group_home_dir = ./
  xtrabackup:   innodb_log_files_in_group = 1
  xtrabackup:   innodb_log_file_size = 2097152
  xtrabackup: using the following InnoDB configuration for recovery:
  xtrabackup:   innodb_data_home_dir = ./
  xtrabackup:   innodb_data_file_path = ibdata1:12M:autoextend
  xtrabackup:   innodb_log_group_home_dir = ./
  xtrabackup:   innodb_log_files_in_group = 1
  xtrabackup:   innodb_log_file_size = 2097152
  xtrabackup: Starting InnoDB instance for recovery.
  xtrabackup: Using 1073741824 bytes for buffer pool (set by --use-memory parameter)
  InnoDB: Using atomics to ref count buffer pool pages
  InnoDB: The InnoDB memory heap is disabled
  InnoDB: Mutexes and rw_locks use GCC atomic builtins
  InnoDB: Memory barrier is not used
  InnoDB: Compressed tables use zlib 1.2.8
  InnoDB: Using CPU crc32 instructions
  InnoDB: Initializing buffer pool, size = 1.0G
  InnoDB: Completed initialization of buffer pool
  InnoDB: The first specified data file ./ibdata1 did not exist: a new database to be created!
  InnoDB: Setting file ./ibdata1 size to 12 MB
  InnoDB: Database physically writes the file full: wait...
  InnoDB: Setting log file ./ib_logfile101 size to 2 MB
  InnoDB: Renaming log file ./ib_logfile101 to ./ib_logfile0
  InnoDB: New log files created, LSN=45781
  InnoDB: Doublewrite buffer not found: creating new
  InnoDB: Doublewrite buffer created
  InnoDB: 1 rollback segment(s) are active.
  InnoDB: Waiting for purge to start
  InnoDB: 5.6.24 started; log sequence number 0

  xtrabackup: error: The transaction log file is corrupted.
  xtrabackup: error: The log was not applied to the intended LSN!
  xtrabackup: Log applied to lsn 0
  xtrabackup: The intended lsn is 661464919534

Any idea what this is and how I overcome it?

1

DISCLAIMER : Not xtrabackup expert

Your situation is quite similar to a Jan 27, 2016 post on the Percona Forums. The poster, dbaffaleuf, was running percona server 5.6.24-72.2-log, innobackupex 2.3.3 Linux (x86_64).

After encountering your same message, dbaffaleuf wrote

Interestingly the xtrabackup_logfile file has been deleted from the backup path. If I save the xtrabackup_logfile before running the prepare, and restore it after, the first prepare crashes with transaction log corrupted, the next try to prepare works:

Restore the xtrabackup_log file for previous copy after full backup

$ cp /tmp/xtrabackup_logfile /my/path/to/backup/timestamp/

Run the prepare again:

$ /home/products/xtrabackup/bin/innobackupex --use-memory=1G --apply-log /my/path/to/backup/timestamp/ | tee -a /my/path/to/prepare/log/file.log

You may have to do the same

  • Save the xtrabackup_logfile before running the prepare
  • Restore the xtrabackup_log file for previous copy after full backup
  • Run the prepare again
  • I can confirm that my log file is missing after the error, and restoring it then running the command again gets further, but now its just filling up the available hd space until it errors because it can't write anymore. I've tried the same with 50gb, 150gb and finally a 250gb vm and all are the same. The database files I'm restoring are 37gb on the source server. – matthewrk Aug 29 '17 at 21:45
  • SUGGESTION: Since you side xtrabackup - 2.2.12 on source, 2.3.9 local, you should think about downgrading to the latest 2.2.x and try again. – RolandoMySQLDBA Aug 31 '17 at 3:21
  • I tried that but unfortunately the same result, I have managed a successful restore by using the surrogate scripts - on review of what exactly that does differently I can't immediately spot anything and can only assume one of the flags they're setting on innobackupex is doing something differently. The surrogate restore script isn't even long particularly long or complex: github.com/sixninetynine/surrogate/blob/master/files/lib/… – matthewrk Sep 1 '17 at 16:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.