Greetings! I'm upgrading for Bacula 2.x to 5.2.1, and I've wanted to start using Base Jobs, since I'm backing up to disk now.
Previously, I'd had the exact same problem here with doing a Full on a previously made Base job: http://www.mail-archive.com/bacula-devel@lists.sourceforge.net/msg06023.html I wanted to mention that the (fixed) first patch posted by Eric Bollengier fixed the problem, as shown here: http://www.mail-archive.com/bacula-devel@lists.sourceforge.net/msg06054.html I'm using Bacula 5.2.1, on Scientific Linux 6, 64 bit. The MySQL version (from the RPM) is 5.1.52. This is a database that's extremely large (70+GB), and has been updated using the supplied scripts from the 2.0 version up to current, and has over 7 years of use in it. Now, an incremental had started as scheduled, based off the previous Base/Full I spoke about before. MySQL is hanging again. I can't tell the job status, because it's locked the DB to a point bconsole can't query what it needs. Here's what MySQL shows: | 3 | bacula | localhost | bacula | Query | 16780 | Copying to tmp table | SELECT Path.Path, Filename.Name, T1.FileIndex, T1.JobId, LStat, DeltaSeq FROM ( SELECT FileId, Job.JobId AS JobId, FileIndex, File.PathId AS PathId, File.FilenameId AS FilenameId, LStat , DeltaSeq, Job.JobTDate AS JobTDate FROM Job, File, ( SELECT MAX(JobTDate) AS JobTDate, PathId, FilenameId FROM ( SELECT JobTDate, PathId, FilenameId FROM File JOIN Job USING (JobId) WHERE File.JobId IN (112775) UNION ALL SELECT JobTDate, PathId, FilenameId FROM BaseFiles JOIN File USING (FileId) JOIN Job ON (BaseJobId = Job.JobId) WHERE BaseFiles.JobId IN (112775) ) AS tmp GROUP BY PathId, FilenameId ) AS T1 WHERE (Job.JobId IN ( SELECT DISTINCT BaseJobId FROM BaseFiles WHERE JobId IN (112775)) OR Job.JobId IN (112775)) AND T1.JobTDate = Job.JobTDate AND Job.JobId = File.JobId AND T1.PathId = File.PathId AND T1.FilenameId = File.FilenameId ) AS T1 JOIN Filename ON (Filename.FilenameId = T1.FilenameId) JOIN Path ON (Path.PathId = T1.PathId) WHERE FileIndex > 0 ORDER BY T1.JobTDate, FileIndex ASC | I'm hoping Eric or someone as another little brilliant snippet of SQL that can solve this issue as well. As far as I can tell, MySQL created the temporary table for the job within the minute the job started, and then hung, essentially the same behavior as shown in the old thread from 2010 with the Base/Full issue. Thanks! Mark Bober ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
