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