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 AT lists.sourceforge DOT
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 AT lists.sourceforge DOT
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 AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
