On 14/07/2023 01:18, Jeffrey C. Witt wrote:
Hi Andy,

Thanks for your response.

Based on this comment...

It's not looking good for the database if /$/backup is falling. That's a
very simple use of the database.

Do you think the database is corrupted in such a way that it would be
better to just do a complete rebuild?

Yes, that is safer.

    Andy


Many thanks,
jw

On Thu, Jul 13, 2023 at 3:55 PM Andy Seaborne <[email protected]> wrote:

Hi Jeff,

There were fixes to compaction in 4.6.0.

On 12/07/2023 23:53, Jeffrey C. Witt wrote:
Dear List,

I ran into an unusual error today when I tried to backup (and also
compact)
my TDB instance.

I first encountered the error when trying to compact and backup up using
fuseki 4.3.2

I ran both:

If you ran them at the same time, you may have trigger the problem that
was fixed in 4.6.0.


$ curl -XPOST http://localhost:3030/$/backup/ds
$ curl -XPOST http://localhost:3030/$/compact/ds

Both of these commands executed for while, filling up disk space, and
then
suddently stopped:

Eventually, I ran:

$ curl -XGET http://localhost:3030/$/status

and for both the compact and backup command, I received:

   "success": false (as seen in the example below)

[ {
      "finished" : "2014-05-28T13:54:13.608+01:00" ,
      "started" : "2014-05-28T13:54:03.607+01:00" ,

2014?

      "task" : "backup" ,
      "taskId" : "1" ,
      "success" : false
    }
]


As I couldn't find any other message to help me diagnose the issue, I
stopped the running fuseki instance and tried to use the tdb2.tdbackup
command.

For this I used apache-jena-4.9.0 and I ran the following command

$ tdb2.tdbbackup --loc build

This command ran for a while, and I could see that it was writing to the
disk, but then it suddenly failed and gave me the following error
message.

...
*Caused by: org.apache.thrift.protocol.TProtocolException: Unrecognized
type 0*
...


(I am assuming that this error is the same reason the "compact" command
wasn't working.)

The problem would have happen on the failed compact, it just manifests
itself later on read.

(there is another way to cause the same problem - if some other process
touches database files)

I'm not really sure what's gone wrong. I've done the fuseki compact
command
several times without a problem.

Likewise, the Fuseki http server continues to be running well. It is
responding to all SPARQL GET requests as usual.

But as the database is growing (currently at 70G), and I need to be able
to
both back it up and compact it as it grows.

I would be most grateful for assistance or help diagnosing the issue.
Please let me know if I can provide more information.

It's not looking good for the database if /$/backup is falling. That's a
very simple use of the database.

You may be able to extract data using SPARQL.

Some data will be in the backup file (the tail of the file may be
managled but it's compressed n-quads so easy to text edit).

      Andy


Sincerely,

Jeff




Reply via email to