160906 16:03:31 innobackupex: Starting the backup operation
|
|
IMPORTANT: Please check that the backup run completes successfully.
|
At the end of a successful backup run innobackupex
|
prints "completed OK!".
|
|
160906 16:03:31 Connecting to MySQL server host: localhost, user: backup, password: set, port: 0, socket: /var/lib/mysql/mysql.sock
|
Using server version 10.1.16-MariaDB
|
innobackupex version 2.3.3 based on MySQL server 5.6.24 Linux (x86_64) (revision id: 525ca7d)
|
xtrabackup: uses posix_fadvise().
|
xtrabackup: cd to /var/lib/mysql/
|
xtrabackup: open files limit requested 0, set to 16364
|
xtrabackup: using the following InnoDB configuration:
|
xtrabackup: innodb_data_home_dir = ./
|
xtrabackup: innodb_data_file_path = ibdata1:12M:autoextend
|
xtrabackup: innodb_log_group_home_dir = ./
|
xtrabackup: innodb_log_files_in_group = 2
|
xtrabackup: innodb_log_file_size = 50331648
|
160906 16:03:31 >> log scanned up to (44011183)
|
2016-09-06 16:03:31 7f48af035740 InnoDB: Operating system error number 2 in a file operation.
|
InnoDB: The error means the system cannot find the path specified.
|
InnoDB: File ./ibdata1: 'open' returned OS error 71. Cannot continue operation
|
2016-09-06 16:03:31 7f48af035740 InnoDB: Assertion failure in thread 139950150604608 in file os0file.cc line 658
|
InnoDB: We intentionally generate a memory trap.
|
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
|
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://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
|
InnoDB: about forcing recovery.
|
20:03:31 UTC - xtrabackup got signal 6 ;
|
This could be because you hit a bug or data is corrupted.
|
This error can also be caused by malfunctioning hardware.
|
We will try our best to scrape up some info that will hopefully help
|
diagnose the problem, but since we have already crashed,
|
something is definitely wrong and this may 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
|
innobackupex(my_print_stacktrace+0x2e) [0x96c7be]
|
innobackupex(handle_fatal_signal+0x262) [0x84cbc2]
|
/lib64/libpthread.so.0(+0xf100) [0x7f48aec17100]
|
/lib64/libc.so.6(gsignal+0x37) [0x7f48ad3815f7]
|
/lib64/libc.so.6(abort+0x148) [0x7f48ad382ce8]
|
innobackupex(os_file_create_func(char const*, unsigned long, unsigned long, unsigned long, unsigned long*)+0x46c) [0x6a386c]
|
innobackupex(open_or_create_data_files(unsigned long*, unsigned long*, unsigned long*, unsigned long*)+0x3b2) [0x706b52]
|
innobackupex() [0x59464c]
|
innobackupex(xtrabackup_backup_func()+0x9a4) [0x599cc4]
|
innobackupex(main+0x9a2) [0x57dd92]
|
/lib64/libc.so.6(__libc_start_main+0xf5) [0x7f48ad36db15]
|
innobackupex() [0x591bfd]
|
|
Please report a bug at https://bugs.launchpad.net/percona-xtrabackup
|