On Wed, 2011-03-02 at 18:29 +0100, Kern Sibbald wrote: > On Tuesday 01 March 2011 14:58:04 Phil Stracchino wrote: > > I was looking into what Bacula was doing in the DB this morning, with a > > MySQL catalog, to see why last night's backup jobs stalled. As a result > > of my investigations, I have two questions: > > > > 1. > > If dbcheck finds that either of the two indices it needs are missing, > > why does it only offer to create temporary indices, instead of offering > > to create the indices once and have done with it? Perhaps this could be > > a command-line option to dbcheck, 'Create any required indices if not > > found'. > > As far as I know dbcheck does not need indexes and does not create any. > Perhaps if you explained the context better I could understand.
In the dbcheck script it has the option of creating the indexes. The indexes are very useful in having the dbcheck run and finish. With the indexes my DB check will run in most of a day with the adition and dropping of the indexes factored in. The day to day Mysql performance for normal Bacula operation is not palatable with the indexes setup on the tables. (IE mysql is so slow it's not usable with bacula IMO). > > > > > 2. > > Why in the name of little green fishes does Bacula issue explicit table > > locks? This might have once been a good idea when MySQL implied MyISAM, > > byt MyISAM has been increasingly (if unofficially) deprecated for years. > > The general wisdom in MySQL circles is that the answer to "My usage > > case is foo, what storage engine should I use?" is "InnoDB" for > > essentially all possible values of 'foo', and issuing a 'LOCK TABLE' on > > InnoDB is almost without exception a bad idea. Bacula should at least > > check what the storage engine is before issuing any table locks. (This > > can be checked very quickly on a table-by-table basis by parsing 'SHOW > > CREATE TABLE `tablename`'.) I would guess that if there is not a strong > > rationale for doing this other than "It was needed on MyISAM", it is > > probably badly hurting Bacula catalog throughput on InnoDB. > > To the best of my knowledge, Bacula only locks tables during batch insert, > and > this is essential. If you want to know how batch insert works (very clever > and a bit complicated), you can read > docs/techlogs/batch_insert_documentation.odt. > > Regards, > > Kern > > > > ------------------------------------------------------------------------------ > Free Software Download: Index, Search & Analyze Logs and other IT data in > Real-Time with Splunk. Collect, index and harness all the fast moving IT data > generated by your applications, servers and devices whether physical, virtual > or in the cloud. Deliver compliance at lower cost and gain new business > insights. http://p.sf.net/sfu/splunk-dev2dev > _______________________________________________ > Bacula-devel mailing list > Bacula-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-devel -- ---------------------------------------------------------------------------- Jason A. Kates (ja...@kates.org) Fax: 208-975-1514 Phone: 660-960-0070 ============================================================================ ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
