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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
