Microsoft.Isam.Esent.Interop.EsentLogFileCorruptException: Log file is corrupt

336 views
Skip to first unread message

Edwin Frey

unread,
Nov 19, 2014, 10:48:48 AM11/19/14
to rav...@googlegroups.com
Good morning!

Last night Azure Storage decided to die, which killed all 4 of my ravendb virtual machines.  3 of them came up with no issues after a recovery period.  The forth did not.  Luckily it was a slave and not the master.

{"Error":"Could not open database named: X","Reason":"System.AggregateException: One or more errors occurred. ---> System.InvalidOperationException: Could not open transactional storage: F:\\RavenDB\\Databases\\X\\Data ---> Microsoft.Isam.Esent.Interop.EsentLogFileCorruptException: Log file is corrupt\r\n   at Raven.Storage.Esent.TransactionalStorage.Initialize(IUuidGenerator uuidGenerator, OrderedPartCollection`1 documentCodecs)\r\n

I found an error similar to this on the boards :

https://groups.google.com/forum/#!searchin/ravendb/Log$20file$20is$20corrupt/ravendb/pliRKvd5qco/Yo5vPT9blxUJ


I ran the command suggested in that post and the output was:


PS F:\RavenDB\Databases\X> esentutl /r RVN /l logs /s system

Extensible Storage Engine Utilities for Microsoft(R) Windows(R)
Version 6.3
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating RECOVERY mode...
    Logfile base name: RVN
            Log files: logs
         System files: system

Performing soft recovery...
                      Restore Status (% complete)

          0    10   20   30   40   50   60   70   80   90  100
          |----|----|----|----|----|----|----|----|----|----|
          .................................X



Operation terminated with error -501 (JET_errLogFileCorrupt, Log file is corrupt) after 46.610 seconds.

Since a recovery didn't work, would the next step be an esentutl /p to repair the DB?  What are the parameters that should be run in that case?  Will there be data loss that it might not account for in replication?  Other options?  


Thank you for your time!
-Ed

Oren Eini (Ayende Rahien)

unread,
Nov 19, 2014, 10:52:36 AM11/19/14
to ravendb
You can go that route, yes. But if it is a slave, just create a new db and let it replicate.

Hibernating Rhinos Ltd  

Oren Eini l CEO Mobile: + 972-52-548-6969

Office: +972-4-622-7811 l Fax: +972-153-4-622-7811

 


--
You received this message because you are subscribed to the Google Groups "RavenDB - 2nd generation document database" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Edwin Frey

unread,
Nov 19, 2014, 10:56:11 AM11/19/14
to rav...@googlegroups.com
Thank you, that's what I'll do.  Just so I can add it to our ops documentation, is the repair the route we'd have to go with on the master?  or at that point is a restore from backup a better approach?  

Oren Eini (Ayende Rahien)

unread,
Nov 19, 2014, 10:57:56 AM11/19/14
to ravendb
If this happened on the master, I would suggest making one of the slaves the master, instead.
Reply all
Reply to author
Forward
0 new messages