On Wednesday 02 March 2011 18:57:37 Phil Stracchino wrote: > On 03/02/11 12:29, 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. > > dbcheck wants a single-field index on PathId over the Path table, and on > FilenameId over the Filename table. It warns that the check will take > much longer if these are not present, and offers to create them if they > are not present ... but only offers to create them temporarily, and > deletes them afterward. Refer to tools/dbcheck.c lines 857-862 and > 907-912, or the output of grep -C 5 -i -n index tools/dbcheck.c.
For what dbcheck is doing these indexes are a good idea. For normal Bacula operations, having those tables will slow down the catalog operations. > > > 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. > > I think I will do some benchmarking with/without batch insert on InnoDB, > then, and see if I can determine whether it is actually helping or > hurting performance overall if the catalog is on InnoDB. I'll be interested to see what you come up with. Don't forget to do multiple simultaneous backups where they are trying to create the same indexes. Simply removing a lock can create chaos. Generally catalog performance problems have are caused by either not adapting the conf file for the SQL engine to the size of your operation, or someone added an index that should not be there. Bacula did this in the past, so you should check that your indexes correspond *only* to what Bacula has in the latest make_mysql_tables file, as there may be some old indexes left around from older scripts. 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
