Hi again, > What can I do to analyze/fix this?
would it be possible/reasonable to clean up all the "accurate mode" information and start from zero? If yes, how can I do this? Unfortunately I'm not that much experienced with mySQL databases... Thanks for your support and many greets Stephan Am 25.02.2018 um 00:49 schrieb Stephan Hermann: > Hi, > > it seems that I run into this issue, too. > I just upgraded from 16.2.7 to 17.2.5 (from subscription repo) and > updated the database scheme from 2004 to 2171. > > Since then incremental backups with a lot of files hang at 'Sending > Accurate information.' There is one mysql process at 100% cpu, but I > can't see any relevant disk activity (iotop -o). > > Killing the queries inside mySQL allow me to continue the jobs, but the > result looks like a full job, not an incremental. > > Some outputs: > > mysql> analyze table File; > +-------------+---------+----------+----------+ > | Table | Op | Msg_type | Msg_text | > +-------------+---------+----------+----------+ > | bareos.File | analyze | status | OK | > +-------------+---------+----------+----------+ > 1 row in set (0.04 sec) > > mysql> optimize table File; > +-------------+----------+----------+-------------------------------------------------------------------+ > | Table | Op | Msg_type | Msg_text > | > +-------------+----------+----------+-------------------------------------------------------------------+ > | bareos.File | optimize | note | Table does not support optimize, > doing recreate + analyze instead | > | bareos.File | optimize | status | OK > | > +-------------+----------+----------+-------------------------------------------------------------------+ > 2 rows in set (4 min 35.79 sec) > > What can I do to analyze/fix this? > > Thanks a lot and many greets > Stephan > > > Am 23.01.2018 um 22:26 schrieb Stephan Duehr: >> Hi, >> >> that looks like the query being run for accurate backup. >> I wonder why it's slower after the upgrade, as it's one table less for the >> join. >> This kind of problem with accurate has also been seen with the Bareos 16.2 >> DB schema >> in MySQL. >> >> Please check if the indexes on the File table match the ones defined in >> /usr/lib/bareos/scripts/ddl/creates/mysql.sql >> >> May be do >> ANALYZE TABLE File; >> in mysql again. >> >> If that does not help, disabling accurate for that job meanwhile may be >> better >> than killing the query. >> >> Regards, >> >> Stephan >> >> On 01/22/2018 02:30 PM, [email protected] wrote: >>> Hi, After the upgrade to 17.2.4 (21 Sep 2017) I noticed the following sql >>> query: >>> >>> SELECT Path.Path, T1.Name, T1.FileIndex, T1.JobId, LStat, DeltaSeq , >>> Fhinfo, Fhnode FROM ( SELECT FileId, Job.JobId AS JobId, FileIndex, >>> File.PathId AS PathId, File.Name AS Name, LStat , DeltaSeq, Fhinfo, Fhnode, >>> Job.JobTDate AS JobTDate FROM Job, File, (SELECT MAX(JobTDate) AS JobTDate, >>> PathId, FileName FROM (SELECT JobTDate, PathId, File.Name AS FileName FROM >>> File JOIN Job USING (JobId) WHERE File.JobId IN >>> (2897,2941,2963,3005,3023,3041) UNION ALL SELECT JobTDate, PathId, >>> File.Name AS FileName FROM BaseFiles JOIN File USING (FileId) JOIN Job ON >>> (BaseJobId = Job.JobId) WHERE BaseFiles.JobId IN >>> (2897,2941,2963,3005,3023,3041) ) AS tmp GROUP BY PathId, FileName) AS T1 >>> WHERE (Job.JobId IN (SELECT DISTINCT BaseJobId FROM BaseFiles WHERE JobId >>> IN (2897,2941,2963,3005,3023,3041)) OR Job.JobId IN >>> (2897,2941,2963,3005,3023,3041)) AND T1.JobTDate = Job.JobTDate AND >>> Job.JobId = File.JobId AND T1.PathId = File.PathId AND T1.FileName = >>> File.Name ) AS T1 JOIN Path ON (Path.PathId = T1.PathId) WHERE FileIndex > >>> 0 ORDER BY T1.JobTDate, FileIndex ASC >>> >>> This query is taking a very long time to complete. Now it's been running >>> over 13 hours and it is still running and taking 100% CPU. >>> >>> I'm using mysql 5.5, and the schema was upgraded when upgrading from 16.2 >>> to 17.2. >>> >>> For the last few days I had to kill the queries, but it would be great to >>> have this fixed. >>> >>> Any idea what is wrong here ? >>> >>> Thank you. >>> >> > -- You received this message because you are subscribed to the Google Groups "bareos-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
