Unrecognized option in the metadata: search.version - irreparable database

[Alex]

Hi,

Our db just got corrupted after a shutdown using the command

$STARDOG_BINARIES/bin/stardog-admin server stop  -p fff -u admin

Here is the log on restart...

Initializing Stardog
WARN  2016-01-11 15:05:47,405 [main] com.complexible.stardog.metadata.MetadataIO:readBytes(260): Unrecognized option in the metadata: search.version
WARN  2016-01-11 15:05:47,628 [main] com.complexible.stardog.metadata.MetadataIO:readBytes(260): Unrecognized option in the metadata: search.version
Database new_olh will not be available because there was an error initializing the database: There was an error while reading the transaction log, cannot initialize databaseMoving irreparable database new_olh to /storage/.unusable/new_olh

Any ideas as to why this occurs?
Regards
Alex

[Michael Grove]

On Mon, Jan 11, 2016 at 10:35 AM, Alex <alex....@gmail.com> wrote:

Hi,

Our db just got corrupted after a shutdown using the command

$STARDOG_BINARIES/bin/stardog-admin server stop  -p fff -u admin

Here is the log on restart...

How quickly afterward did you kill the VM?  server stop is asynchronous, so it's not guaranteed that the server has already shutdown completely by the time the CLI returns.

 

Initializing Stardog
WARN  2016-01-11 15:05:47,405 [main] com.complexible.stardog.metadata.MetadataIO:readBytes(260): Unrecognized option in the metadata: search.version
WARN  2016-01-11 15:05:47,628 [main] com.complexible.stardog.metadata.MetadataIO:readBytes(260): Unrecognized option in the metadata: search.version

These can be ignored.

 

Database new_olh will not be available because there was an error initializing the database: There was an error while reading the transaction log, cannot initialize databaseMoving irreparable database new_olh to /storage/.unusable/new_olh

Any ideas as to why this occurs?

The log was probably incomplete.  At a guess, VM terminated before shutdown completed and the rest of the log was not finished flushing. The transaction log is used to improve node synchronization performance in the cluster. If you have it enabled in a single server, you're primarily using it to slow down your writes.

Cheers,

Mike

 

Regards
Alex

--
-- --
You received this message because you are subscribed to the C&P "Stardog" group.
To post to this group, send email to sta...@clarkparsia.com
To unsubscribe from this group, send email to
stardog+u...@clarkparsia.com
For more options, visit this group at
http://groups.google.com/a/clarkparsia.com/group/stardog?hl=en

[Alex Muir]

On Mon, Jan 11, 2016 at 9:18 PM, Michael Grove <mi...@complexible.com> wrote:

On Mon, Jan 11, 2016 at 10:35 AM, Alex <alex....@gmail.com> wrote:

Hi,

Our db just got corrupted after a shutdown using the command

$STARDOG_BINARIES/bin/stardog-admin server stop  -p fff -u admin

Here is the log on restart...

How quickly afterward did you kill the VM?  server stop is asynchronous, so it's not guaranteed that the server has already shutdown completely by the time the CLI returns.

 

 The docker container gets killed when the java process running stardog is killed.

 

Database new_olh will not be available because there was an error initializing the database: There was an error while reading the transaction log, cannot initialize databaseMoving irreparable database new_olh to /storage/.unusable/new_olh

Any ideas as to why this occurs?

> The log was probably incomplete.  At a guess, VM terminated before shutdown completed and the rest of the log was not finished flushing. The transaction log is used to improve > node synchronization performance in the cluster. If you have it enabled in a single server, you're primarily using it to slow down your writes.

Okay, from looking at the last operation in the log prior to the shutdown there had been nothing written to the log since the 8th. Although it did seem to end abruptly. There was no shutdown message in the log. Is one generated other than to console?

Is there a difference in the time taken to shutdown a database with a huge dataset and a small dataset.. 

Regards

Alex
www.tilogeo.com

[Michael Grove]

Yes, the log referred to in the message is the transaction log used for log shipping in the cluster.  It's binary, so you would not be able to read it.  It's in the directory where the database is stored.  If you could send that over so we can look at it, that'd be appreciated.

But if you're not using the cluster, there's no point in having cluster options enabled for a single node.  You can safely just move that log file out of the index's directory and restart; the database itself is fine.

 

Is there a difference in the time taken to shutdown a database with a huge dataset and a small dataset.

Some, but not a lot.  The number of databases also can affect shutdown time.  Shutdown will also wait a short amount of time for connections to close before severing them.  

Cheers,

Mike

 

Regards

Alex
www.tilogeo.com