On Thu, Jan 17, 2013 at 08:20:48AM -0500, Phil Stracchino wrote:
> One last footnote:  *SOLELY* setting MySQL read-only does NOT guarantee
> a consistent backup.  You must FLUSH TABLES, and even then you're still
> not 100% safe on InnoDB.
> 

Agreed, I forgot that important step in my previous email. Our method
right now involves flushing the tables, setting the read lock,
rsyncing the data files to a separate directory, then enabling write
access to the db while tarring / lzop'ing the new directory in the
background. 

Naturally we only do this when there are no backup jobs running which
is easy to determine using a "stat dir" echo'ed to bconsole before the
database backup starts. 

Could we expect to see better db performance by moving to innodb or
one of MariaDB's fancy new backends? I'm especially interested in
improving volume recycle times which can be quite long with our setup
(200GB file table). the DELETE from File where JobId in (.....) can
take a few hours sometimes.  

Cheers, Uwe 



-- 
NIONEX --- Ein Unternehmen der Bertelsmann SE & Co. KGaA



------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users