Hi Steven, About last errors corrupt literal length and serialization errors, it is related to old Snappy library, could you migrate to 1.7 version or to gzip to solve it ?
This error "Can not restore 1 WAL master record for storage" is waring you can skip it. On Thu, Jun 12, 2014 at 8:33 PM, Luca Garulli <[email protected]> wrote: > Hey Steven, > We're here to help you. > > First question: what version are you using? Have you upgraded OrientDB > following all the enhancement on durability? > > Lvc@ > > > > On 12 June 2014 19:22, StevenTomer <[email protected]> wrote: > >> We've been running with OrientDB for a very long time now, and have >> deployed many >> software packages including it. We love the interface, and have written >> our own C++ >> library to talk to the server over the remote mode (Network Binary >> Protocol). We've >> invested a lot of time in it, and have found and reported quite a number >> of bugs over >> the years. >> >> However, the database itself seems to be extremely brittle. I cannot >> count the number >> of times I have had to respond to service calls because the database was >> broken. In >> almost every case, the database was broken beyond repair, causing total >> data loss. >> >> In no case was this due to the use of the database - all use was through >> the given >> APIs, Select, Traverse, Record Load, and Transactions. >> >> We were hoping that the plocal / WAL upgrades would solve these problems, >> but they >> haven't. The current situation is untenable for us, as we're trying to >> ramp up our >> deployment of these software packages. >> >> Unfortunately, we have not discovered a trigger to the problems, which >> has made futile >> our attempts at determining where the problem lies. Sometimes it seems >> like the >> problems have been around power failures, but other times it just happens >> while in >> the course of normal operation / running. >> >> We've seen: >> - Record broken errors >> - Corrupt literal length >> - Serialization errors when reading a record >> - Can not restore 1 WAL master record for storage >> - Where the unique index becomes out-of-sync with the cluster, so items >> containing >> the same value are inserted, so a rebuild of the index fails, after which >> the database >> continues to accept new inserts of records with values already in the >> index >> - When a single record is broken, it shuts down queries across the entire >> cluster, >> eliminating access to any other data. >> >> Unfortunately, we can't send broken databases because of proprietary >> customer data >> and privacy concerns. >> >> I can't believe that our use case (think a 'forest' of tree hierarchies >> that change with >> some frequency), where we commit trees through transactions, and have >> several >> not unique and one unique index, is out of the norm. The database >> storage should >> be durable, the index should always be in sync with it, and data loss is >> just plain >> unacceptable. >> >> We would much prefer to fix the problems rather than try to find another >> solution >> (or even develop our own if we have to), but without a good way to >> reproduce the >> myriad of failure modes we've seen, we don't know how to report them to >> you in a >> way that you'll be able to do something about. >> >> I'd like to give my full recommendation to OrientDB, but can't. I would >> steer any >> current developers away from it. Durability, above all other >> considerations, should >> be the rule. A database must be bulletproof. >> >> Please, I'm begging you for suggestions on where to go from here. We >> really don't >> want to remove OrientDB from our products, but given the current >> direction, there >> really doesn't seem to be much choice. >> >> Thank you for your attention. >> >> Steven Tomer >> >> -- >> >> --- >> You received this message because you are subscribed to the Google Groups >> "OrientDB" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > > --- > You received this message because you are subscribed to the Google Groups > "OrientDB" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Best regards, Andrey Lomakin. Orient Technologies the Company behind OrientDB -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
