why do I need datadir ?

Bug #368945 reported by Percona on 2009-04-29
4
Affects Status Importance Assigned to Milestone
Percona XtraBackup moved to https://jira.percona.com/projects/PXB
Fix Released
Medium
Valentine Gostev

Bug Description

I am trying xtrabackup on empty box:

[root@backup1 percona]# xtrabackup --prepare --target-dir=/mnt/san1/backup/
xtrabackup: Error: Please set parameter 'datadir'

But I can start as:
[root@backup1 percona]# xtrabackup --prepare --target-dir=/mnt/san1/backup/ --datadir=/mnt/san1/backup

Question, why do I need to have datadir option ?

Related branches

Changed in percona-xtrabackup:
assignee: nobody → Yasufumi Kinoshita (yasufumi-kinoshita)
importance: Undecided → Medium
Will Bryant (will-bryant-gmail) wrote :

Can you still reproduce with the current version? I saw this with 1.0 but it seems to be fixed in 1.2.

Percona (percona-team) on 2010-11-25
Changed in percona-xtrabackup:
assignee: Yasufumi Kinoshita (yasufumi-kinoshita) → Alexey Kopytov (akopytov)
milestone: none → 1.6
Vadim Tkachenko (vadim-tk) wrote :

bug still exists in 1.4

Changed in percona-xtrabackup:
status: New → Confirmed
Valentine Gostev (longbow) wrote :

root@dev302:~# xtrabackup --datadir=/var/lib/mysql --backup --target-dir=/root/backup/www
xtrabackup Ver 1.5 Rev 203 for 5.1.53 unknown-linux-gnu (x86_64)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/mysql
xtrabackup: Target instance is assumed 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 = 5242880
>> log scanned up to (224373)
[01] Copying ./ibdata1
     to /root/backup/www/ibdata1
[01] ...done
xtrabackup: The latest check point (for incremental): '224373'
>> log scanned up to (224373)
xtrabackup: Stopping log copying thread.
xtrabackup: Transaction log of lsn (224373) to (224373) was copied.
root@dev302:~# xtrabackup --prepare --target-dir=/root/backup/www
xtrabackup Ver 1.5 Rev 203 for 5.1.53 unknown-linux-gnu (x86_64)
xtrabackup: cd to /root/backup/www
xtrabackup: This target seems to be not prepared yet.
xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(224373)
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
110217 23:46:06 InnoDB: highest supported file format is Barracuda.
110217 23:46:06 Percona XtraDB (http://www.percona.com) 1.0.13-12.4 started; log sequence number 224373

[notice (again)]
  If you use binary log and don't use any hack of group commit,
  the binary log position seems to be:

xtrabackup: starting shutdown with innodb_fast_shutdown = 1
110217 23:46:06 InnoDB: Starting shutdown...
110217 23:46:06 InnoDB: Shutdown completed; log sequence number 224373
root@dev302:~# echo $?
0
root@dev302:~# cat backup/www/xtrabackup_checkpoints
backup_type = full-prepared
from_lsn = 0
to_lsn = 224373
last_lsn = 224373

After that Percona Server was able to start with files restored from this backup

Changed in percona-xtrabackup:
milestone: 1.6 → 1.5
assignee: Alexey Kopytov (akopytov) → nobody
status: Confirmed → Fix Released
Vadim Tkachenko (vadim-tk) wrote :

Valentine, I think your test is incorrect.

The point of bug is that
--datadir parameter is not needed to perform --prepare stage, but xtrabackup requires it.

Changed in percona-xtrabackup:
status: Fix Released → New
milestone: 1.5 → 1.6
Changed in percona-xtrabackup:
status: New → Confirmed
Changed in percona-xtrabackup:
status: Confirmed → Triaged
assignee: nobody → Alexey Kopytov (akopytov)
Changed in percona-xtrabackup:
assignee: Alexey Kopytov (akopytov) → Valentine Gostev (core-longbow)
milestone: 1.6 → none
milestone: none → 1.7
Changed in percona-xtrabackup:
milestone: 1.7 → 1.6
status: Triaged → Fix Released

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXB-526

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers