xtrabackup 2.3/2.4 fails after backup/prepare is completed when --defaults-file points to non-existing file
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
Percona XtraBackup moved to https://jira.percona.com/projects/PXB | Status tracked in 2.4 | |||||
2.3 |
Triaged
|
Medium
|
Sergei Glushchenko | |||
2.4 |
Fix Released
|
Undecided
|
Sergei Glushchenko |
Bug Description
Using binary from -> https:/
As Documentation states:
https:/
"--defaults-
It is turns out that --defaults-file must be path to backup-my.cnf otherwise it will append to current working directory:
[root@mysql-57 bin]# ./xtrabackup --defaults-
xtrabackup: [ERROR] Could not open required defaults file: /usr/local/
xtrabackup: [ERROR] Fatal error in defaults handling. Program aborted!
Interesting note from stderr:
InnoDB: Loading buffer pool(s) from /home/backup_
InnoDB: not started
InnoDB: Cannot open '/home/
(null) is created in backup directory:
[root@mysql-57 full]# ls
backup-my.cnf ib_buffer_pool ib_logfile0 ibtmp1 (null) sys xtrabackup_info
bck ibdata1 ib_logfile1 mysql performance_schema xtrabackup_
And the result is:
InnoDB: Shutdown completed; log sequence number 2491944
completed OK!
11:08:21 UTC - xtrabackup got signal 11 ;
This could be because you hit a bug or data is corrupted.
This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x10000
./xtrabackup(
./xtrabackup(
/lib64/
./xtrabackup(
./xtrabackup(
./xtrabackup(
/lib64/
./xtrabackup[
Changed in percona-xtrabackup: | |
status: | Confirmed → Triaged |
summary: |
- xtrabackup got signal 11 while preparing backup with MySQL 5.7.10 + xtrabackup 2.3/2.4 fails after backup is completed when --defaults-file + points to non-existing file |
summary: |
- xtrabackup 2.3/2.4 fails after backup is completed when --defaults-file - points to non-existing file + xtrabackup 2.3/2.4 fails after backup/prepare is completed when + --defaults-file points to non-existing file |
Full log:
[root@mysql-57 bin]# ./xtrabackup --prepare --target- dir=/home/ backup_ dir/full/ --defaults- file=backup- my.cnf file=backup- my.cnf --prepare --target- dir=/home/ backup_ dir/full/ xtrabackup/ bin/backup- my.cnf dir/full data_home_ dir = . data_file_ path = ibdata1: 10M:autoextend log_group_ home_dir = . log_files_ in_group = 1 log_file_ size = 2097152 data_home_ dir = . data_file_ path = ibdata1: 10M:autoextend log_group_ home_dir = . log_files_ in_group = 1 log_file_ size = 2097152 thread_ fence() is used for memory barrier dir/full/ (null) backup_ dir/full/ (null)' for reading: No such file or directory
xtrabackup: Error: --defaults-file must be specified first on the command line
[root@mysql-57 bin]# ./xtrabackup --defaults-
xtrabackup: [ERROR] Could not open required defaults file: /usr/local/
xtrabackup: [ERROR] Fatal error in defaults handling. Program aborted!
./xtrabackup version 2.3.1beta1 based on MySQL server 5.7.10 Linux (x86_64) (revision id: )
xtrabackup: cd to /home/backup_
xtrabackup: This target seems to be not prepared yet.
InnoDB: Number of pools: 1
xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(2491701)
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_
xtrabackup: innodb_
xtrabackup: innodb_
xtrabackup: innodb_
xtrabackup: innodb_
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_
xtrabackup: innodb_
xtrabackup: innodb_
xtrabackup: innodb_
xtrabackup: innodb_
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: PUNCH HOLE support available
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Uses event mutexes
InnoDB: GCC builtin __atomic_
InnoDB: Compressed tables use zlib 1.2.7
InnoDB: Number of pools: 1
InnoDB: Using CPU crc32 instructions
InnoDB: Initializing buffer pool, total size = 100M, instances = 1, chunk size = 100M
InnoDB: Completed initialization of buffer pool
InnoDB: page_cleaner coordinator priority: -20
InnoDB: Highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 2491701
InnoDB: Doing recovery: scanned up to log sequence number 2491710 (0%)
InnoDB: Doing recovery: scanned up to log sequence number 2491710 (0%)
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: Creating shared tablespace for temporary tables
InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
InnoDB: File './ibtmp1' size is now 12 MB.
InnoDB: 96 redo rollback segment(s) found. 1 redo rollback segment(s) are active.
InnoDB: 32 non-redo rollback segment(s) are active.
InnoDB: 5.7.10 started; log sequence number 2491710
InnoDB: Loading buffer pool(s) from /home/backup_
InnoDB: not started
InnoDB: Cannot open '/home/
[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 dir/full/ (null)
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Dumping buffer pool(s) to /home/backup_
InnoDB: Buffer pool(s) dum...