Hello,
Le vendredi 23 avril 2010 10:00:39, Graham Keeling a écrit :
> On Thu, Apr 22, 2010 at 06:47:34PM +0200, Eric Bollengier wrote:
> > Hello Graham,
> >
> > Le jeudi 22 avril 2010 17:47:35, Graham Keeling a écrit :
> > > Hello,
> > >
> > > I am not sure whether this is a bug or a feature request. I will
> > > happily fill in the form for either, once somebody advises...
> > >
> > > The command that I run most often on bconsole is 'status director'.
> > >
> > > Unfortunately, bconsole often pauses for long periods of time during a
> > > 'status director' request. For example, whilst the query that bug 1472
> > > talks about is running (generating accurate data). In that case,
> > > 'status director' is blocked regularly for more than five minutes. The
> > > situation is worse if there are multiple backups, each queuing up to
> > > make their query.
> > > This is particularly bad from the perspective of people who want to use
> > > bconsole as the engine behind a graphical interface.
> > > The user cannot get any idea of what is going on, and it seems as if
> > > bacula is 'stuck' indefinitely.
> > >
> > > It would be very good if 'status director' could be tweaked so that it
> > > does not get blocked.
> > > It seems to be the 'list_scheduled_jobs()' function that waits for a
> > > lock (LockRes()).
> > > In the worse case, it could at least quickly return a message that
> > > states that the resource is busy. But I think that it should be
> > > possible to do better than that.
> >
> > The actual master code uses a dedicated sql connection for the
> > VirtualFull query, it should no longer block. For normal Accurate
> > backup, it uses dedicated connection since the beginning, so it's
> > shouldn't block commands too.
>
> Hello,
>
> Do you mean that this has been addressed in the latest development code?
For the VirtualFull, yes.
> > We planed to use a dedicated connection for command like "status dir",
> > some users are also using the multidb catalog option that permits to use
> > dedicated connection for each threads. (we don't test it through
> > regression tests, so I cannot guarantee that it works all the time, but
> > it's a workaround).
>
> Is there documentation for this workaround somewhere?
The documentation is present in the manual but only as comment. This is an
experimental feature (for 5 or 6 years now...) And we don't support this
configuration, some operations can have problem. Bacula is designed to
serialize sql queries, but if you want to test it and give us feedbacks or
find/fix bugs (like you do very well). It could be a nice improvement.
This is the content of the source documentation file about this feature. (It
needs to be updated too)
\item [Multiple Connections = \lt{}yes\vb{}no\gt{}]
\index[dir]{Multiple Connections}
\index[dir]{Directive!Multiple Connections}
By default, this directive is set to no. In that case, each job that uses
the same Catalog will use a single connection to the catalog. It will be
shared,
and Bacula will allow only one Job at a time to communicate. If you set this
directive to yes, Bacula will permit multiple connections to the database,
and the database must be multi-thread capable. For SQLite and PostgreSQL,
this is no problem. For MySQL, you must be *very* careful to have the
multi-thread version of the client library loaded on your system. When this
directive is set yes, each Job will have a separate connection to the
database, and the database will control the interaction between the
different
Jobs. This can significantly speed up the database operations if you are
running multiple simultaneous jobs. In addition, for SQLite and PostgreSQL,
Bacula will automatically enable transactions. This can significantly speed
up insertion of attributes in the database either for a single Job or
multiple simultaneous Jobs.
This directive has not been tested. Please test carefully before running it
in production and report back your results.
------------------------------------------------------------------------------
_______________________________________________
Bacula-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-devel
