Michal Migurski wrote:
Don't take the database down for backups.
I can think of no logical reason why you'd want to kill the DB to back it up, since it's just a big "read" operation.
Referential integrity might be a reason.
Good point, though if this is a concern, the OP will probably use the built-in enforcement of referential integrity and transaction support of whatever database they are running.
I don't know what an "OP" is, though I'm not sure it's relevant to my point. What I'm saying is that I don't think it's a good idea to back up a live database, because at that point you can't enforce referential integrity any more.
If a single database is spread over files A, B, and C, then in the time it took for a naive backup to grab file A, files B and C may have changed such that the database cannot be restored to an internally-consistent state using files A, B, and C. At this point, enforcement of referential integrity would actually work against you.
MySQL provides facilities for locking tables for this purpose. Also, as others have suggested, replication is a better way to do backups than directly off of the live server.
Just my non-db-guru $0.02.
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
