Re: Problem with replication
We have tried that as well, but the slave still claims to have a higher index version, even when the index files were deleted completely Regards Thomas Stevo Slavić, 20.01.2011 16:52: Not too elegant but valid check would be to bring slave down, delete it's index data directory, then to commit a change to index to master, then bring slave up, and wait for pollInterval to pass and replication to occur. Regards, Stevo. On Thu, Jan 20, 2011 at 4:16 PM, Thomas Kellerer wrote: Stevo Slavić, 20.01.2011 15:42: So if on startup index gets replicated, then commit probably isn't being called anywhere on master. No, the index is not replicated on startup (same behaviour: "no files to download") Is that index configured to autocommit on master, or do you commit from application code? If you commit from application code, check if commit actually gets issued to the slave. We explicitely commit() from the application when doing an update to the index. How do I check if the commit is "sent" to the slave other than monitoring the polling on the slave (which doesn't pick up the changes) Regards Thomas
Re: Problem with replication
Stevo Slavić, 20.01.2011 15:42: So if on startup index gets replicated, then commit probably isn't being called anywhere on master. No, the index is not replicated on startup (same behaviour: "no files to download") Is that index configured to autocommit on master, or do you commit from application code? If you commit from application code, check if commit actually gets issued to the slave. We explicitely commit() from the application when doing an update to the index. How do I check if the commit is "sent" to the slave other than monitoring the polling on the slave (which doesn't pick up the changes) Regards Thomas
Re: Problem with replication
Thomas Kellerer, 20.01.2011 12:53: Hi all, we have implemented a Solr based search in our web application. We have one master server that maintains the index which is replicated to the slaves using the built-in Solr replication. This has been working fine so far, but suddenly the replication does not send the modified files to the slaves. Each time the slave polls the master, the master answers with "No files to download for indexversion: 1291900430240" The problem is, that the index version on the master **is** higher than the one on the slave. One other thing I noticed: When I do http://host:port/solr/replication?command=indexversion on the slave, it returns 0 (zero) 0 0 0 0 But when I http://host:port/solr/core0/admin/replication/index.jsp on the slave, it displays a "valid" indexversion. Don't know that that means though. Regards Thomas
Re: Problem with replication
Here is our configuration:
true
commit
startup
stopwords.txt,stopwords_de.txt,stopwords_en.txt,synonyms.txt
Stevo Slavić, 20.01.2011 13:26:
On which events did you configure master to perform replication? replicateAfter
Regards,
Stevo.
On Thu, Jan 20, 2011 at 12:53 PM, Thomas Kellerer wrote:
Hi all,
we have implemented a Solr based search in our web application. We have one
master server that maintains the index which is replicated to the slaves
using the built-in Solr replication.
This has been working fine so far, but suddenly the replication does not
send the modified files to the slaves.
Each time the slave polls the master, the master answers with "No files to
download for indexversion: 1291900430240"
The problem is, that the index version on the master **is** higher than the
one on the slave.
We have something like this:
Master: Index Version: 1291900430241, Generation: 1288
Slave: Index Version: 1291900430240, Generation: 1287
But still the files are not replicated ("No files to download...")
Why would the master think that no files need to be replicated even though
the slave version and generation are lower than the one from the master?
What makes the problem even more difficult is, that this isn't reproducable.
Sometimes re-starting the master puts everything back to normal.
Any ideas?
Regards
Thomas
Problem with replication
Hi all,
we have implemented a Solr based search in our web application. We have one
master server that maintains the index which is replicated to the slaves using
the built-in Solr replication.
This has been working fine so far, but suddenly the replication does not send
the modified files to the slaves.
Each time the slave polls the master, the master answers with "No files to download
for indexversion: 1291900430240"
The problem is, that the index version on the master **is** higher than the one
on the slave.
We have something like this:
Master: Index Version: 1291900430241, Generation: 1288
Slave: Index Version: 1291900430240, Generation: 1287
But still the files are not replicated ("No files to download...")
Why would the master think that no files need to be replicated even though the
slave version and generation are lower than the one from the master?
What makes the problem even more difficult is, that this isn't reproducable.
Sometimes re-starting the master puts everything back to normal.
Any ideas?
Regards
Thomas
Re: Term is duplicated when updating a document
Thanks. Not really the answer I wanted to hear, but at least I know this is not my fault ;) Regards Thomas Erick Erickson, 15.10.2010 20:42: This is actually known behavior. The problem is that when you update a document, it's deleted and re-added, but the original is marked as deleted. However, the terms aren't touched, both the original and the new document's terms are counted. It'd be hard, very hard, to remove the terms from the inverted index efficiently. But when you optimize, all the deleted documents (and their assiociated terms) are physically removed from the files, thus your term counts change. HTH Erick On Fri, Oct 15, 2010 at 10:05 AM, Thomas Kellererwrote: Thanks for the answer. Which fields are modified when the document is updated/replaced. Only one field was changed, but it was not the one where the auto-suggest term is coming from. Are there any differences in the content of the fields that you are using for the AutoSuggest. No Have you changed you schema.xml file recently? If you have, then there may have been changes in the way these fields are analyzed and broken down to terms. No, I did a complete index rebuild to rule out things like that. Then after startup, did a search, then updated the document and did a search again. Regards Thomas This may be a bug if you did not change the field or the schema file but the terms count is changing. On Fri, Oct 15, 2010 at 9:14 AM, Thomas Kellerer wrote: Hi, we are updating our documents (that represent products in our shop) when a dealer modifies them, by calling SolrServer.add(SolrInputDocument) with the updated document. My understanding is, that there is no other way of updating an existing document. However we also use a term query to autocomplete the search field for the user, but each time adocument is updated (added) the term count is incremented. So after starting with a new index the count is e.g. 1, then the document (that contains that term) is updated, and the count is 2, the next update will set this to 3 and so on. One the index is optimized (by calling SolServer.optimize()) the count is correct again. Am I missing something or is this a bug in Solr/Lucene? Thanks in advance Thomas
Re: Term is duplicated when updating a document
Thanks for the answer. Which fields are modified when the document is updated/replaced. Only one field was changed, but it was not the one where the auto-suggest term is coming from. Are there any differences in the content of the fields that you are using for the AutoSuggest. No Have you changed you schema.xml file recently? If you have, then there may have been changes in the way these fields are analyzed and broken down to terms. No, I did a complete index rebuild to rule out things like that. Then after startup, did a search, then updated the document and did a search again. Regards Thomas This may be a bug if you did not change the field or the schema file but the terms count is changing. On Fri, Oct 15, 2010 at 9:14 AM, Thomas Kellerer wrote: Hi, we are updating our documents (that represent products in our shop) when a dealer modifies them, by calling SolrServer.add(SolrInputDocument) with the updated document. My understanding is, that there is no other way of updating an existing document. However we also use a term query to autocomplete the search field for the user, but each time adocument is updated (added) the term count is incremented. So after starting with a new index the count is e.g. 1, then the document (that contains that term) is updated, and the count is 2, the next update will set this to 3 and so on. One the index is optimized (by calling SolServer.optimize()) the count is correct again. Am I missing something or is this a bug in Solr/Lucene? Thanks in advance Thomas
Term is duplicated when updating a document
Hi, we are updating our documents (that represent products in our shop) when a dealer modifies them, by calling SolrServer.add(SolrInputDocument) with the updated document. My understanding is, that there is no other way of updating an existing document. However we also use a term query to autocomplete the search field for the user, but each time adocument is updated (added) the term count is incremented. So after starting with a new index the count is e.g. 1, then the document (that contains that term) is updated, and the count is 2, the next update will set this to 3 and so on. One the index is optimized (by calling SolServer.optimize()) the count is correct again. Am I missing something or is this a bug in Solr/Lucene? Thanks in advance Thomas
Strange search result (or lack of)
Hi, I have the following field defined in my schema: The field contains the value "Das Urteil" which is thus stored as "das urteil" The following query (using Solr 1.4) returns nothing name_de:das urteil But when I run the query name_de:"das urteil" the expected document is found. When I check this through the "Analysis" page of the solr admin it does show me a match for the first query. I'm sure I'm missing something obvious. But what? Regards Thomas
