I like the multiple instance case—I hadn’t consider that, but if I undertand how BaseX works with indexes, it should be as easy as making a backup from instance A and restoring it to instance B?
Or maybe just have a shared /data dir and be careful about which instance is accessing a given database so there are not concurrent writes?
I’m using node IDs as index lookup keys so I’d have to make sure that node IDs persist across backup and restore but surely that is the case?
But it certainly makes sense to do my long-running persistent index construction in one instance and then expose it through another as read-only for user access.
Will explore this.
Cheers,
E.
_____________________________________________
Eliot Kimber
Sr Staff Content Engineer
O: 512 554 9368
M: 512 554 9368
LinkedIn | Twitter | YouTube | Facebook
From:
Christian Grün <christian.gruen@gmail.com>
Date: Monday, February 7, 2022 at 12:28 PM
To: Eliot Kimber <eliot.kimber@servicenow.com>
Cc: basex-talk@mailman.uni-konstanz.de <basex-talk@mailman.uni-konstanz.de>
Subject: Re: [basex-talk] Managing/Debugging Server Load and Performance
[External Email]
> I am seeing that when BaseX is doing some long-running process (constructing one of our big custom indexes) that it seems to consume all the BaseX cycles and the HTTP server becomes unresponsive.
If you perform expensive write operations on databases that other
users want to access, they’ll need to wait until this operation is
finished.
There are various ways out: You can e.g. create temporary instances of
your index databases and drop the operative database instances after
your maintenance operations have finished. For high-availability use
cases, you can also work with multiple BaseX instances.
> […] this use of BaseX was completely unplanned but suddenly very much desired…
Always good to hear!