Hello Phil, Le mardi 01 mars 2011 14:58:04, Phil Stracchino a écrit : > 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?
Because these indexes slow down files and attributes insertion, and speed up dbcheck. So, as you insert files more often than you run dbcheck, we decided to create/delete these indexes on the fly. But, feel free to add them permanently. > Perhaps this could be > a command-line option to dbcheck, 'Create any required indices if not > found'. > > 2. > Why in the name of little green fishes does Bacula issue explicit table > locks? You can look the docs/techlogs/batch_insert_documentation.odt file that explains the batch insertion process. These locks are used to ensure that two jobs won't insert two records for the same filename/path. You have to know that until mysql 5.1.21 and with a special configuration option that breaks the replication (if used), you can't run two batch insertion process at the same time on innodb. see http://sf.net/apps/wordpress/bacula/2009/11/12/handle-multiple-jobs-in- parallel-with-innodb/ > 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. Can you explain why in our situation (lock on path and filename during massive insertion), this is bad to lock the table to ensure that we won't have duplicate rows? Have you an other way to ensure that? (maybe it's built-in). Would this change improve the performance significantly? Bye > 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. -- Need professional help and support for Bacula ? Visit http://www.baculasystems.com ------------------------------------------------------------------------------ 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
