1

As a follow up to this question: Is copying /var/lib/mysql a good alterntive to mysqldump?

If I don't stop the database server, and my tables are inconsistent, can MySQL still recover from this (by removing the inconsistent rows)? Or is the backup entirely useless?

I've been doing my backups by backing up /var/lib/mysql for a long time... but I've never had to use them. It'd be terrible to find out I couldn't if I had to (after the fact, that is).

Community
  • 1
  • 1
jaynp
  • 3,275
  • 4
  • 30
  • 43

1 Answers1

1

A consistent snapshot (all of the data from the same instant in time) is fine - this is (hopefully) what happens in a crash and MySQL (specifically InnoDB) is engineered to recover from this, although it may take a while to start up as it does crash recovery. For MyISAM tables - well you are on your own.

The problem is that it takes a while to copy a file and the files may be changing as you are copying them, so your backup file may be an inconsistent snapshot. The start of the file containing older data than the end! Additionally all the files need to be in sync w.r.t each other. MySQL will try but there is no guarantee that it will recover from this condition.

So you can use something like LVM snapshots to get a consistent snapshot in time or use mysqldump with --single-transaction, or make the tables read-only while you are backing them up.

abasterfield
  • 2,214
  • 12
  • 17
  • Maybe my question isn't clear. I know inconsistent snapshots are bad, but can MySQL get back up and running using an inconsistent snapshot (by any crash recovery mechanism) using what's found in `/var/lib/mysql`? – jaynp Dec 12 '13 at 18:39
  • No. Dirty shutdown yes, inconsistent snapshot no. You cannot rely on your backups using plain file copy. – abasterfield Dec 12 '13 at 18:40