Why don't you create DNS names, or such, so that you can replace a
zookeeper instance at the same hostname:port rather than having to edit
solr.xml across your whole Solr farm?
The idea is that your list of zookeeper hostnames is a virtual one, not
a real one.
Upayavira
On Wed, Sep 30, 2015, at
On 9/29/2015 9:40 PM, pramodmm wrote:
> In the meantime, please help me validate what we are doing is right.
> Currently, our zookeeper instances are running on vmware machines and when
> one of them dies and we get a new machine as a replacement - we install
> zookeeper and make it a part of the
> The idea is that your list of zookeeper hostnames is a virtual one, not
> a real one.
Thanks for the suggestion. Looks like I am not alone in thinking along the
same lines. I am planning on doing that and was not sure if anyone else
tried this approach and validated that it worked.
--
Hi,
Is there an example which I could use - to upload solr.xml in zookeeper and
change zkhost entries on the fly and have solr instances be updated via
zookeeper. This will prevent us from restarting each solr node everytime, a
new zookeeper host is added or deleted.
We are on Solr 4.8.
Thanks,
On 9/29/2015 5:59 PM, pramodEbay wrote:
> Is there an example which I could use - to upload solr.xml in zookeeper and
> change zkhost entries on the fly and have solr instances be updated via
> zookeeper. This will prevent us from restarting each solr node everytime, a
> new zookeeper host is
> Before we even think about upgrading the zookeeper functionality in
> Solr, we must wait for the official 3.5 release from the zookeeper
> project. Alpha (or Beta) software will not be included in Solr unless
> it is the only way to fix a very serious bug. This is a new feature,
> not a bug.
