We are having problems with disastrous index rebuilds. We are currently on
2.1.0
In the server.sh we are setting index.auto.rebuildAfterNotSoftClose to
false and index.txMode to FULL. We see these settings when we look at the
studio configuration dashboard.
The server is crashing and on restart we see:
2015-08-26 17:51:56:001 WARNI {db=[redacted]} Non tx operation was used
during data modification we will need index rebuild.
[OLocalPaginatedStorage]
Questions:
1) Is there anything additional we have to do to prevent these index
rebuilds other than setting index.auto.rebuildAfterNotSoftClose and
index.txMode?
2) we are trying to wrap everything in transactions and are having trouble
tracking down what caused the non-tx operation. Is there any way to easily
figure out what caused the non-tx operation?
3) We can see the settings in the studio dashboard and in the configuration
dump when the server is started. When we try to connect in console to a
specific database however we are seeing
index.auto.rebuildAfterNotSoftClose set to the default (true)
I also asked about this issue here:
https://github.com/orientechnologies/orientdb/issues/4181
On Friday, February 6, 2015 at 4:27:20 AM UTC-8, Lvc@ wrote:
>
> Hi Chanras,
> When you killed the process, OrientDB was flushing pages on disk. During
> this operation you could have portion of your database lost. In this case
> OrientDB read the WAL (Journal) and rollback any non committed
> transactions. This is to *apply the ACIDity of transactions*.
>
> About indexes they were rebuilt because you didn't apply changes in
> transaction. Please be sure to *always do changes inside a transaction*,
> otherwise indexes could be broken.
>
> Luca
>
>
> On 6 February 2015 at 03:43, Chanras Sun <[email protected] <javascript:>
> > wrote:
>
>> Dear OrientDB Team,
>>
>> Thank for your great work, I really like the way of OrientDB design and
>> it features.
>> I have been evaluating OrientDB for big data project and every thing seem
>> to be fine, except robustness with big data and slow in graph traversal.
>> The problem is that, I got 300 millions of user records, the query time was
>> great ( not graph traversal) but when the server was suddenly out of power,
>> I mean power cut or kill Java process or JVM crash the OrientDB system take
>> 5 hours to recover database and take 12 hours to rebuild indexes(3 indexes,
>> each index need at least 4 hours to rebuild). I think it hard to deal with
>> this characteristic in production environment.
>>
>> (OrientDB 2.0.1 Community edition)
>> best regards,
>>
>> @S. Chanras
>>
>> --
>>
>> ---
>> 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.
