Thanks Erick,
I will look harder at our current configuration and how we're handling
config replication, but I just realized that a backup script was doing a
commit and an optimize on the slave prior to taking the backup. This
happens daily, after updates and replication from the master. This is
s
Andrew:
I'm not entirely sure that's your problem, but it's the first thing I'd try.
As for your config files, see the section "Replicating solrconfig.xml"
here: http://wiki.apache.org/solr/SolrReplication. That at least
allows you to centralize separate solrconfigs for master and
slave, maki
Erick,
Thank you. I think originally my thought was that if I had my slave
configuration really close to my master config, it would be very easy to
promote a slave to a master (and vice versa) if necessary. But I think you
are correct that ripping out from the slave config anything that would
modi
Gotta admit it's a bit puzzling, and surely you want to move to the 3x
versions ..
But at a guess, things might be getting confused on the slaves given
you have a merge policy on them. There's no reason to have any
policies on the slaves; slaves should just be about copying the files
from the mast
Hi,
I am running solr 1.4.0+ds1-1ubuntu1. I have a master server that has a
number of solr instances running on it (150 or so), and nightly most of
them have documents written to them. The script that does these writes
(adds) does a commit and an optimize on the indexes when it's entirely
finished
Just off the top of my head, aren't you able to use a slave as a
repeater, so it's configured as both a master and a slave?
http://wiki.apache.org/solr/SolrReplication#Setting_up_a_Repeater
This would seem to require that the slave return the same values as
its master for indexversion. What happe
Yes, i read that too in the replication request handler's source comments. But
i would find it convenient if it would just use the same values as we see using
the details command.
Any devs agree? Then i'd open a ticket for this one.
On Tuesday 07 December 2010 17:14:09 Xin Li wrote:
> I read it
I read it somewhere (sorry for not remembering the source).. the
indexversion command gets the "replicable" index version #. Since it
is a slave machine, so the result is 0.
Thanks,
On Tue, Dec 7, 2010 at 11:06 AM, Markus Jelsma
wrote:
> But why? I'd expect valid version numbers although the rep
But why? I'd expect valid version numbers although the replication handler's
source code seems to agree with you judging from the comments.
On Monday 06 December 2010 17:49:16 Xin Li wrote:
> I think this is expected behavior. You have to issue the "details"
> command to get the real indexversion
I think this is expected behavior. You have to issue the "details"
command to get the real indexversion for slave machines.
Thanks,
Xin
On Mon, Dec 6, 2010 at 11:26 AM, Markus Jelsma
wrote:
> Hi,
>
> The indexversion command in the replicationHandler on slave nodes returns 0
> for indexversion a
Hi,
The indexversion command in the replicationHandler on slave nodes returns 0
for indexversion and generation while the details command does return the
correct information. I haven't found an existing ticket on this one although
https://issues.apache.org/jira/browse/SOLR-1573 has similarities
/solr/replication?command=details<http://slave_host:8983/solr/replication?command=indexversion>
and compare the index version on slave and on master, and put the instance
back in service when this two are the same. It works fine except that the
response claims that the structure of the respon
on the slave this command would not work well. The indexversion is not
the actual index version. It is the current replicateable index
version.
why do you call that API directly?
On Tue, Jul 21, 2009 at 12:53 AM, solr jay wrote:
> If you ask for the index version of a slave instance, you always
If you ask for the index version of a slave instance, you always get version
number being 0. Is it expected behavior?
I am using this url
http://slave_host:8983/solr/replication?command=indexversion
This request returns correct version on master.
If you use the 'details' command, you get the ri
14 matches
Mail list logo
