[Koha-devel] incremental backup of the DB
Paul A
paul.a at navalmarinearchive.com
Thu Nov 19 18:12:10 CET 2015
At 12:15 PM 11/19/2015 +1300, Robin Sheat wrote:
>Paul A schreef op wo 18-11-2015 om 17:49 [-0500]:
> > Very interesting, can you share more details?
>
>Not really, I didn't implement it.
>
>But essentially it provides an offsite database replicant that can then
>be backed up using snapshotting or whatever. I think regularly dumping a
>running database would not be best practice, as it puts a significant
>load on the server, and also may lock certain actions (don't quote me on
>that though.)
Robin -- first and foremost, my best wishes for your move and new job, I'm
sure that everyone here will miss your enthusiasm, experience and wisdom.
As to the intricacies of backing up a MySQL database, we're probably going
outside the "Koha envelope" but Mark T. and David C. both echoed your
concern on "load on the server." I am of the opinion that this is purely
hardware related, and server investment should reflect in-production use
plus a suitable margin. We HAProxy two servers, each with 8-core CPUs and
16G RAM; the swap files have never been written to. The "system", all Koha
files and MySQL + InnoDB are on raided solid state drives.
As I wrote originally, the Koha routines to "clean" the db (especially
sessions, unused Z39-50 data etc more than a day old) plus the dump takes
~2 seconds. I'm fairly certain that the lock time on the db is less than
this (as the lock is released before the write happens -- I think as soon
as dump has read binlog, but I'd have to immerse myself again in the
intricacies, possibly of flag --single-transaction.)
So, what we see in about 4 years of production practice is (a) that we have
never found any backup corruption, (b) our staff and cataloguers have never
noticed any slow-downs that substantially differ from normal
LAN|router|cable latency, and (c) even under extreme conditions (Bing,
Google and Baidu once hit between them 186,000 requests/hour) the limiting
factor is never MySQL but always Zebra (with or without ZEBRAOPTIONS "-T"
flag.)
Hoping this response wasn't too long, and again, best wishes for your future...
Paul
---
Maritime heritage and history, preservation and conservation,
research and education through the written word and the arts.
<http://NavalMarineArchive.com> and <http://UltraMarine.ca>
More information about the Koha-devel
mailing list