Percona XtraBackup moved to https://jira.percona.com/projects/PXB

About xtrabackup2.0

Asked by kazushige uratani

Hello!!

Can I ask a xtrabackup2.0's question.
Since xtrabackup1.6.2 is already used and the 2.0GA version came out, I tried.

before that.
I think that I want to explain use mysql's varsion.
--------------------------------------------------------------------------------------
 5.5.13-55-log Percona Server (GPL), Release 20.4
--------------------------------------------------------------------------------------

I would like to do restore though, but a part of functions were not able to be used.

Could you confirm following message?
--------------------------------------------------------------------------------------
InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy
and Percona Inc 2009-2012. All Rights Reserved.

This software is published under
the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.

IMPORTANT: Please check that the copy-back run completes successfully.
           At the end of a successful copy-back run innobackupex
           prints "completed OK!".

Original data directory is not empty! at /usr/bin/innobackupex line 568.
--------------------------------------------------------------------------------------

It seems that the "copy-back option" has gone wrong.
--------------------------------------------------------------------------------------
innobackupex --copy-back $WORK_DIR
   OR
innobackupex --ibbackup=xtrabackup --copy-back $WORK_DIR
--------------------------------------------------------------------------------------

It will succeed, if the "copy-back" is changed into the following command.
--------------------------------------------------------------------------------------
mv $WORK_DIR/ib_logfile* $DATA_DIR/log_innodb
cp -r $WORK_DIR/* $DATA_DIR
--------------------------------------------------------------------------------------
OS command is OK!!

Please give me some advises.

kazushige uratani

Question information

Language:
English Edit question
Status:
Solved
For:
Percona XtraBackup moved to https://jira.percona.com/projects/PXB Edit question
Assignee:
No assignee Edit question
Solved by:
Alexey Kopytov
Solved:
Last query:
Last reply:
Revision history for this message
Best Alexey Kopytov (akopytov) said : 		#1

Hello,

As of 1.6.4 and 1.9.0, the --copy-back option requires that the server's data directory (as specified in the backup-my.cnf file) is empty. It's just a sanity check to make sure it doesn't overwrite any files in the data directory. Please see https://bugs.launchpad.net/percona-xtrabackup/+bug/737569

Revision history for this message
kazushige uratani (kazushige-uratani) said : 		#2

Hello Valentine

Thank you for early support.

the bug report was checked and many things were tried,
unfortunately I was not able to solve.

Only a few should already give me advice.

The following is my.cnf.
----------------------------------------------------------------------------------------------------------------------
[mysqld]
datadir = /var/lib/mysql
#innodb_data_home_dir = # directory of innodb_data_file(_path). empty is datadir
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir = /var/lib/mysql/log_innodb/
innodb_log_files_in_group = 2
innodb_log_file_size = 1G
----------------------------------------------------------------------------------------------------------------------

The following is "backup-my.cnf" which "innobackupex" created.
----------------------------------------------------------------------------------------------------------------------
# This MySQL options file was generated by innobackupex.

# The MySQL server
[mysqld]
datadir=/var/data/backup
innodb_data_home_dir=/var/data/backup
innodb_data_file_path=ibdata1:10M:autoextend
innodb_log_group_home_dir=/var/data/backup
innodb_log_files_in_group=2
innodb_log_file_size=1073741824
----------------------------------------------------------------------------------------------------------------------

Although each path of "backup-my.cnf" differs from "my.cnf", does a setup have an error?

The following is a log at the time of restoration execution.
----------------------------------------------------------------------------------------------------------------------
uncompress /var/tmp/nprgree-db-02_20120313.tar.gz to /var/tmp/work

InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy
and Percona Inc 2009-2012. All Rights Reserved.

This software is published under
the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.

option_ibbackup_binary is autodetect, trying to connect to MySQL
Connected to MySQL with pid 9944
120406 15:37:35 innobackupex: Connection to database server closed
Connected successfully
120406 15:37:35 innobackupex: Starting mysql with options: --password=xxxxxxxx --user='root' --unbuffered --
120406 15:37:35 innobackupex: Connected to database with mysql child process (pid=9947)
120406 15:37:41 innobackupex: Connection to database server closed
IMPORTANT: Please check that the apply-log run completes successfully.
           At the end of a successful apply-log run innobackupex
           prints "completed OK!".

120406 15:37:41 innobackupex: Starting ibbackup with command: xtrabackup_55 --prepare --target-dir=/var/tmp/work --use-memory=1GB

xtrabackup_55 version 2.0.0 for Percona Server 5.5.16 Linux (x86_64) (revision id: undefined)
xtrabackup: cd to /var/tmp/work
xtrabackup: This target seems to be not prepared yet.
xtrabackup: xtrabackup_logfile detected: size=206045184, start_lsn=(464641132124)
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 = 206045184
120406 15:37:41 InnoDB: Using Linux native AIO
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 1073741824 bytes for buffer pool (set by --use-memory parameter)
120406 15:37:41 InnoDB: The InnoDB memory heap is disabled
120406 15:37:41 InnoDB: Mutexes and rw_locks use GCC atomic builtins
120406 15:37:41 InnoDB: Compressed tables use zlib 1.2.3
120406 15:37:41 InnoDB: Using Linux native AIO
120406 15:37:41 InnoDB: Warning: innodb_file_io_threads is deprecated. Please use innodb_read_io_threads and innodb_write_io_threads instead
120406 15:37:41 InnoDB: Initializing buffer pool, size = 1.0G
120406 15:37:41 InnoDB: Completed initialization of buffer pool
120406 15:37:41 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 464641132124
120406 15:37:41 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Doing recovery: scanned up to log sequence number 464646374912 (2 %)
InnoDB: Doing recovery: scanned up to log sequence number 464651617792 (5 %)
InnoDB: Doing recovery: scanned up to log sequence number 464656860672 (8 %)
InnoDB: Doing recovery: scanned up to log sequence number 464662103552 (11 %)
InnoDB: Doing recovery: scanned up to log sequence number 464667346432 (14 %)
InnoDB: Doing recovery: scanned up to log sequence number 464672589312 (17 %)
InnoDB: Doing recovery: scanned up to log sequence number 464677832192 (20 %)
InnoDB: Doing recovery: scanned up to log sequence number 464683075072 (22 %)
InnoDB: Doing recovery: scanned up to log sequence number 464688317952 (25 %)
InnoDB: Doing recovery: scanned up to log sequence number 464693560832 (28 %)
InnoDB: Doing recovery: scanned up to log sequence number 464698803712 (31 %)
InnoDB: Doing recovery: scanned up to log sequence number 464704046592 (34 %)
InnoDB: Doing recovery: scanned up to log sequence number 464709289472 (37 %)
InnoDB: Doing recovery: scanned up to log sequence number 464714532352 (40 %)
InnoDB: Doing recovery: scanned up to log sequence number 464719775232 (42 %)
InnoDB: Doing recovery: scanned up to log sequence number 464725018112 (45 %)
InnoDB: Doing recovery: scanned up to log sequence number 464730260992 (48 %)
InnoDB: Doing recovery: scanned up to log sequence number 464735503872 (51 %)
InnoDB: Doing recovery: scanned up to log sequence number 464740746752 (54 %)
InnoDB: Doing recovery: scanned up to log sequence number 464745989632 (57 %)
InnoDB: Doing recovery: scanned up to log sequence number 464751232512 (60 %)
InnoDB: Doing recovery: scanned up to log sequence number 464756475392 (62 %)
InnoDB: Doing recovery: scanned up to log sequence number 464761718272 (65 %)
InnoDB: Doing recovery: scanned up to log sequence number 464766961152 (68 %)
InnoDB: Doing recovery: scanned up to log sequence number 464772204032 (71 %)
InnoDB: Doing recovery: scanned up to log sequence number 464777446912 (74 %)
InnoDB: Doing recovery: scanned up to log sequence number 464782689792 (77 %)
InnoDB: Doing recovery: scanned up to log sequence number 464787932672 (80 %)
InnoDB: Doing recovery: scanned up to log sequence number 464793175552 (83 %)
InnoDB: Doing recovery: scanned up to log sequence number 464798418432 (85 %)
InnoDB: Doing recovery: scanned up to log sequence number 464803661312 (88 %)
InnoDB: Doing recovery: scanned up to log sequence number 464808904192 (91 %)
InnoDB: Doing recovery: scanned up to log sequence number 464814147072 (94 %)
InnoDB: Doing recovery: scanned up to log sequence number 464819389952 (97 %)
InnoDB: Doing recovery: scanned up to log sequence number 464824273791 (99 %)
120406 15:37:48 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 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 874332007, file name log_bin.000371
InnoDB: and relay log file
InnoDB: position 0 874332151, file name log_relay/log_relay.001068
InnoDB: Last MySQL binlog file position 0 573970436, file name log_bin/log_bin.000364
120406 15:38:52 InnoDB: Waiting for the background threads to start
120406 15:38:53 Percona XtraDB (http://www.percona.com) 1.1.8-20.1 started; log sequence number 464824273791

[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 573970436, file name log_bin/log_bin.000364

xtrabackup: starting shutdown with innodb_fast_shutdown = 1
120406 15:38:56 InnoDB: Starting shutdown...
120406 15:39:05 InnoDB: Shutdown completed; log sequence number 464824273791

120406 15:39:05 innobackupex: Restarting xtrabackup with command: xtrabackup_55 --prepare --target-dir=/var/tmp/work --use-memory=1GB
for creating ib_logfile*

xtrabackup_55 version 2.0.0 for Percona Server 5.5.16 Linux (x86_64) (revision id: undefined)
xtrabackup: cd to /var/tmp/work
xtrabackup: This target seems to be already prepared.
xtrabackup: notice: xtrabackup_logfile was already used to '--prepare'.
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 = 2
xtrabackup: innodb_log_file_size = 1073741824
120406 15:39:05 InnoDB: Using Linux native AIO
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 1073741824 bytes for buffer pool (set by --use-memory parameter)
120406 15:39:05 InnoDB: The InnoDB memory heap is disabled
120406 15:39:05 InnoDB: Mutexes and rw_locks use GCC atomic builtins
120406 15:39:05 InnoDB: Compressed tables use zlib 1.2.3
120406 15:39:05 InnoDB: Using Linux native AIO
120406 15:39:05 InnoDB: Warning: innodb_file_io_threads is deprecated. Please use innodb_read_io_threads and innodb_write_io_threads instead
120406 15:39:05 InnoDB: Initializing buffer pool, size = 1.0G
120406 15:39:05 InnoDB: Completed initialization of buffer pool
120406 15:39:05 InnoDB: Log file ./ib_logfile0 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile0 size to 1024 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: Progress in MB: 100 200 300 400 500 600 700 800 900 1000
120406 15:39:10 InnoDB: Log file ./ib_logfile1 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile1 size to 1024 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: Progress in MB: 100 200 300 400 500 600 700 800 900 1000
120406 15:39:15 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!
120406 15:39:15 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: In a MySQL replication slave the last master binlog file
InnoDB: position 0 874332007, file name log_bin.000371
InnoDB: and relay log file
InnoDB: position 0 874332151, file name log_relay/log_relay.001068
InnoDB: Last MySQL binlog file position 0 573970436, file name log_bin/log_bin.000364
120406 15:39:16 InnoDB: Waiting for the background threads to start
120406 15:39:17 Percona XtraDB (http://www.percona.com) 1.1.8-20.1 started; log sequence number 464824273932

[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 573970436, file name log_bin/log_bin.000364

xtrabackup: starting shutdown with innodb_fast_shutdown = 1
120406 15:39:18 InnoDB: Starting shutdown...
120406 15:39:21 InnoDB: Shutdown completed; log sequence number 464824273932
120406 15:39:21 innobackupex: completed OK!
 8853 pts/2 00:00:07 mysqld
Stopping MySQL (Percona Server): mysqld.

moved original datadir to /var/lib/_mysqldata~20120406_150328

InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy
and Percona Inc 2009-2012. All Rights Reserved.

This software is published under
the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.

IMPORTANT: Please check that the copy-back run completes successfully.
           At the end of a successful copy-back run innobackupex
           prints "completed OK!".

Original InnoDB log directory does not exist! at /usr/bin/innobackupex line 564.
Starting MySQL (Percona Server) database server: mysqld . . . . . . . . . . . . . . failed!
----------------------------------------------------------------------------------------------------------------------

Of course, if "copy-back" is changed into "OS's command", it will succeed.

Revision history for this message
Alexey Kopytov (akopytov) said : 		#3

Yes, the values in backup-my.cnf look clearly wrong.

Revision history for this message
kazushige uratani (kazushige-uratani) said : 		#4

Hello Valentine
Thank you for really early support.

Why "datadir" of "innobackupex" becomes "/var/data/backup"?
Could you tell me.

I think that a setup of "my.cnf" is correct though.

Please give me advice.
Sorry!!

Revision history for this message
kazushige uratani (kazushige-uratani) said : 		#5

It solved about this matter.

Thank you!!

Revision history for this message
kazushige uratani (kazushige-uratani) said : 		#6

Thanks Alexey Kopytov, that solved my question.