OK, that makes sense. However my main question is how do I recover
from a corrupt search index? The automatic repair that seems to kick
in on a restart notifies me that the index cannot be repaired. It
seems like a DB backup is not enough, and I also have to back up my
file-based search indexes. This seems bad, as it will be nearly
impossible to take these two backup snapshots of two persistent
stores in the same state.
On Jun 4, 2007, at 5:05 AM, Marcel Reutegger wrote:
Hi Noah,
Noah Vihinen wrote:
We've been running into issues with our jackrabbit index on forced
shutdowns. On restarts, we end up getting errors like the following:
Error indexing root node:
java.io.IOException: Error indexing root node:
b5d9c4a1-07d5-471e-9fc9-e9a2fbd6ae48
at
org.apache.jackrabbit.core.query.lucene.MultiIndex.<init>
(MultiIndex.java:313) at
org.apache.jackrabbit.core.query.lucene.SearchIndex.doInit
(SearchIndex.java:295) at
org.apache.jackrabbit.core.query.AbstractQueryHandler.init
(AbstractQueryHandler.java:44)
[...]
We attempted to get around this issue by simply deleted the index
of the repository (on the particular machine in a cluster) and
restarted with no luck. In the end, the only thing that seems to
work is to copy the index directory from one of the other
functional machines in our cluster, followed by a restart.
This seems like a really ugly way of getting around this issue.
Is there something obvious we're doing wrong. Shouldn't it be
possible to add a machine to a cluster with no pre-existing
index? What are we missing?
My guess is, that this happens because content is changed while the
new cluster node indexes (traverses) the workspace.
Might be related to: http://issues.apache.org/jira/browse/JCR-931
regards
marcel
