On Sunday 06 January 2008 20:10, Eric Bollengier wrote: > Hi, > > On Sunday 06 January 2008 18:33:58 Kern Sibbald wrote: > > On Sunday 06 January 2008 13:31, Michel Meyers wrote: > > > Hello, > > > > > > I just had a job bail out with this message: > > > > > > 06-Jan 13:09 server-dir JobId 84: Fatal error: sql_create.c:732 > > > sql_create.c:732 insert INSERT INTO batch VALUES > > > (578407,84,'/path/','filename','P4A ORB4 IGk B h h A Byp BAA Q BHf8G2 > > > BHQexl BHfb1A A A E','oJKoU70RjrXaw > > > UdZeOLFQ') failed: > > > Table 'bacula.batch' doesn't exist > > > > > > A short investigation shows that this happens due to the MySQL > > > connection timing out and the table subsequently getting dropped. > > > > > > My question is: Wouldn't it be better to create a permanent table and > > > just drop it when done? If multiple of these are needed concurrently, > > > they could be created with a unique name, like bacula.batch-$jobid and > > > then maybe add some cleanup code that purges any bacula.batch* tables > > > upon director startup. > > > > > > This would make Bacula resilient to MySQL timeouts and avoid forcing > > > users to change their global MySQL config. (e.g. I don't mind granting > > > the Bacula user rights to create tables, I DO mind changing the MySQL > > > timeout for everybody.) > > > > I don't consider the above to be a Bacula bug, but rather a MySQL bug or > > a configuration problem. Bacula assumes that none of the connections to > > database will timeout regardless of the idle time, and if they timeout, > > Bacula will most likely fail. > > > > I'm not convinced that using a non-temporary table would help since if > > the connection is dropped, on the next access, it will likely break, > > unless the client libraries automatically reconnect. Yes, the name must > > be unique because there can be one table open for each job. > > > > I'm not sure why Eric suggested opening a bug, perhaps because we could > > pragmatically set the timeout very large. > > I want to keep a trace of this problem somewhere, this is a very frequent > problem on user list. If we could find a solution, it will be great. > > I think that we can set timeout values to 0 (or something like 8 days), and > this problem will disappear.
Yes, I agree, if it is simply a programming issue to set the timeout values, we should do it, and I think you are right that it is a good idea to track this problem. Kern > > Bye > > > Another alternative is to turn off batch inserts, or possibly to switch > > to PostgreSQL where there have never been any silly default timeouts that > > I am aware of. > > > > Regards, > > > > Kern ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
