Simon Ekstrand wrote: > 2009/4/23 Ulrich Leodolter <ulrich.leodol...@obvsg.at>: >> Hi, >> >> On Thu, 2009-04-23 at 09:54 +0200, Simon Ekstrand wrote: >>> Hi, >>> >>> I thought I'd just put in a note that we have just done a successful >>> upgrade to bacula 3.0 for a bacula system running 7 storage daemons >>> with a total of ~70 TB data (all disk based, no tapes). Everything is >>> running smoothly so far. >>> The catalog in use is a mysql db totaling approximatly 110 GB. We did >> Our catalog is about 18G, nice to hear that it works > 100GB. >> Are u running catalog backups? how long runs mysqldump bacula? >> Would be nice if you can share your hardware config >> (machines, cpu, mem, disk) > > The catalog server currently runs dual quad core 3ghz intel xeons, 8gb > ram, 15krmp sas disks etc. > We don't currently do any mysqldumps of the catalog db due to the > horrible amounts of time required for a mysqldump of a db of this > size. As a half-measure we instead do replication of the db to a > second server so that we have a copy of the data in case of a hardware > crash. > > I'd say that the catalog is probably our biggest problem with bacula > currently. We backup a quite a few servers, many of them containing > millions of files, so our catalog is large and constantly growing. > Doing restores of jobs with > 1,000,000 files with a catalog of this > size can be frustrating at times (building the filelist specifically). > Also, the catalog inserts when jobs with > ~5,000,000 files complete > can be very long - literally hours in bad cases. This is iffy for a > couple of reasons, one is that no other jobs can complete during that > time as the catalog db tables are locked, and also that the waiting > jobs will fail without a sufficiently high innodb_lock_wait_timeout > set in mysql. Ours is currently set to 2 hours which seems to cover > our cases fairly well.
Ever thought of using multiple catalogs, eg one catalog for each client or client group? This should mitigate most of the catalog issues you have. Attila > That said, it's certainly workable, the db pain is generally not to > bad. I've been considering trying out postgres for the catalog to see > how it handles our current load, but that's a bit of a project in > itself. > ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
