XtraBackup crashes in prepare stage on MariaDB 10.1
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Percona XtraBackup moved to https://jira.percona.com/projects/PXB |
New
|
Undecided
|
Unassigned |
Bug Description
A user saw the following crash with XtraBackup 2.4.1 while attempting to prepare a backup that was taken on a MariaDB 10.1.11 server:
2016-12-20 21:00:59 0x7ff5f3ec4740 InnoDB: Assertion failure in thread 140694336063296 in file fil0fil.cc line 3681
InnoDB: Failing assertion: fsp_flags_
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://
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://
InnoDB: about forcing recovery.
04:00:59 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.
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
innobackupex(
innobackupex(
/lib64/
/lib64/
/lib64/
innobackupex[
innobackupex(
innobackupex[
innobackupex[
innobackupex[
innobackupex(
innobackupex(
innobackupex[
innobackupex(
/lib64/
innobackupex[
No other errors occurred prior to this during the backup stage or the prepare stage.
This server is not using MariaDB-specific InnoDB features, such as tablespace encryption or page compression. However, the server does have innodb_page_size set to 64k.
XtraBackup 2.4.1 could apparently back up this server until a couple days ago, and then the crashing started to happen. As far as the user knows, nothing interesting has changed on the server since then. Since the crash started happening, the crash is 100% reproducible on this server, and backups can no longer be prepared.
Here is the server's configuration file:
[mariadb]
plugin-
# -- Remove the following line to enable feedback reporting to mariadb.org
feedback-url=''
[mysqld]
enable-secure-auth
# -- Auditing - pre-load Plugin
##plugin-
[mysqld]
port = 3306
socket = /var/lib/
datadir = /mariadb/data/
userstat = 1
key_buffer_size = 256M
max_allowed_packet = 1M
table_cache = 256
sort_buffer_size = 1M
myisam_
thread_cache_size = 8
max_connections = 300
tmpdir = /mariadb/temp/
log_error = /mariadb/
innodb_
innodb_
innodb_
innodb_
innodb_
innodb_page_size = 65536
log-bin=
server_id=1
innodb_
innodb_
innodb_
innodb_
innodb_
innodb_
innodb_log_archive = 1
innodb_log_arch_dir = /mariadb/arch
#skip-name-resolve
log_bin_
#max-allowed-packet = 64M
open-files-limit = 65535
max-connect-errors = 100000
max-connections = 1000
thread-cache-size = 200
back-log = 128
#net_buffer_length = 16K
#connect_timeout = 10
#net_read_timeout = 30
#net_write_timeout = 60
#interactive_
#wait_timeout = 28800
#net_retry_count = 10
character-
collation-server = 'utf8_general_ci'
#read_rnd_
#sort_buffer_size = 2M
#read_buffer_size = 128K
#max_tmp_tables = 32
tmp-table-size = 32M
max-heap-table-size = 32M
sql-mode = STRICT_TRANS_TABLES
optimizer_
optimizer_switch = 'index_merge=on'
optimizer_switch = 'index_
optimizer_switch = 'index_
optimizer_switch = 'index_
optimizer_switch = 'index_
optimizer_switch = 'index_
optimizer_switch = 'derived_merge=on'
optimizer_switch = 'derived_
optimizer_switch = 'firstmatch=on'
optimizer_switch = 'loosescan=on'
optimizer_switch = 'materializatio
optimizer_switch = 'in_to_exists=on'
optimizer_switch = 'semijoin=on'
optimizer_switch = 'partial_
optimizer_switch = 'partial_
optimizer_switch = 'subquery_
optimizer_switch = 'mrr_cost_based=on'
optimizer_switch = 'mrr_sort_keys=off'
optimizer_switch = 'outer_
optimizer_switch = 'semijoin_
optimizer_switch = 'join_cache_
optimizer_switch = 'join_cache_
optimizer_switch = 'join_cache_bka=on'
optimizer_switch = 'optimize_
optimizer_switch = 'table_
optimizer_switch = 'extended_keys=on'
join-buffer-
join-cache-level = 6
join-buffer-size = 4M
# Security
symbolic-links = 0
local-infile = 0
# Logging
log-warnings = 2
slow-query-log = 1
long-query-time = 5
log-slow-verbosity = 'query_plan,innodb'
#log_slow_
#server-id = 1
slave_net_timeout = 60
#max_prepared_
binlog-
#log-bin = mariadb-bin
binlog-format = MIXED
expire-logs-days = 7
max-binlog-size = 1024M
sync-binlog = 1
binlog-
binlog-cache-size = 256K
#slave_
slave-transacti
#relay_log_recovery = ON
#sync_master_info = 1
#sync_relay_log = 0
#sync_relay_
# InnoDB
default-
innodb-
innodb-
table-definitio
table-open-cache = 2048
transaction-
innodb-support-xa = ON
query-cache-size = 0
query-cache-type = 0
innodb-
innodb-
innodb-
innodb-
innodb-file-format = Barracuda
innodb-
innodb-
#Save and restore buffer pool to be transparent for user
#innodb_
innodb-
innodb-
#innodb-
#innodb_
#innodb_io_capacity = 200
#innodb_
innodb-
innodb-
#innodb-
innodb-open-files = 2048
key-buffer-size = 64M
flush = OFF
myisam-
myisam-
userstat = ON
loose-archive = OFF
loose-blackhole = OFF
#loose-federated = OFF
#innodb = FORCE
[mysql]
default-
auto-rehash = FALSE
local-infile = 1
max-allowed-packet = 64M
secure-auth = TRUE
[mysqldump]
max-allowed-packet = 1G
default-
[myisamchk]
key-buffer-size = 1G
sort-buffer-size = 1G
read-buffer-size = 8M
write-buffer-size = 8M
Changed in percona-xtrabackup: | |
assignee: | nobody → Muhammad Irfan (muhammad-irfan) |
Changed in percona-xtrabackup: | |
status: | New → Confirmed |
status: | Confirmed → New |
Changed in percona-xtrabackup: | |
assignee: | Muhammad Irfan (muhammad-irfan) → nobody |
I've been told that current versions of Percona XtraBackup might not be able to back up a MariaDB 10.1 server when innodb_page_size != 16K, so that might be the problem here.