On Tuesday 06 September 2005 17:26, Philipp Steinkrueger wrote: > Hi, > > Kern wrote: > > Hmmm. It looks like MySQL may have changed the behavior of their > > dump/restore, > > > which used to delete everything before doing a restore. If you did not > > explicitly delete your database before doing the restore, you probably > > unknowingly duplicated all the records -- not very good. > > afaik it was never a default to drop the database automatically before > inserting a dump,
Perhaps it didn't drop the database but it did drop each table -- otherwise, how can the example from the Catalog Maintenance chapter of the manual work? mysqldump -f --opt bacula > bacula.sql mysql bacula < bacula.sql rm -f bacula.sql I'm sure that worked because I tried it before writing the chapter. If it doesn't drop the tables, then it must be very cleaver about the inserts. > but > anyway i dont think that this really happend, because he writes that > bacula is complaining about > duplicate entries which means that bacula wants to insert something and > that would be a duplicate. Yes, I cannot argue this point as I am not really sure what is going on because Christian did not show the actual error message. Bacula does not care if there are duplicate entries in the File table, as far as I remember, and when it does insert an entry in that table, the FileId of NULL is used. > if he had duplicated the content of the database when i inserted the > dump again, then mysql would > have complained during the restore of the dump. this happend to me for > dozens of time, i am sure > and thats why i am pretty sure that automatic dropping of database was > never a default. > > what might have happend is the following: when you reload the database > by dumping it and > restoring it, autoincrement values may have been renumberd. usually the > autoincrement column > is defined as a key and due to this would not be allowed to be not unique. Can you explain this or give an example? I don't see your point but would like to understand it, because a dump followed by a single restore should never create a condition that would cause Bacula to fail, otherwise there is a *big* problem. Best regards, Kern ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
