6th page isn't initialized

[andreiip]

Hello everybody.

mysql Ver 14.14 Distrib 5.6.28-76.1, for debian-linux-gnu (x86_64) using 6.2
xtrabackup version 2.4.6 based on MySQL server 5.7.13 Linux (x86_64) (revision id: 8ec05b7)

I try prepare percona backup and received:
xtrabackupreparepare --target-dir=/backups/mysqlbackups
........................................................................
InnoDB: End of page dump

                            InnoDB: Uncompressed page, stored checksum in field1 300180583, calculated checksums for field1: crc32 2232620153/2147590501, innodb 300180583, none 3735928559, stored checksum in field2 1565447105, calculated checksums for field2: crc32 2232620153/2147590501, innodb 1565447105, none 3735928559, page LSN 1715 4265470450, low 4 bytes of LSN at page end 4265470450, page number (if stored to page already) 6, space id (if created with >= MySQL-4.1.1 and stored already) 0
                  InnoDB: Page may be a freshly allocated page
     [FATAL] InnoDB: Apparent corruption of an index page [page id: space=0, page number=6] to be written to data file. We intentionally crash the server to prevent corrupt data from ending up in data files.
                          2017-03-10 14:30:51 0x7f66a5309720 InnoDB: Assertion failure in thread 140078834816800 in file ut0ut.cc line 916
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.7/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
            06:30:51 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...

[Shahriyar Rzayev (rzayev-sehriyar)]

Hi,
So you took backup with PXB 2.4.6 and for 5.6.28-76.1 server version.
Could you please share my.cnf (mysql config file) and backup-my.cnf(from backup folder) files?

[andreiip (andriip)]

Hi
My config:
........................................................
my.cnf

[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock

[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0

[mysqld]
bind-address = ::
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /sql/data
language = /usr/share/mysql/english

skip-external-locking
default_storage_engine = InnoDB
key_buffer = 16M
max_allowed_packet = 128M
thread_stack = 192K
myisam-recover = BACKUP
thread_cache_size = 256
max_connections = 1000
max_connect_errors = 1000000
open_files_limit = 65535
table_definition_cache = 1024
table_open_cache = 1000
join_buffer_size = 5M

query_cache_limit = 64M
query_cache_size = 2048M
innodb_buffer_pool_size = 24000M
tmp_table_size = 128M
max_heap_table_size = 128M

ssl-cert = /etc/mysql/ssl/wildcard.syrahost.com.crt
ssl-key = /etc/mysql/ssl/wildcard.syrahost.com.key

long_query_time = 10

innodb_file_per_table
innodb_flush_method = O_DIRECT
innodb_flush_log_at_trx_commit = 2
innodb_log_buffer_size = 16M
innodb_file_format = barracuda
innodb_thread_concurrency = 24
innodb_log_file_size = 2G

# Replication global settings
log_bin = /sql/binlogs/mysql-bin.log
tmpdir = /sql/tmp
relay-log = /sql/data/slave-relay.log
relay-log-index = /sql/data/slave-relay-log.index
max_binlog_size = 100M
expire_logs_days = 7
sync_binlog=1
log-slave-updates
binlog_format=mixed
sql_mode = NO_ENGINE_SUBSTITUTION

slave_compressed_protocol=1
slave-net-timeout = 30
master-retry-count = 86400

# Replication per server settings
server-id=1
auto_increment_offset=1
auto_increment_increment=2

[mysqldump]
quick
quote-names
max_allowed_packet = 16M

[isamchk]
key_buffer = 16M

======================================================================
backup-my.cnf
# This MySQL options file was generated by innobackupex.

# The MySQL server
[mysqld]
innodb_checksum_algorithm=innodb
innodb_log_checksum_algorithm=innodb
innodb_data_file_path=ibdata1:12M:autoextend
innodb_log_files_in_group=2
innodb_log_file_size=2147483648
innodb_fast_checksum=false
innodb_page_size=16384
innodb_log_block_size=512
innodb_undo_directory=.
innodb_undo_tablespaces=0
server_id=1

redo_log_version=0
.................................................

[Shahriyar Rzayev (rzayev-sehriyar)]

Did you upgrade your MySQL from previous versions recently?
I mean, from what time(what situation) you have encountered this issue?

[andreiip (andriip)]

No, we did not update MySQL (Percona is glad to announce the release of Percona Server 5.6.28-76.1 on January 12th, 2016 (Downloads are available here and from the Percona Software Repositories).).
I try configure xtrabackup.

When I make xtrabackup in the slave server sometimes works and sometimes doesn't works.

When I make prepare in the slave server sometimes works and sometimes doesn't works. In master server doesn't works.

[andreiip (andriip)]

When I installed to xtrabackup version 2.2.13. The prepare works

[Sergei Glushchenko (sergei.glushchenko)]

fixed by PR https://github.com/percona/percona-xtrabackup/pull/379

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXB-500