Another perspective...
I've personally found that if your memory is limited (my bacula db server has 8Gb of RAM) that, for a bacula database, mysql performs _better_ than postgres. My File table currently has 2,856,394,323 rows. I've seen so many recommendations here and elsewhere about postgres being an obvious choice over mysql, but in real life practice, we've found at our site that mysql gave us better results (even after weeks of tuning postgres). Our hybrid solution is to run mysql INNODB as the active database so to avoid table-locking which causes all kinds of problems, especially operator access to bconsole. However, due to the painfully slow dumps from INNODB, we have a slave mysql server running MYISAM that we use for regular ole mysql dumps. In general this works out fairly well for us. The only unresolved issue that we have is that some of the bacula queries can take awhile to return. I've tracked it down the way the db engine is responding to the query, but the odd thing is that the first time these queries run, they are quick, then the mysql engine changes the recipe it uses to a slower one. Haven't figured out why or how to keep it running the quick way. Stephen On 03/01/2013 03:16 AM, Uwe Schuerkamp wrote: > On Tue, Feb 26, 2013 at 04:23:20PM +0000, Alan Brown wrote: >> On 26/02/13 09:42, Uwe Schuerkamp wrote: >> >> >>> for the record I'd like to give you some stats from our recent myisam >>> -> innodb conversion. >> >> >> For the sizes you're talking about, I'd recommend: >> >> 1: A _lot_ more memory. 100Gb or so. >> >> and even more strongly: >> >> 2: Postgresql >> >> >> Mysql is fast and good for small databases, but postgresql scales to >> large sizes with a lot less pain and suffering. Conversion here was >> relatively painless. >> >> > > Hi Alan & list, > > can you point me to some good conversion guides and esp. utlities? I > checked the postgres documentation wiki, but half of the scripts > linked there are dead it seems. I tried converting a mysql dump to pg > using my2pg.pl, but the poor script ran out of memory 30 minutes into > the conversion on the test machine (Centos 6, 8GB RAM ;-) > > I'm hoping our File table will get a lot smaller now over time as > we've moved away from copy jobs for the time being, so the conversion > should also get easier as tape volumes with millions of files on them > get recycled and pruned. > > All the best, Uwe > -- Stephen Thompson Berkeley Seismological Laboratory step...@seismo.berkeley.edu 215 McCone Hall # 4760 510.214.6506 (phone) University of California, Berkeley 510.643.5811 (fax) Berkeley, CA 94720-4760 ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
