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? 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 > > > -- Dr. Jeffrey C. Witt Philosophy Department Loyola University Maryland 4501 N. Charles St. Baltimore, MD 21210 www.jeffreycwitt.com
