Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.2.16
-
None
Description
If you have a custom InnoDB system tablespace defined (i.e. not ibdata1) and if you also have a custom undo tablespace defined, then mariabackup incorrectly tries to open ibdata1 in addition to the custom InnoDB system tablespace.
For example, let's say that you have the following configuration file:
[mariadb-10.2]
|
log_error=mysqld.err
|
datadir=/datadir
|
innodb_data_home_dir=/datadir/data
|
innodb_data_file_path = ib_mysql2_01:1G:autoextend
|
innodb_log_group_home_dir = /datadir/logs
|
innodb_undo_directory = /datadir/undologs
|
innodb_undo_log_truncate = 1
|
innodb_undo_logs = 128
|
innodb_undo_tablespaces = 32
|
And let's say that you try to backup the system with mariabackup in the following way:
mariabackup --backup --databases=mysql --no-lock --parallel=10 --compress --compress-threads=10 --user=root --target-dir=/home/ec2-user/backup
|
It will fail with the following error:
180918 18:26:12 Connecting to MySQL server host: localhost, user: root, password: not set, port: not set, socket: not set
|
Using server version 10.2.16-MariaDB
|
Loading encryption plugin
|
Encryption plugin parameter : '--aws_key_management_key_spec=AES_128'
|
Encryption plugin parameter : '--aws_key_management_log_level=Off'
|
Encryption plugin parameter : '--aws_key_management_master_key_id='
|
Encryption plugin parameter : '--aws_key_management_region='
|
Encryption plugin parameter : '--aws_key_management_request_timeout=0'
|
Encryption plugin parameter : '--aws_key_management_rotate_key=0'
|
mariabackup based on MariaDB server 10.2.16-MariaDB Linux (x86_64)
|
mariabackup: uses posix_fadvise().
|
mariabackup: cd to /datadir/data/
|
mariabackup: open files limit requested 0, set to 1024
|
mariabackup: using the following InnoDB configuration:
|
mariabackup: innodb_data_home_dir = /datadir/data
|
mariabackup: innodb_data_file_path = ib_mysql2_01:1G:autoextend
|
mariabackup: innodb_log_group_home_dir = /datadir/logs
|
2018-09-18 18:26:12 139964570237056 [Note] InnoDB: Number of pools: 1
|
2018-09-18 18:26:12 139964570237056 [ERROR] InnoDB: Operating system error number 2 in a file operation.
|
2018-09-18 18:26:12 139964570237056 [ERROR] InnoDB: The error means the system cannot find the path specified.
|
2018-09-18 18:26:12 139964570237056 [ERROR] InnoDB: If you are installing InnoDB, remember that you must create directories yourself, InnoDB does not create them.
|
2018-09-18 18:26:12 139964570237056 [ERROR] InnoDB: File /datadir/data/ibdata1: 'open' returned OS error 71. Cannot continue operation
|
180918 18:26:12 [ERROR] mysqld got signal 6 ;
|
This could be because you hit a bug. It is also possible that this binary
|
or one of the libraries it was linked against is corrupt, improperly built,
|
or misconfigured. This error can also be caused by malfunctioning hardware.
|
|
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
|
|
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.
|
|
Server version: 10.2.16-MariaDB
|
key_buffer_size=0
|
read_buffer_size=131072
|
max_used_connections=0
|
max_threads=1
|
thread_count=0
|
It is possible that mysqld could use up to
|
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 5422 K bytes of memory
|
Hope that's ok; if not, decrease some variables in the equation.
|
|
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 = 0x0 thread_stack 0x49000
|
addr2line: 'mariabackup': No such file
|
mariabackup(my_print_stacktrace+0x2e)[0x7f4c0b43391e]
|
mariabackup(handle_fatal_signal+0x355)[0x7f4c0af1ffb5]
|
sigaction.c:0(__restore_rt)[0x7f4c0a3ea370]
|
:0(__GI_raise)[0x7f4c089741d7]
|
:0(__GI_abort)[0x7f4c089758c8]
|
addr2line: 'mariabackup': No such file
|
mariabackup(+0x9aeff5)[0x7f4c0b1c7ff5]
|
mariabackup(+0x423bcf)[0x7f4c0ac3cbcf]
|
mariabackup(+0x424142)[0x7f4c0ac3d142]
|
mariabackup(+0x45cc8a)[0x7f4c0ac75c8a]
|
mariabackup(main+0x185)[0x7f4c0ac53365]
|
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f4c08960b35]
|
addr2line: 'mariabackup': No such file
|
mariabackup(+0x4539cd)[0x7f4c0ac6c9cd]
|
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
|
information that should help you find out what is causing the crash.
|
strace shows that mariabackup tries to open both the custom InnoDB system tablespace and the default system tablespace (i.e. ibdata1):
stat("/datadir/data/ib_mysql2_01", {st_mode=S_IFREG|0660, st_size=1073741824, ...}) = 0
|
access("/datadir/data/ib_mysql2_01", R_OK) = 0
|
open("/datadir/data/ib_mysql2_01", O_RDONLY|O_CLOEXEC) = 6
|
fstat(6, {st_mode=S_IFREG|0660, st_size=1073741824, ...}) = 0
|
mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f4c0a61d000
|
pread64(6, "\230\267R\365\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\27\200\300\0\10\0\0\0\0\0\27"..., 65536, 0) = 65536
|
close(6) = 0
|
open("/datadir/data/ibdata1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
|
Attachments
Issue Links
- is caused by
-
MDEV-13561 Mariabackup is incompatible with retroactively created innodb_undo_tablespaces
- Closed