On 5/11/24 11:32, Phil Stracchino wrote:
On 5/10/24 18:31, Phil Stracchino wrote:
On 5/10/24 14:33, Phil Stracchino wrote:
On 5/9/24 21:07, Marcin Haba wrote:
Runscript {
Runs When = After
Runs On Client = no
Console = ".bvfs_update jobid = %i"
}
Yeah, this is consistent. It appears to WORK, but sends me a
'RunScript() Unknown term code' message for each and every backup job.
mmm, new development this morning, on a Differential job:
13-May 04:30 minbar-dir JobId 0: Using Catalog "Catalog"
13-May 04:30 minbar-dir JobId 0: Error: bdb.h:147 bdb.h:147 delete
DELETE FROM PathVisibility WHERE NOT EXISTS (SELECT 1 FROM Job WHERE
JobId=PathVisibility.JobId) failed:
wsrep_max_ws_rows exceeded
So .bvfs_update is generating too many rows in a single update here for
a Galera cluster. (Galera3 has a hard limit of 4GB/128K rows written in
any single replication update.)
If I were to try to *fix* this compatibility issue (and it would quite
possibly perform better this way anyway), what I would do there is add a
LIMIT 100000 and then loop on it until ROW_COUNT() < 100000. BEST
PRACTICE for Galera performance is to try to keep individual writes
below 10K rows, but an occasional 100K write isn't going to have much
impact.
--
Phil Stracchino
Fenian House Publishing
ph...@caerllewys.net
p...@co.ordinate.org
Landline: +1.603.293.8485
Mobile: +1.603.998.6958
_______________________________________________
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel
