Hello, Am 07.09.2005 schrieb Philipp Steinkrueger: > Hi Kern, > > > >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 > > > > > > > because of the --opt parameter in the mysqldump command which adds > drop-commands into bacula.sql which > are performed when you reinsert bacula.sql and so the tables are droped... > > >>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. > > > > > > > allright. first, this is based on speculation, because i dont have > enough time to read the bacula code. you > have to confirm or deny if the following is possible with bacula. > lets assume we have two tables. the first tables consists of two > columns, one of them is an autoincrement > column. the table would look like this after sometime: > > 324 fsdfd > 325 fsasr4g > 326 24325 > > now the other tables consists of two columns too, but there are no > autoincrement columns. the content > could look like this: > > 324 file1 > 325 file2 > 326 file3 > > if there is some relationship between the tables, lets say that the > second tables content is created based on the values > of the first tables content, then something could happend resulting in > affects described by christian. > if you dump the database and reload it into the server, there are > chances that the autoincrement values are > renumberd. i cant find a reference for that at mysql.com at the moment, > but i am pretty sure i've read > something like this and the problem is de facto discussed in severel > forums. i could not reproduce this > with my mysql 4.1 server, but perhaps its an mysql 3.2 issue, dont know. > > anyway, if the autoincrement value is renumberd and bacula is performing > some action which > creates the content of table two, it looks into table one for "fsdfd" > and picks up the > value, which used to be 324 but is 1 after the dump-reload-procedure. > now its going to insert this into the second table, but > there is allready a row with id 1, and so it will complain about > duplicate rows. > perhaps the unproofed assumption of renumberd autoincrement values is > not even needed. if you dump and restore > without dropping first, you could mess up the content, too, producing > relation-problems like this...
Very nice explanation - but you're wrong. I just made a "mysqldump bacula File -p > bacula-file.sql". when you check "describe File", you'll see that "FileId" is "auto_increment". When you check the dump, that column "FileId" is also set. "auto_increment" is only used, if you INSERT a dataset WITHOUT any value for the column "FileId". But you can set a value on your own explicitely. > with this argumentation one could perhaps even try to explain why > christians problem did not rise immediatly, but after two days. Greets, Thomas ------------------------------------------------------- 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
