[MDEV-11968] With innodb_page_size=8K crash with 'Error 17' after "Tried to read 65536 bytes at offset 0. Was only able to read 49152." Created: 2017-02-01  Updated: 2017-05-31  Resolved: 2017-05-15

Status: Closed
Project: MariaDB Server
Component/s: Backup
Affects Version/s: 10.1
Fix Version/s: 10.1.23

Type: Bug Priority: Major
Reporter: Andrii Nikitin (Inactive) Assignee: Vladislav Vaintroub
Resolution: Cannot Reproduce Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-11520 Extending an InnoDB data file unneces... Closed
relates to MDEV-11556 InnoDB redo log apply fails to adjust... Closed

 Description   

Backup on empty database created with innodb_page_size=8K intentionally crashes trying to read 65K from ibdata1 :

170201 15:29:20 Connecting to MySQL server host: localhost, user: root, password: not set, port: 3306, socket: /farm/m0-bb-10.1-wlad-xtrabackup/my.sock
Using server version 10.1.21-MariaDB
/farm/m0-bb-10.1-wlad-xtrabackup/build/extra/xtrabackup/xtrabackup based on MariaDB server 10.1.21-MariaDB Linux (x86_64)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /farm/m0-bb-10.1-wlad-xtrabackup/dt
xtrabackup: open files limit requested 0, set to 1048576
InnoDB: The universal page size of the database is set to 8192.
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
170201 15:30:30 >> log scanned up to (927384)
170201 15:30:31 >> log scanned up to (927384)
...
170201 15:31:05 >> log scanned up to (927384)
xtrabackup: Generating a list of tablespaces
170201 15:31:06 >> log scanned up to (927384)
...
170201 15:32:35 >> log scanned up to (927384)
170201 15:32:36 >> log scanned up to (927384)
170201 15:32:37 [01] Copying ./ibdata1 to /farm/m0-bb-10.1-wlad-xtrabackup/bkup/ibdata1
170201 15:32:37 [01]        ...done
InnoDB: Tried to read 65536 bytes at offset 0. Was only able to read 49152.
InnoDB: Fatal error: cannot read from file. OS error number 17.
2017-02-01 15:32:37 7f4bddffd700  InnoDB: Assertion failure in thread 139963823806208 in file os0file.cc line 3226
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.
170201 15:32:37 [ERROR] mysqld got signal 6 ;
...
stack_bottom = 0x0 thread_stack 0x48400
/farm/m0-bb-10.1-wlad-xtrabackup/build/extra/xtrabackup/xtrabackup(my_print_stacktrace+0x29)[0x55c259874519]
170201 15:32:37 >> log scanned up to (927384)
/farm/m0-bb-10.1-wlad-xtrabackup/build/extra/xtrabackup/xtrabackup(handle_fatal_signal+0x2f5)[0x55c25945e395]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7f4be42d1390]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38)[0x7f4be2765428]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7f4be276702a]
/farm/m0-bb-10.1-wlad-xtrabackup/build/extra/xtrabackup/xtrabackup(+0x8dffb3)[0x55c259790fb3]
/farm/m0-bb-10.1-wlad-xtrabackup/build/extra/xtrabackup/xtrabackup(_Z15xb_get_zip_sizei+0xe5)[0x55c25923c815]
/farm/m0-bb-10.1-wlad-xtrabackup/build/extra/xtrabackup/xtrabackup(_Z15xb_fil_cur_openP12xb_fil_cur_tP14xb_read_filt_tP10fil_node_tj+0x1dd)[0x55c2592464dd]
/farm/m0-bb-10.1-wlad-xtrabackup/build/extra/xtrabackup/xtrabackup(+0x38b967)[0x55c25923c967]
/farm/m0-bb-10.1-wlad-xtrabackup/build/extra/xtrabackup/xtrabackup(+0x38bcb2)[0x55c25923ccb2]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba)[0x7f4be42c76ba]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f4be283682d]

# du -ah
256K    ./xtrabackup_logfile
12M     ./ibdata1

Om Windows error is little different and exits without crash :

xtrabackup: open files limit requested 0, set to 0
InnoDB: The universal page size of the database is set to 8192.
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
InnoDB: Created tablespace for space 4294967280 name .\ib_logfile0 key_id 0 encryption 0.
170201 16:40:56 >> log scanned up to (927384)
InnoDB: Created tablespace for space 0 name .\ibdata1 key_id 1 encryption 0.
xtrabackup: Generating a list of tablespaces
InnoDB: Created tablespace for space 1 name mysql/innodb_table_stats key_id 0 encryption 0.
InnoDB: Created tablespace for space 2 name mysql/innodb_index_stats key_id 0 encryption 0.
InnoDB: Created tablespace for space 3 name mysql/gtid_slave_pos key_id 0 encryption 0.
170201 16:40:56 [01] Copying .\ibdata1 to O:\f1\m1-bb-10.1-wlad-xtrabackup\bkup\ibdata1
170201 16:40:56 [01]        ...done
 InnoDB: Operation read to file O:\f1\_depot\m-branch\bb-10.1-wlad-xtrabackup\storage\xtradb\os\os0file.cc and at line 3209
InnoDB: File (unknown): 'read' returned OS error 0. Cannot continue operation

O:\f1\m1-bb-10.1-wlad-xtrabackup\bkup>dir -s
total 12544
12288 ibdata1    256 xtrabackup_logfile



 Comments   
Comment by Andrii Nikitin (Inactive) [ 2017-05-15 ]

It looks that I cannot repeat this problem in released 10.1.23 , closing as the bug was never shipped and resolved by similar fixes before release.

Using server version 10.1.23-MariaDB
InnoDB: The universal page size of the database is set to 8192.
...
170515 19:22:21 completed OK!

Comment by Marko Mäkelä [ 2017-05-31 ]

There have been some recent improvements to the file size handling, most notably MDEV-11520 and MDEV-11556.

Because this bug was filed against Mariabackup, it is possible that this is simply a duplicate of MDEV-11556, which implements proper extension of InnoDB data files during redo log based recovery.

Generated at Thu Feb 08 07:54:03 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.