Bacula-users

Re: [Bacula-users] Optimize Mysql

2017-06-01 12:07:11
Subject: Re: [Bacula-users] Optimize Mysql
From: Alan Brown <ajb2 AT mssl.ucl.ac DOT uk>
Date: Thu, 1 Jun 2017 16:40:11 +0100
On 01/06/17 14:49, Petar Kozić wrote:
Yes, how to use ?

dbcheck checks the integrity of the databases, not the tuning of them.



With regard to tuning of mysql
- bear in mind that I'm saying this from the point of view of having spent years doing exactly that for Bacula.


DON'T DO IT.

If you you think you need to - DON'T.
If you already are - STOP.

If you're having to spend hours tuning MySQL then you're operating outside of the intended operating parameters for the database and you'll probably have to keep returning to the problem as the load changes. MySQL's memory requirements crank up rapidly and end up driving server requirements to extreme levels.

Once you're at that position (and preferably well before it), it's time to move to PostgreSQL.

It may seem daunting, and is a big step (changing your DB engine always is), but it's a necessary one if your backup sets are growing.

When you're into the "tens of millions of files in the database" territory, you'll find that PgSQL uses less memory, less CPU and is a _lot_ faster than MySQL for pretty much everything. The time spent learning how to use it (which is about 8-10 hours at most and usually more like 2-3) is more than made up by both the reduction in overheads keeping a MySQL-based Bacula system going AND the cost reduction in server hardware to support the MySQL database.


If your Backup sets are large enough that you need to consider "tuning" MySQL, then that time is better spent installing PgSQL. MySQL tuning for a backup system at largeish scales ends up being a "black hole" in terms of administrative time and can lead to substantial recovery delays when (not if) MySQL breaks.

I'm sure this will trigger religious arguments about databases, but bear in mind that I held off moving to PgSQL for 7-8 years because of fears over complexity and difficulty - which proved to be baseless. The hardest part of the transition turned out to be making a MySQL dump that was properly portable - read the man pages because a standard mysqldump is not ansi compliant.

(The same database in PgSQL uses less than 1/2 the system resources and under 1/4 memory that it used in MySQL, so this transition was worth it when adding another 48GB ram to the system would have cost over $2000. It's still worth it today despite memory being cheaper, because for the most part PgSQL is self-tuning, meaning far less administrative overhead on a stressed system)


For similar reasons, I would strongly _discourage_ installing a new Bacula system based on MySQL. Changing databases is a lot harder than choosing one in the first place which will handle growth without needing substantial administrative time.



--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
<Prev in Thread] Current Thread [Next in Thread>

ADSM.ORG Privacy and Data Security by https://kimlaw.us