Claudiu created JCR-3689:
----------------------------

             Summary: Jackrabbit indexes are not up-to-date after performing 
database restore ...
                 Key: JCR-3689
                 URL: https://issues.apache.org/jira/browse/JCR-3689
             Project: Jackrabbit Content Repository
          Issue Type: Bug
          Components: indexing, jackrabbit-core, jackrabbit-jca
    Affects Versions: 2.6
         Environment: Linux 2.6.18-308.el5 #1 SMP Fri Jan 27 17:17:51 EST 2012 
x86_64 x86_64 x86_64 GNU/Linux
            Reporter: Claudiu


We have been requested to implement a backup/restore mechanism for our JCR 
repository. As we are using versioning for a given set of nodes we need to 
restore the entire version storage. As the JCR import/export API does not cope 
well with overwriting/updating the version storage, the only solution for us 
was to backup and restore the database (Oracle) + backup/restore of indexes (to 
avoid time spent in recreating indexes if the DB data volume is high).

After doing the above mentioned database restore + indexes restore, we have 
found that one frozen node corresponding to version 1.0 of a node cannot be 
located using a JCR SQL2 (the query is used by our app logic and works for all 
other cases). We had a look on the indexes but we cannot find any information 
related to that frozen node.

We tried to start the JCR repository with consistencyEnabled/consistencyFix 
(for persistence manager) as true and 
checkConsistencyEnabled/forceConsistencyCheck/autoRepair as true (for search 
index component). No errors have been reported so there was nothing to fix.

We tried also with an offline checker tool from Hippo CMS 
(http://maven.onehippo.com/maven2/org/onehippo/cms7/hippo-addon-checker/) but 
again no errors have been reported. 

If I am using the JCR API and accesing the node with the jcr uuid identifier I 
have no problems in location the node (probably because indexes are not 
involved in the process).

For us the problem is major because this is data inconsistency between the 
database and the indexes.

We would appreciate any suggestion.

Thanks.




--
This message was sent by Atlassian JIRA
(v6.1#6144)

Reply via email to