On 04/05/2012 02:41 PM, Stephen Thompson wrote:
> On 04/02/2012 03:33 PM, Phil Stracchino wrote:
>> (Locking the table for batch attribute insertion actually isn't
>> necessary; MySQL can be configured to interleave auto_increment inserts.
>> However, that's the way Bacula does it.)
>
> Are you saying that if I turn on auto_increment inserts in MySQL, it
> won't matter whether or not bacula is asking for locks during batch
> inserts? Or does bacula also need to be configured (patched) not to use
> locks during batch inserts?
You would have to patch Bacula to not issue an explicit LOCK TABLE. It
does not at present contain any option to not lock the table during
inserts. This is something I've meant to experiment with myself for
some time, to compare performance, but haven't managed to get to it. It
hasn't been a high priority for me since I don't ever have more than
about five or six jobs running, and they basically never finish up at
the same time anyway.
> And lastly, why does the bacula documentation claim that locks are
> 'essential' for batch inserts and you claim they are not?
Basically, if interleaved mode is NOT enabled, multiple batch inserts
will contend for access to the table, since even if Bacula does not lock
the table, InnoDB will set a global AUTO_INC lock on the table any time
you attempt to insert an indeterminate number of rows into a table
containing an auto_increment field.
(In this context, actually, on InnoDB, having Bacula issue a LOCK TABLE
is redundant; InnoDB is going to lock the table anyway until the thread
is done inserting rows.)
Setting innodb_autoinc_lock_mode = 2 enables multiple threads to
interleave inserts into the same table and guarantees that they will
still get unique auto_increment row IDs; it simply does not guarantee
that the IDs allocated to any given thread will be consecutive.
However, I'm pretty sure Bacula is not written sufficiently incorrectly
to care whether it gets consecutive row IDs. :)
--
Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355
alaric AT caerllewys DOT net alaric AT metrocast DOT net phil AT
co.ordinate DOT org
Renaissance Man, Unix ronin, Perl hacker, SQL wrangler, Free Stater
It's not the years, it's the mileage.
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
