The index folder is indeed gone but it seems to work. Maybe just a
structural change...
Met vriendelijke groeten
Arkadi Colson
Smartbit bvba • Hoogstraat 13 • 3670 Meeuwen
T +32 11 64 08 80 • F +32 11 64 08 81
On 04/02/2013 04:08 PM, yayati wrote:
I moved solr 4.1 to solr 4.2 on one of slave
I moved solr 4.1 to solr 4.2 on one of slave server earlier my index
directory has index.timestamp, but now, it has only index folder no
timestamp. Is this is bug.?? Though size of index is same as on master . It
shows replication running on dasboard with both master and slave version.
what happene
On Feb 27, 2013, at 4:40 AM, Bernd Fehling
wrote:
> Under this circumstances with replication I would not even dream about using
> SolrCloud.
The funny part about that is that the master->slave replication issue(s) in 4.1
don't apply to SolrCloud, so you would have had better luck :)
- Mark
I always have a "clean" index folder, I mean I don't get the
index. folder at any time. Besides, I haven't noticed that slaves
pull entire index in replication.
I restarted my repeater node and replication started to work fine again, the
slaves updated all the changes that their master had. But af
May be the info about index version is pulled from the repeaters
"data/replication.properties" file and the content of that file
is wrong.
Had something similar and only solution for me was deleting the
replication.properties file. But no guarantee about this.
Actually the replication is pretty mu
I'm now having a different problem. In my master-repeater-2slaves
architecture I have these generations versions:
Master: 29147
Repeater: 29147
Slaves: 29037
When I go to slaves logs it shows "Slave in sync with master". That is
apparently because if I do
http://localhost:17045/solr/replication?co
Interesting, that there is no such a bug if I disable index compression,
discussed here:
https://issues.apache.org/jira/browse/SOLR-4375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13566364#comment-13566364
--
View this message in context:
http://lucen
On Feb 25, 2013, at 5:54 AM, raulgrande83 wrote:
> Mark, is going to be an official 4.2 release soon?
I've suggested on the dev mailing list that I will create a Lucene/Solr 4.2
release within the next few weeks unless someone beats me to it.
I can't do it this week, I likely can't do it next
Hello everybody.
I have downloaded the 4.2-SNAPSHOT version that Mark linked at the JIRA and
our first tests have been OK. Slaves now doesn't need to replicate the
entire index and index versions between nodes are the same when replication
process is completed.
This 4.2 version is here:
https://i
We are fixing this bug here: https://issues.apache.org/jira/browse/SOLR-4471
- Mark
On Feb 22, 2013, at 7:07 AM, Artyom wrote:
> I have the same problem. This bug appeared in 4.0 rarely, but 4.1 downloads
> the full index every time.
>
I have the same problem. This bug appeared in 4.0 rarely, but 4.1 downloads
the full index every time.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Slaves-always-replicate-entire-index-Index-versions-tp4041256p4042209.html
Sent from the Solr - User mailing list archive at
Amit Nithian wrote
> For your issue above in your last post, is it possible that there was a
> commit on the master in that slight window after solr checks for the
> latest
> generation of the master but before it downloads the actual files? How
> frequent are the commits on your master?
No, I don
Sounds good I am trying the combination of my patch and 4413 now to see how
it works and will have to see if I can put unit tests around them as some
of what I thought may not be true with respect to the commit generation
numbers.
For your issue above in your last post, is it possible that there w
Thanks for the patch, we'll try to install these fixes and post if
replication works or not.
I renamed 'index.' folders to just 'index' but it didn't work.
These lines appeared in the log:
INFO: Master's generation: 64594
21-feb-2013 10:42:00 org.apache.solr.handler.SnapPuller fetchLatestIndex
I
Thanks for the links... I have updated SOLR-4471 with a proposed solution
that I hope can be incorporated or amended so we can get a clean fix into
the next version so our operations and network staff will be happier with
not having gigs of data flying around the network :-)
On Thu, Feb 21, 2013
Hi Amit,
I have came across some JIRAs that may be useful in this issue:
https://issues.apache.org/jira/browse/SOLR-4471
https://issues.apache.org/jira/browse/SOLR-4354
https://issues.apache.org/jira/browse/SOLR-4303
https://issues.apache.org/jira/browse/SOLR-4413
https://issues.apache.org/jira/br
A few others have posted about this too apparently and SOLR-4413 is the
root problem. Basically what I am seeing is that if your index directory is
not index/ but rather index. set in the index.properties a new
index will be downloaded all the time because the download is expecting
your index to be
17 matches
Mail list logo
