Re: Runscript Unknown term code Re: Bacula 15.0.2 update

Phil Stracchino <[email protected]> Mon, 13 May 2024 14:20:36 -0400
Newsgroups gmane.comp.sysutils.backup.bacula.devel
Organization Fenian House Publishing
Message-ID <[email protected]>
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
   [email protected]
   [email protected]
   Landline: +1.603.293.8485
   Mobile:   +1.603.998.6958



_______________________________________________
Bacula-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-devel