We're using the 1.7 release version (which I believe had all of the latest durability enhancements).
Steve On Thursday, June 12, 2014 11:33:28 AM UTC-6, Lvc@ 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] <javascript:>> > 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] <javascript:>. >> 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.
