On 12/01/17 14:14, Josip Deanovic wrote:
> So if one is for some reason locked to specific old version of a
> specific old proprietary application one can't do much than continue
> with the MyISAM as innodb is not an option and external search engines
> are not supported either.

I've had to deal with such software:


Once the database is created "UPDATE TABLE table ENGINE=MYISAM" works 
just fine in 99.9% of cases.

The only table I ever had trouble with was in GLPI, where one search 
function failed using innodb, but that was fixed in a more recent 
version of mysql anyway.

> I am not saying that innodb isn't a better mysql storage engine when
> compared to MyISAM. I am saying that sometimes the innodb is not the
> option and you have to stick with MyISAM for some time.
>
At the risk of offending someone:


1: If your database load is high enough that you really need to worry 
about myisam vs innodb for performance reasons then you should be 
considering using something like PostgreSQL anyway.

2: If Bacula has caused memory consumption of MySQL to grow larger than 
4GB, it's time to switch to PostgreSQL.

3: If your database must have utterly reliable recovery from a crash 
(including write recovery), it's time to look at using something other 
than mysql.


I'm not "dissing" MySQL. It's a brilliant database for what it's 
designed to do - a small, fast, simple query-optimised database for 
things like webservers.

It's not designed to be used in a write-heavy multiuser environment or 
with lots of complex queries. Once the system load (cpu and memory) of 
mysql exceeds that of another database (or queries are executed 
noticeably slower) then it's time to switch.


If you only have a hammer then every problem looks like a nail.

Even if you "only know mysql", it's not difficult to change to something 
else - and once you do, you'll be happily surprised to notice how little 
tuning pg_sql needs (almost none: Everything is designed to be 
automatically optimising and there's a pg_tune script which will do all 
the startup stuff for you)


Example: The Bacula system here needed regular MySQL maintenance. After 
switching to PGsql I find that I only ever look at it to confirm it's 
still working ok.


On a very small (sub 1GB) system, PostgreSQL vs MySQL will (on paper) 
favour mysql because of the no-load/no-data footprints, but on just 
about any x86 system made in the last 10 years there's no fundamental 
disadvantage to using PostgreSQL from the outset (and doing so avoids 
possibly crossing paths with Oracle in future)


If you are backing up databases:


The "best" strategy for DB table backup is DO NOT DO IT - generate a DB 
dump using the appropriate tools and back that up. Anything else will 
cause problems when it's restoration time.






------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users