TDB backup is safer way to back it up. It is not safe to copy the files
of a live database because you may copy different files at different
points in time.
You can build from a backup, and copy files, then start TDB.
Or even capture changes; build from a backup, and replay patches. That
is what rdf-delta (not part of Jena) does.
TDB2 also offers a possibility that might work for you.
It has a compaction step that produces a new, smaller database (TDB2
databases grow faster then TDB1). Like TDB1, you can't safely copy a
live database around. But the old database after compaction is not live.
You can sync twice to produce a small copy.
Andy
On 05/01/18 06:35, Dimov, Stefan wrote:
Thanks Lorenz,
That could work if the DB is already deployed.
How about initial deployment on multiple nodes? Or vice versa – copying it up
from live nodes to some backup/archive storage?
S.
On 12/22/17, 11:46 PM, "Lorenz Buehmann" <[email protected]>
wrote:
Probably I misunderstand the workflow, but isn't it more efficient to
push the changeset to all nodes instead of copying the whole TDB? I.e.
synchronizing the TDB instances on the triple level instead of files.
Cheers,
Lorenz
On 23.12.2017 01:55, Dimov, Stefan wrote:
> Yes, this is high av., deployment and backup.
>
> We have cloud system with multiple nodes and TDB needs to be copied
to/from these nodes. Copied from – when we need to back it up and copied to – when
we deploy it. So, the problems come when we copy from/to the nodes – it takes
time, operations sometimes fail, downtime - the nodes don’t work while we copy the
TDB (it’s a limitation that comes from Jena/TDB) and also sometimes the hardware
OS is throwing errors just because there are big files on it (without even copying
them).
>
> Before you say “you need a better hardware”, I agree, but that’s what we
have right now, so I was just wondering if somebody had similar problems and how
they resolved it (apart from replacing the hardware with faster, bigger and high
av. one ( )
>
> Regards,
> Stefan
>
>
> On 12/22/17, 4:24 PM, "ajs6f" <[email protected]> wrote:
>
> Can you tell us about the workflow that is managing them? You
mention copying and maintaining TDB files-- is that for high availability? Are you
writing updates to a master and replicating the resulting store, or some other
scenario?
>
> ajs6f
>
> > On Dec 22, 2017, at 7:19 PM, Dimov, Stefan <[email protected]>
wrote:
> >
> > Our TDB now is about 32G and I see that some of its files are
almost 5G (single file size), but let’s assume it can/will grow 3, 4, 5 times …
> >
> > On 12/22/17, 2:16 PM, "Dick Murray" <[email protected]> wrote:
> >
> > How big? How many?
> >
> > On 22 Dec 2017 8:37 pm, "Dimov, Stefan" <[email protected]>
wrote:
> >
> >> Hi all,
> >>
> >> We have a project, which we’re trying to productize and we’re
facing
> >> certain operational issues with big size files. Especially with
copying and
> >> maintaining them on the productive cloud hardware (application
nodes).
> >>
> >> Did anybody have similar issues? How did you resolve them?
> >>
> >> I will appreciate if someone shares their
experience/problems/solutions.
> >>
> >> Regards,
> >> Stefan
> >>
> >
> >
>
>
>
>
