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
stephen AT seismo.berkeley DOT 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 AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
