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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
