> > The advantage of other methods is that you avoid all sorts of nasty > > locking on various parts of your database. The advantage of > the Hot Copy > > product that Innobase Oy sell is that it doesn't place any > locks on your > > InnoDB table space when it runs. > > Wouldn't that break the ACID ? The backup data would not be > fully consistent, > integrated anymore. Anyway thats my understanding. > > I understand that the InnoDB Hot Copy product is providing > this feature by > using the actual row locks to make sure that ACID is taken > care of while > creating a consistent backup.
The algorithm as I understand it is something like this: 1) Tell InnoDB engine to flush the transaction journal to the data pool. 1) Tell InnoDB engine to NOT flush the transaction journal to data pool until further notice. 2) Make a flat copy of the data pool (analogous to just cp'ing the files). 3) Make a copy of pending transactions in the transaction journal. 4) Tell InnoDB engine to resume normal behavior. Transactions can still continue to write to the DB because everything goes through the transaction journal anyway. The journal simply stores a list of changed DB pages associated with a particular transaction, and is flushed to the data pool asynchronously. The data pool always represents a consistent-state snapshot of the DB thanks to the double-write buffer. The only risk is that the backup procedure may take such a long time that the transaction journal becomes full. I don't know how InnoDB handles this -- I suspect transactions simply start failing at that point although I suppose it's possible that they simply block until space becomes available. You can avoid this by ensuring that your transaction journals are sufficiently large to accommodate the copy process in the face of the heaviest possible DB write load. Estimating with any precision is difficult but it's usually fairly straightforward to come up with a "definitely safe" guess. (Our production DB runs 3 transaction journals of 20MB each for example -- plenty of space for us, even assuming very substantial growth in write traffic) -JF -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
