Re: Performance issue
Phil Stracchino <[email protected]>
| Newsgroups | gmane.comp.bacula.user |
|---|---|
| Organization | Fenian House Publishing |
| Message-ID | <[email protected]> |
On 1/24/25 13:22, Bill Arlofski via Bacula-users wrote: > I will let a developer comment on this as it is "Above my pay grade"™, but I can say that I have seen horrific backup > performance with attribute spooling disabled. It has been very many years since I last even tried, but apparently it is not > (was not?) very efficient to write the attributes of each file to the catalog in real time as the backup is running. The problem is that as it works now, those 'spooled' attributes are 'spooled' by writing them to a temporary table ANYWAY. And if that table contains even a single BLOB/TEXT table or is larger than TMP_TABLE_SIZE, which defaults to 16K, it will be forced to disk. It would be better to 'spool' them either to a temporary file or to an in-memory store, then burst-write that cache to the catalog. I once tried looking into rewriting it myself, but I don't understand enough C++ or the architecture of the Bacula MySQL driver. >> this huge atomic write *also* makes it incompatible with Galera 3 clusters.) > > This is interesting and useful news to me because we have prospects recently coming to us asking about Galera clusters. Thank > you. :) Yeah, the limitation is that Galera 3 has a hard limit of 128K records (and if I remember correctly, 4GB total volume) on replicated writes. This limit is eliminated in Galera 4 which can do arbitrary-size streaming writes, but MySQL/MariaDB clustering does not yet use Galera 4. I can tell you that with attribute spooling *disabled*, it works very well on a Galera back-end. -- Phil Stracchino Fenian House Publishing [email protected] [email protected] Landline: +1.603.293.8485 Mobile: +1.603.998.69 _______________________________________________ Bacula-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-users