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
