Orientdb: All the metadata of indexes are lost after automatic index rebuilds

Created on 26 Jan 2017  路  11Comments  路  Source: orientechnologies/orientdb

OrientDB Version, operating system, or hardware.

  • v2.2.14

Operating System

  • [x] Linux

Expected behavior and actual behavior

All the metadata of indexes are lost after automatic index rebuilds...

We set the metadata

allowLeadingWildcard":true

for all of our Lucene indexes.

After a restart of our server (we had a sudden death of the system), a rebuild was started of nearly all of the indexes, including the Lucene indexes.
Now, I notice that such rebuilt Lucene indexes have not these metadata anymore. Obviously resulting in errors for our queries where we use such wildcards.

bug

Most helpful comment

hammering a running server every time seems to be too much expensive

no big deal: one possibility is to launch a virtual server, in that you run ODB server and get it busy; then from the host machine, abruptly stop the virtual server and disable abruptly its access to the disk device. Done.

All 11 comments

Hi, even if the clause allowLeadingWildcard":true involves only the Query parser behaviour, it is necessary to drop and rebuild the index to re-enable it.
I'm afraid of that. I've got other bugs in the backlog, I'll try to do my best to solve it.
Thanks for reporting

Hi, even if the clause allowLeadingWildcard":true involves only the Query parser behaviour, it is necessary to drop and rebuild the index to re-enable it.
I'm afraid of that. I've got other bugs in the backlog, I'll try to do my best to solve it.
Thanks for reporting

Hi, even if the clause allowLeadingWildcard":true involves only the Query parser behaviour, it is necessary to drop and rebuild the index to re-enable it.
I'm afraid of that. I've got other bugs in the backlog, I'll try to do my best to solve it.
Thanks for reporting

@robfrank

ok, thx for the confirmation, at least we know now it is a known bug. Which will be resolved very soon...;-)

Meanwhile, dropping and recreating these indexes. This lasts for about 1.5hrs per index (20-30M docs per class, multiple indexes per class). Only 17 indexes to go... :-(

I was not clear. We didn't have knowledge of the bug, but if after a crash the index rebuild procedure doesn't load the metadata, well, the index needs to be rebuilt. So, I'm trying to reproduce the bug, that's not so easy (hammering a running server every time seems to be too much expensive :) )

hammering a running server every time seems to be too much expensive

no big deal: one possibility is to launch a virtual server, in that you run ODB server and get it busy; then from the host machine, abruptly stop the virtual server and disable abruptly its access to the disk device. Done.

I've managed to replicate the bug.
Good: the index is recreated using the right metadata: indexes are rebuilt right!.
Bad: sometimes, after rebuild, the index is re-opened with wrong metadata.
Note that it happens only sometimes (random).
Possible workaround: after rebuild, switch off and the on the server.
We are working to find a fix.

@robfrank thx!
cool, that's already a big step in finding a fix.

FYI, @taburet is working actively on it.

We are doing final tests, the fix is on SNAPSHOTs and will be part of 2.2.17

Our tests are always green. I close and move on 2.2.17 milestone.

Was this page helpful?
0 / 5 - 0 ratings