Hi there,
after disabling the accurate mode for a few days and re-enabling it,
things are working well again.
Maybe restarting the bareos machine also helped.
So for me the problem is solved.
Greets
Stephan
Am 27.02.2018 22:55 schrieb Stephan Hermann:
Hi again,
What can I do to
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
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
Hi,
I encountered the same problem on CentOS 7 using MySQL 5.7. Unfortunately the
missing Index did not really improve the situation - neither did the
OPTIMIZE/ANALYZE commands.
The only solution was to downgrade MySQL to 5.5 then everything was running
smoothly like usual and the accurate
Hi Artur,
> After analyzing database queries I noticed that an additional index would be
> useful in the Job table. So I added a new index for column JobTDat in Job
> table
>
> create index ON Job (JobTDate);
>
> as for me, this solution solved the problem.
I tried this as well and it solved
Hi,
After analyzing database queries I noticed that an additional index would be
useful in the Job table. So I added a new index for column JobTDat in Job table
create index ON Job (JobTDate);
as for me, this solution solved the problem.
regards,
Artur
--
You received this message because
> If that does not help, disabling accurate for that job meanwhile may be
> better
> than killing the query.
...and just a quick followup-question: If I disable accurate backup for the
time being - can I reenable it later without complications?
Kind regards
Markus
--
You received this
Hi,
I'm suffering from exactly the same problem: After updating from 16.2 to 17.4.2
the step "Sending Accurate information" takes now hours instead seconds with
16.2, also "Sending spooled attrs to the Director." The Query in question is as
posted from jsfrerot.
My System ist Ubuntu 16.04
Le mardi 23 janvier 2018 16:26:47 UTC-5, Stephan Duehr a écrit :
> 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
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
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,
11 matches
Mail list logo
