Proper way to backup and restore?

[seqizz]

Hi,

I’m struggling with xtrabackup for a while. There are some Innodb corrupt warnings while or after restore on different server. It’s going pretty unstable. There is no corruption on production database of course. Example after-restore error:

140721 10:29:39 InnoDB: Error: page 2504 log sequence number 97651749064
InnoDB: is in the future! Current system log sequence number 54429130252.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: for more information.

Here are the versions and options I use to backup and restore, I’d be grateful if someone check and recommend something:

Prod server (backup via):
percona-xtradb-cluster-server-5.5 version 5.5.34-25.9-607.precise
percona-xtrabackup version 2.1.6-702-1.precise

Restored on:
percona-server-server-5.5 version 5.5.37-rel35.0-657.wheezy
percona-xtrabackup-21 version 2.1.9-746-1.wheezy

Backup command (innobackupex):
–galera-info --rsync
–galera-info --rsync --incremental

Restore command (innobackupex):
–apply-log --use-memory=2G --ibbackup=xtrabackup_51

Thanks.

[alaincraven]

I have had this before with very busy servers using mysqlhotcopy. Never had it with inno/xtra backup.
Is your server under heavy load when backing up?
Also - what is the size of the log file?

[dcg9381]

Same issue… anyone get this sorted?

[mirfan]

Can you please share full error log along with my.cnf configuration file to check further. From quick look, It seems those LSN errors will eventually fix once current log sequence number catches up with future log sequence number High amount of fake DML queries can speed up this operation to fix. On safe side, you can check database consistency via mysqlcheck --all-databases or mysqldump to verify that all database tables are in good shape.