--stats does not work
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| Percona XtraBackup moved to https://jira.percona.com/projects/PXB |
Fix Released
|
Medium
|
Alexey Kopytov |
Bug Description
I created a partial backup:
[baron@ginger ~]$ xtrabackup --backup --target-
xtrabackup: table 'test/t1' is registerd to the list.
xtrabackup: table 'test/t2' is registerd to the list.
....
Then I prepared it,
[baron@ginger ~]$ xtrabackup --prepare --target-
That all worked fine, then I tried to use --stats. The first time I did it, it created zero-sized ib_logfiles. It should have not done that! Then it crashed. I thought that maybe it failed because the partial backup caused a problem. I ran it again with --tables, and this time, it failed because it expected the log files to be 5MB.
[baron@ginger ~]$ xtrabackup --stats --data-dir=backups/
xtrabackup Ver undefined Rev undefined for 5.1.47 pc-linux-gnu (i686)
xtrabackup: Can't change dir to '/var/lib/mysql' (Errcode: 2)
xtrabackup: cannot my_setwd /var/lib/mysql
[baron@ginger ~]$ xtrabackup --stats --datadir=backups/
xtrabackup Ver undefined Rev undefined for 5.1.47 pc-linux-gnu (i686)
xtrabackup: cd to backups/
xtrabackup: Target instance is assumed as followings.
xtrabackup: innodb_
xtrabackup: innodb_
xtrabackup: innodb_
xtrabackup: innodb_
xtrabackup: innodb_
xtrabackup: Starting 'read-only' InnoDB instance to gather index statistics.
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
101107 22:46:32 InnoDB: Log file ./ib_logfile0 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile0 size to 5 MB
InnoDB: Database physically writes the file full: wait...
101107 22:46:32 InnoDB: Log file ./ib_logfile1 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile1 size to 5 MB
InnoDB: Database physically writes the file full: wait...
101107 22:46:32 InnoDB: highest supported file format is Barracuda.
InnoDB: Error: tried to read 512 bytes at offset 0 512.
InnoDB: Was only able to read 0.
InnoDB: Fatal error: cannot read from file. OS error number 17.
101107 22:46:32 InnoDB: Assertion failure in thread 3079362768 in file os/os0file.c line 2461
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://
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://
InnoDB: about forcing recovery.
Aborted (core dumped)
[baron@ginger ~]$ xtrabackup --stats --datadir=backups/ --tables=t1
xtrabackup: tables regcomp(t1): Success
xtrabackup Ver undefined Rev undefined for 5.1.47 pc-linux-gnu (i686)
xtrabackup: cd to backups/
xtrabackup: Target instance is assumed as followings.
xtrabackup: innodb_
xtrabackup: innodb_
xtrabackup: innodb_
xtrabackup: innodb_
xtrabackup: innodb_
xtrabackup: Starting 'read-only' InnoDB instance to gather index statistics.
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: Error: log file ./ib_logfile0 is of different size 0 0 bytes
InnoDB: than specified in the .cnf file 0 5242880 bytes!
xtrabackup: innodb_init(): Error occured.
[baron@ginger ~]$ ls -lh backups/
total 21M
-rw-rw-r-- 1 baron baron 18M Nov 7 22:31 ibdata1
-rw-rw-r-- 1 baron baron 0 Nov 7 22:46 ib_logfile0
-rw-rw-r-- 1 baron baron 0 Nov 7 22:46 ib_logfile1
drwx------ 2 baron baron 4.0K Nov 7 22:12 test
drwx------ 2 baron baron 4.0K Nov 7 22:12 test1
-rw-rw-r-- 1 baron baron 59 Nov 7 22:31 xtrabackup_
-rw-rw-r-- 1 baron baron 2.0M Nov 7 22:31 xtrabackup_logfile
Related branches
- Vadim Tkachenko: Approve on 2011-03-28
-
Diff: 82 lines (+60/-0)2 files modifiedtest/t/xb_stats.sh (+36/-0)
xtrabackup.c (+24/-0)
Changed in percona-xtrabackup: | |
assignee: | nobody → Alexey Kopytov (akopytov) |
milestone: | none → 1.6 |
importance: | Undecided → Medium |
Vadim Tkachenko (vadim-tk) wrote : | #1 |
Changed in percona-xtrabackup: | |
assignee: | Alexey Kopytov (akopytov) → Valentine Gostev (core-longbow) |
Changed in percona-xtrabackup: | |
status: | New → Confirmed |
Changed in percona-xtrabackup: | |
assignee: | Valentine Gostev (core-longbow) → Vadim Tkachenko (vadim-tk) |
tags: | added: xtrabackup |
Changed in percona-xtrabackup: | |
milestone: | 1.6 → 1.7 |
Changed in percona-xtrabackup: | |
status: | Confirmed → In Progress |
Alexey Kopytov (akopytov) wrote : | #2 |
The xtrabackup manual says:
"
... to use the statistics feature, you need a clean copy of the database including correctly sized log files, so you need to execute with --prepare twice to use this functionality on a backup.
"
http://
Since the crash reported in this bug was caused by missing log files when using the --stats option, the fix should be to make xtrabackup --stats refuse to run with a descriptive error message when no log files have been found rather than trying to create them and crash.
Changed in percona-xtrabackup: | |
status: | In Progress → Fix Committed |
Changed in percona-xtrabackup: | |
status: | Fix Committed → Fix Released |
Changed in percona-xtrabackup: | |
assignee: | Vadim Tkachenko (vadim-tk) → Alexey Kopytov (akopytov) |
Shahriyar Rzayev (rzayev-sehriyar) wrote : | #3 |
Percona now uses JIRA for bug reports so this bug report is migrated to: https:/
Assigned to Valentine to create test case