At 01:10 PM 9/11/2015 -0400, Mark Tompsett wrote:
Greetings,
>
I would suggest the
cleanup_database.pl script in
the cronjobs directory, except I've just looked at it and it doesn't
touch the import_items or import_biblios tables.
As Galen mentioned it does via cascades. Thanks for pointing me at the
better way.
+1 (at least for Z39.50.) However for "cleaning up" purposes on
a limited VM machine, what's the size of your inno file? On my sandbox
(perhaps a tad smaller than your example):
root@[my_sandbox]:/var/lib/mysql# ls -l
total 1282100
-rw-rw---- 1 mysql mysql 1302331392 Sep 11 17:45 ibdata1
which is significant (nearly 4x the clean [1] sql dump at 354330649.) (To
get rid of it in production, you have to delete all MySQL tables before
removing this overweight monstrosity, then restore your dumps - takes
only a few seconds on a fast machine, so I've set up the cron for
"idle hours". Note this is a MySQL problem, not Koha; there was
some talk that MySQL 5.6 would alleviate it, but my experience is that it
does not -- only partiallytested, we're still using 5.5.44 in
production.)
Best -- Paul
[1] I have things set up to run:
./bin/cronjobs/cleanup_database.pl --import 1 &&
./bin/cronjobs/cleanup_database.pl --mail &&
./bin/cronjobs/cleanup_database.pl --sessions &&
./bin/cronjobs/cleanup_database.pl --logs 10 &&
./bin/cronjobs/cleanup_database.pl --zebraqueue 1
before mysqldump --user=[munged] --password=[munged] >
[munged]/backup/kohadump_{date}.sql