Using Incremental Backup fails.

Asked by Alon Edelman on 2012-02-08

Hi all.

I Am having some problem with the Incremental backups and i hope that someone can help me here.

I have a DB that no one uses (no active connections).

a base backup was done using "xtrabackup --backup --target-dir=/backup/xtranbackup/full"
The result of cat /backup/xtranbackup/full/xtrabackup_checkpoints is :
backup_type = full-backuped
from_lsn = 0
to_lsn = 421032481873
last_lsn = 421032481873

With out having any change to the DB i have used "xtrabackup --prepare --apply-log-only --target-dir=/backup/xtranbackup/full"

xtrabackup version 1.6.4 for Percona Server 5.1.59 unknown-linux-gnu (x86_64) (revision id: 314)
xtrabackup: cd to /backup/xtranbackup/full
xtrabackup: This target seems to be not prepared yet.
xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(421032481873)
xtrabackup: Temporary instance for recovery is set as followings.
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M: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 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Compressed tables use zlib 1.2.3
InnoDB: Warning: innodb_file_io_threads is deprecated. Please use innodb_read_io_threads and innodb_write_io_threads instead
120208 14:50:52 InnoDB: Initializing buffer pool, size = 100.0M
120208 14:50:52 InnoDB: Completed initialization of buffer pool
120208 14:50:52 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
120208 14:50:52 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Last MySQL binlog file position 0 28855, file name ./lab2-bin.000004

[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 28855, file name ./lab2-bin.000004

xtrabackup: starting shutdown with innodb_fast_shutdown = 1
120208 14:51:07 InnoDB: Starting shutdown...
120208 14:51:07 InnoDB: Shutdown completed; log sequence number 421032482969

the to_lsn = 421032481873 and the log sequence number 421032482969.

according to the doc it should not happen !

If try to apply the Incremental backup(that was done with "xtrabackup --backup --target-dir=/backup/xtranbackup/inc1 --incremental-basedir=/backup/xtranbackup/full ") i get :
120208 15:01:26 InnoDB: Initializing buffer pool, size = 100.0M
120208 15:01:26 InnoDB: Completed initialization of buffer pool
120208 15:01:26 InnoDB: highest supported file format is Barracuda.
InnoDB: ##########################################################
InnoDB: WARNING!
InnoDB: The log sequence number in ibdata files is higher
InnoDB: than the log sequence number in the ib_logfiles! Are you sure
InnoDB: you are using the right ib_logfiles to start up the database?
InnoDB: Log sequence number in ib_logfiles is 421032481873, log
InnoDB: sequence numbers stamped to ibdata file headers are between
InnoDB: 421032482969 and 421032482969.
InnoDB: ##########################################################
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!

so, my question is, what am i doing wrong ?

Thank you, Alon.

update--> after Alexey response i tsrted from the basic, and did the backup using the docs from http://www.percona.com/doc/percona-xtrabackup/xtrabackup_bin/incremental_backups.html?id=percona-xtrabackup:xtrabackup:incremental

the directory did not exist before the backup was started
first backup :
xtrabackup --backup --target-dir=/data/backups/base --datadir=/hddraid/mysql

backup_type = full-backuped
from_lsn = 0
to_lsn = 421032481873
last_lsn = 421032481873

incremental :
xtrabackup --backup --target-dir=/data/backups/inc1 --incremental-basedir=/data/backups/base --datadir=/hddraid/mysql

backup_type = incremental
from_lsn = 421032481873
to_lsn = 421032483039
last_lsn = 421032483039

now the prepare:
xtrabackup --prepare --apply-log-only --target-dir=/data/backups/base

xtrabackup version 1.6.4 for Percona Server 5.1.59 unknown-linux-gnu (x86_64) (revision id: 314)
xtrabackup: cd to /data/backups/base
xtrabackup: This target seems to be not prepared yet.
xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(421032481873)
xtrabackup: Temporary instance for recovery is set as followings.
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M: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 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Compressed tables use zlib 1.2.3
InnoDB: Warning: innodb_file_io_threads is deprecated. Please use innodb_read_io_threads and innodb_write_io_threads instead
120220 17:02:23 InnoDB: Initializing buffer pool, size = 100.0M
120220 17:02:23 InnoDB: Completed initialization of buffer pool
120220 17:02:23 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
120220 17:02:23 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Last MySQL binlog file position 0 28855, file name ./lab2-bin.000004

[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 28855, file name ./lab2-bin.000004

xtrabackup: starting shutdown with innodb_fast_shutdown = 1
120220 17:02:37 InnoDB: Starting shutdown...
120220 17:02:37 InnoDB: Shutdown completed; log sequence number 421032482969

so it looks like i am still doing something wrong, no ?

Alon.

Question information

Language:
English Edit question
Status:
Answered
For:
Percona XtraBackup moved to https://jira.percona.com/projects/PXB Edit question
Assignee:
Alexey Kopytov Edit question
Last query:
2012-02-08
Last reply:
2012-02-21
Alexey Kopytov (akopytov) said : #1

Alon,

It looks like when applying the log to the full backupm xtrabackup is somehow using the log from the incremental one (note the start_lsn value in the prepare log I'm quoting below). It could get overwritten if you specified the full backup directory as an incremental one by mistake.

---
xtrabackup version 1.6.4 for Percona Server 5.1.59 unknown-linux-gnu (x86_64) (revision id: 314)
xtrabackup: cd to /backup/xtranbackup/full
xtrabackup: This target seems to be not prepared yet.
xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(421032481873)
---

Alexey Kopytov (akopytov) said : #2

Alon,

My apologies, I misinterpreted the source in my previous answer. What xtrabackup reports as start_lsn when applying the log is actually the maximum LSN in the log file being applied, it's just that the message text is misleading.

But what happens when you do apply the incremental backup with this new backup setup? Does it still fail due to LSN mismatch?

Can you help with this problem?

Provide an answer of your own, or ask Alon Edelman for more information if necessary.

To post a message you must log in.