[MDEV-14342] Importing partial backup from XtraBackup can sometimes crash server Created: 2017-11-09  Updated: 2020-08-25  Resolved: 2017-11-17

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 10.2.9, 10.2.10
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Geoff Montee (Inactive) Assignee: Andrii Nikitin (Inactive)
Resolution: Not a Bug Votes: 1
Labels: crash, innodb, xtrabackup

Issue Links:
Duplicate
is duplicated by MDEV-20931 ALTER...IMPORT can crash the server Closed
Relates
relates to MDEV-20974 Don't require .cfg files to import In... Closed

 Description   

I'm not sure if this is a bug in the server or a bug in XtraBackup, but sometimes importing a partial backup made with XtraBackup can cause the server to crash.

The backup is made and prepared in the following way:

xtrabackup --backup --parallel=4 --databases=my_schema --target-dir=${TARGET_DIR}
xtrabackup --prepare --export --target-dir=${TARGET_DIR}

And then to restore the backup, we get a list of table names, discard the tablespaces for those tables, and then import them from the backup:

TABLES=$(mysql -u root --batch --skip-column-names --execute="SELECT GROUP_CONCAT(TABLE_NAME SEPARATOR ' ') FROM information_schema.TABLES WHERE TABLE_SCHEMA='my_schema' GROUP BY TABLE_SCHEMA")
for TABLE in ${TABLES}; do
mysql -u root -B my_schema -e "SET foreign_key_checks = 0; ALTER TABLE \`${TABLE}\` DISCARD TABLESPACE; SET foreign_key_checks = 1"
done;
cp -vn ${TARGET_DIR}/my_schema/*.exp /var/lib/mysql/my_schema/
cp -vn ${TARGET_DIR}/my_schema/*.frm /var/lib/mysql/my_schema/
cp -vn ${TARGET_DIR}/my_schema/*.ibd /var/lib/mysql/my_schema/
chown mysql:mysql /var/lib/mysql/my_schema/*
for TABLE in ${TABLES}; do
mysql -u root -B my_schema -e "ALTER TABLE \`${TABLE}\` IMPORT TABLESPACE"
done;

The last step crashes with some backups:

2017-11-09 16:03:39 140282653591296 [Note] InnoDB: Phase I - Update all pages
2017-11-09 16:03:39 140282653591296 [Note] InnoDB: Sync to disk
2017-11-09 16:03:39 140282653591296 [Note] InnoDB: Sync to disk - done!
2017-11-09 16:03:39 140282653591296 [Note] InnoDB: Phase III - Flush changes to disk
2017-11-09 16:03:39 140282653591296 [Note] InnoDB: Phase IV - Flush complete
2017-11-09 16:03:39 140282653591296 [ERROR] [FATAL] InnoDB: Trying to read page number 1664705849 in space 34, space name my_schema/my_tab, which is outside the tablespace bounds. Byte offset 0, len 16384
171109 16:03:39 [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.9-MariaDB-debug-log
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=1
max_threads=153
thread_count=10
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467321 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x7f961002a530
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 = 0x7f9619bc3d80 thread_stack 0x49000
/usr/sbin/mysqld(my_print_stacktrace+0x38)[0x7f963238a797]
/usr/sbin/mysqld(handle_fatal_signal+0x39e)[0x7f9631c213c4]
/lib64/libpthread.so.0(+0xf370)[0x7f9630fc9370]
/lib64/libc.so.6(gsignal+0x37)[0x7f962f1371d7]
/lib64/libc.so.6(abort+0x148)[0x7f962f1388c8]
/usr/sbin/mysqld(+0xd5b6d5)[0x7f96321536d5]
mysys/stacktrace.c:267(my_print_stacktrace)[0x7f9632242acd]
fil/fil0fil.cc:5134(fil_report_invalid_page_access(unsigned long, unsigned long, char const*, unsigned long, unsigned long, bool))[0x7f9632243155]
buf/buf0rea.cc:183(buf_read_page_low(dberr_t*, bool, unsigned long, unsigned long, page_id_t const&, page_size_t const&, bool, bool))[0x7f96321dd4b8]
buf/buf0rea.cc:436(buf_read_page(page_id_t const&, page_size_t const&))[0x7f96321ddea7]
buf/buf0buf.cc:4314(buf_page_get_gen(page_id_t const&, page_size_t const&, unsigned long, buf_block_t*, unsigned long, char const*, unsigned int, mtr_t*, dberr_t*))[0x7f96321b2a1a]
dict/dict0stats.cc:1549(dict_stats_analyze_index_below_cur(btr_cur_t const*, unsigned long, unsigned long*, unsigned long*))[0x7f9632223152]
dict/dict0stats.cc:1841(dict_stats_analyze_index_for_n_prefix(dict_index_t*, unsigned long, std::vector<unsigned long, ut_allocator<unsigned long, true> > const*, n_diff_data_t*, mtr_t*))[0x7f9632223954]
dict/dict0stats.cc:2067(dict_stats_analyze_index(dict_index_t*))[0x7f963222460f]
dict/dict0stats.cc:2269(dict_stats_update_persistent(dict_table_t*))[0x7f96322248a8]
dict/dict0stats.cc:3228(dict_stats_update(dict_table_t*, dict_stats_upd_option_t))[0x7f9632226ecb]
handler/ha_innodb.cc:13622(ha_innobase::discard_or_import_tablespace(char))[0x7f9631f4ad4f]
sql/handler.cc:4198(handler::ha_discard_or_import_tablespace(char))[0x7f9631c2c480]
sql/sql_table.cc:5714(mysql_discard_or_import_tablespace(THD*, TABLE_LIST*, bool))[0x7f9631a74147]
sql/sql_alter.cc:364(Sql_cmd_discard_import_tablespace::execute(THD*))[0x7f9631af820e]
sql/sql_parse.cc:6203(mysql_execute_command(THD*))[0x7f96319b21e9]
sql/sql_parse.cc:7875(mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool))[0x7f96319b6bd4]
sql/sql_parse.cc:7691(wsrep_mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool))[0x7f96319b6271]
sql/sql_parse.cc:1809(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool))[0x7f96319a4505]
sql/sql_parse.cc:1360(do_command(THD*))[0x7f96319a2e13]
sql/sql_connect.cc:1354(do_handle_one_connection(CONNECT*))[0x7f9631af2d0d]
sql/sql_connect.cc:1261(handle_one_connection)[0x7f9631af2a6d]
/lib64/libpthread.so.0(+0x7dc5)[0x7f9630fc1dc5]
/lib64/libc.so.6(clone+0x6d)[0x7f962f1f973d]
 
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x7f961003a888): ALTER TABLE `my_tab` IMPORT TABLESPACE
Connection ID (thread ID): 73
Status: NOT_KILLED



 Comments   
Comment by Elena Stepanova [ 2017-11-09 ]

anikitin, it's not exactly MariaBackup, but could you please take a look anyway, maybe you've already dealt with it before.

Comment by Andrii Nikitin (Inactive) [ 2017-11-10 ]

The steps are not copying *.cfg files from database directory, i.e. step like this:

cp -vn ${TARGET_DIR}/my_schema/*.cfg /var/lib/mysql/my_schema/

I expect that the crash will not happen when .cnf files are properly restored.

Comment by Andrii Nikitin (Inactive) [ 2017-11-17 ]

Closing because the crash doesn't happen when .cfg file is copied from backup

Generated at Thu Feb 08 08:12:48 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.