Hello, At this time, I believe that this is a configuration problem with your MySQL. You have several options for correcting the problem:
1. Correct your MySQL configuration so that it can work correctly. 2. Turn off batch insert mode 3. Backup to version 1.38.11 (I don't recommend this). 4. If something else is going wrong, either fix it or provide us with some more specific information. The current information doesn't provide anything I can "fix". I've asked Eric to comment on the specific error message, but given its nature, I wouldn't expect any magic Bacula solution to be immediately available -- at this point until I hear Eric's response I'm not convinced it is a Bacula problem, particularly considering the strange problem you reported earlier. Regards, Kern On Monday 24 September 2007 15:38, Ondrej Planka wrote: > Hi Kern, > > I litle bit investigated this issue. When I configured Bacula 2.2.4 on SuSE > Linux with MySQL 5.0.45 with this option (see below), I didn't get any > error messages about "Table 'bacula.batch' doesn't exist ". > > BUT after much Backup Job(at the end of Job) (during this Backu Job no > problem, I saw transfer rate) I got this messages: > > 24-Sep 15:17 backup-dir: Backup_Client9.2007-09-24_14.05.39 Fatal error: > Can't fill File table Query failed: INSERT INTO File (FileIndex, JobId, > PathId, FilenameId, LStat, MD5) SELECT batch.FileIndex, batch.JobId, > Path.PathId, Filename.FilenameId,batch.LStat, > batch.MD5 FROM batch > JOIN Path ON (batch.Path = Path.Path) > JOIN Filename ON (batch.Name = Filename.Name) : > ERR=Lock wait timeout exceeded; try restarting transaction > > I nothing do with MySQL configuration and this configuration worked > properly with Bacula 1.38.11. > > I think, it is issue of Bacula 2.2.4. > > I use this Bacula 2.2.4 configuration: > > ./configure \ > --sbindir=/bacula/bin \ > --sysconfdir=/bacula/bin \ > --with-pid-dir=/bacula/working \ > --with-subsys-dir=/bacula/working \ > --enable-smartalloc \ > --with-mysql \ > --with-working-dir=/bacula/working \ > [EMAIL PROTECTED] \ > [EMAIL PROTECTED] \ > --with-smtp-host=localhost \ > --with-baseport=9101 \ > --with-db-name=bacula \ > --with-db-user=bacula > > > > Best Regrads, > > Ondrej Planka > > ---------- Original Message ---------------------------------- > From: Kern Sibbald <[EMAIL PROTECTED]> > Date: Mon, 24 Sep 2007 14:53:18 +0200 > > >Hello, > > > >On Monday 24 September 2007 13:57, Chris Howells wrote: > >> Kern Sibbald wrote: > >> > 4. The errors you guys are seeing is because batch insert is turned on > >> > but something went wrong in creating the batch table. I suspect that > >> > you have not setup the correct permissions on MySQL that allows the > >> > user you are running with (normally "bacula") to create tables. > >> > However, if that is the case, there *should* be an error message that > >> > is printed -- I don't imagine that error path has been tested though. > >> > Something to be investigated more. > >> > >> I had a problem with bacula backups failing with a similar error. I > >> eventually debugged it to be a problem with MySQL not allowing the > >> creation of temporary tables. So 'CREATE TABLE blah' worked, but 'CREATE > >> TEMPORARY TABLE blah' didn't. Very weird I thought! > > > >Yes, more fine grained than I would have expected. > > > >> I eventually worked out that this was because the permissions on /tmp > >> where wrong - I'd accidentally done a 'rm -rf /tmp', and then failed to > >> re-create it properly. The perms on /tmp were something like 600 and > >> owned root:root. In the default Debian/Ubuntu configurations that I have > >> seen MySQL creates its temporary tables in /tmp, but of course the mysql > >> user couldn't write to /tmp, and it therefore failed. > >> > >> Using /tmp for temporary tables can also cause problems on backups with > >> lots of files if you have quite a small / (slash partition) because / > >> fills up and the backup dies :) > >> > >> You can check/configure where temporary tables are located by looking at > >> the 'tmpdir' option in my.cnf. > > > >This pretty much confirms that most of the problems are probably due to > > MySQL (or OS) misconfiguration. I'm still concerned about the lack of > > decent error messages for the create temp table failure, which appears to > > be a Bacula problem ... > > > >Many thanks. > > > >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 ------------------------------------------------------------------------- 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
