Re: Determining master/slave from ZK in SolrCloud
I attached my patch to do this to the JIRA at
https://issues.apache.org/jira/browse/SOLR-2765?jwupdated=55859&focusedCommentId=13122185#comment-13122185.
Any comments would be appreciated.
On Tue, Oct 4, 2011 at 1:06 PM, Jamie Johnson wrote:
> so my initial test worked, this appeared in ZK now
>
> roles=searcher,indexer
>
> which I can use to tell if it should be used to write to or not. It
> had fewer changes to other files as well
>
> I needed to change
> CloudDescriptor (add roles variable/methods)
> CoreContainer (parse roles attribute)
> ZKController (store roles in ZK)
>
> and now what is in ZK is the following:
>
> roles=searcher,indexer
> node_name=hostname:8983_solr
> url=http://hostname:8983/solr/
>
> As I said this will meet my need, I can provide my changes back to the
> JIRA referenced if this is what is expected from roles.
>
> On Tue, Oct 4, 2011 at 12:45 PM, Jamie Johnson wrote:
>> So I see this JIRA which references roles
>>
>> https://issues.apache.org/jira/browse/SOLR-2765
>>
>> I'm looking at implementing what Yonik suggested, namely in
>> solrconfig.xml I have something like
>>
>> > collection="${collection}" roles="searcher,indexer"/>
>>
>> these will be pulled out and added to the cloudDescriptor so they can
>> be saved in ZK. Seem reasonable?
>>
>> On Tue, Oct 4, 2011 at 12:17 PM, Jamie Johnson wrote:
>>> also as an FYI I created this JIRA
>>>
>>> https://issues.apache.org/jira/browse/SOLR-2811
>>>
>>> which perhaps should be removed if the roles option comes to life. Is
>>> there a JIRA on that now?
>>>
>>> On Tue, Oct 4, 2011 at 12:12 PM, Jamie Johnson wrote:
Thanks for the reply Mark. So a couple of questions.
When is distributed indexing going to be available on Trunk? Are
there docs on it now?
I think having Roles on the shard would scratch the itch here, because
as you said I could then include a role which indicated what to do
with this server.
My use case is actually for something outside of Solr. As of right
now we are not on the latest trunk (actually a few months back I
think) but could push to upgrade to it if the distributed indexing
code was available today, but management may still shoot that down
because of a short timeline. Suffice it to say that I'll be reading
this information by another application to handle distributed indexing
externally. The version that I'm working on requires that the
application be responsible for performing the distribution.
On Tue, Oct 4, 2011 at 12:05 PM, Mark Miller wrote:
> Because the distributed indexing phase of SolrCloud will not use
> replication, we have not really gone down this path at all.
>
> One thing we are considering is adding the ability to add various roles
> to each shard as hints - eg a shard might be designated a searcher and
> another an indexer.
>
> You might be able to piggy back on this to label things master/slave. A
> ZooKeeper aware replication handler could then use this information.
>
> There is nothing to stop you from adding this information to zookeeper
> yourself, using standard zookeeper tools - but just putting the
> information is only half the problem - something then needs to read it.
>
> - Mark Miller
> lucidimagination.com
> 2011.lucene-eurocon.org | Oct 17-20 | Barcelona
>
> On Oct 4, 2011, at 10:26 AM, Jamie Johnson wrote:
>
>> Ok, so I am pretty sure this information is not available. What is
>> the most appropriate way to add information like this to ZK? I can
>> obviously look for the system properties enable.master and
>> enable.slave, but that won't be fool proof since someone could put
>> this in the config file instead and not as a system property. Is
>> there a way to determine this quickly programatically without having
>> to go through all of the request handlers in the solrCore?
>>
>> On Mon, Oct 3, 2011 at 5:52 PM, Jamie Johnson wrote:
>>> Is it possible to determine if a solr instance is a master or a slave
>>> in replication terms based on the information that is placed in ZK in
>>> SolrCloud?
>>>
>
>
>
>
>
>
>
>
>
>
>
>
>>>
>>
>
Re: Determining master/slave from ZK in SolrCloud
so my initial test worked, this appeared in ZK now
roles=searcher,indexer
which I can use to tell if it should be used to write to or not. It
had fewer changes to other files as well
I needed to change
CloudDescriptor (add roles variable/methods)
CoreContainer (parse roles attribute)
ZKController (store roles in ZK)
and now what is in ZK is the following:
roles=searcher,indexer
node_name=hostname:8983_solr
url=http://hostname:8983/solr/
As I said this will meet my need, I can provide my changes back to the
JIRA referenced if this is what is expected from roles.
On Tue, Oct 4, 2011 at 12:45 PM, Jamie Johnson wrote:
> So I see this JIRA which references roles
>
> https://issues.apache.org/jira/browse/SOLR-2765
>
> I'm looking at implementing what Yonik suggested, namely in
> solrconfig.xml I have something like
>
> collection="${collection}" roles="searcher,indexer"/>
>
> these will be pulled out and added to the cloudDescriptor so they can
> be saved in ZK. Seem reasonable?
>
> On Tue, Oct 4, 2011 at 12:17 PM, Jamie Johnson wrote:
>> also as an FYI I created this JIRA
>>
>> https://issues.apache.org/jira/browse/SOLR-2811
>>
>> which perhaps should be removed if the roles option comes to life. Is
>> there a JIRA on that now?
>>
>> On Tue, Oct 4, 2011 at 12:12 PM, Jamie Johnson wrote:
>>> Thanks for the reply Mark. So a couple of questions.
>>>
>>> When is distributed indexing going to be available on Trunk? Are
>>> there docs on it now?
>>>
>>> I think having Roles on the shard would scratch the itch here, because
>>> as you said I could then include a role which indicated what to do
>>> with this server.
>>>
>>> My use case is actually for something outside of Solr. As of right
>>> now we are not on the latest trunk (actually a few months back I
>>> think) but could push to upgrade to it if the distributed indexing
>>> code was available today, but management may still shoot that down
>>> because of a short timeline. Suffice it to say that I'll be reading
>>> this information by another application to handle distributed indexing
>>> externally. The version that I'm working on requires that the
>>> application be responsible for performing the distribution.
>>>
>>>
>>> On Tue, Oct 4, 2011 at 12:05 PM, Mark Miller wrote:
Because the distributed indexing phase of SolrCloud will not use
replication, we have not really gone down this path at all.
One thing we are considering is adding the ability to add various roles to
each shard as hints - eg a shard might be designated a searcher and
another an indexer.
You might be able to piggy back on this to label things master/slave. A
ZooKeeper aware replication handler could then use this information.
There is nothing to stop you from adding this information to zookeeper
yourself, using standard zookeeper tools - but just putting the
information is only half the problem - something then needs to read it.
- Mark Miller
lucidimagination.com
2011.lucene-eurocon.org | Oct 17-20 | Barcelona
On Oct 4, 2011, at 10:26 AM, Jamie Johnson wrote:
> Ok, so I am pretty sure this information is not available. What is
> the most appropriate way to add information like this to ZK? I can
> obviously look for the system properties enable.master and
> enable.slave, but that won't be fool proof since someone could put
> this in the config file instead and not as a system property. Is
> there a way to determine this quickly programatically without having
> to go through all of the request handlers in the solrCore?
>
> On Mon, Oct 3, 2011 at 5:52 PM, Jamie Johnson wrote:
>> Is it possible to determine if a solr instance is a master or a slave
>> in replication terms based on the information that is placed in ZK in
>> SolrCloud?
>>
>>>
>>
>
Re: Determining master/slave from ZK in SolrCloud
So I see this JIRA which references roles https://issues.apache.org/jira/browse/SOLR-2765 I'm looking at implementing what Yonik suggested, namely in solrconfig.xml I have something like these will be pulled out and added to the cloudDescriptor so they can be saved in ZK. Seem reasonable? On Tue, Oct 4, 2011 at 12:17 PM, Jamie Johnson wrote: > also as an FYI I created this JIRA > > https://issues.apache.org/jira/browse/SOLR-2811 > > which perhaps should be removed if the roles option comes to life. Is > there a JIRA on that now? > > On Tue, Oct 4, 2011 at 12:12 PM, Jamie Johnson wrote: >> Thanks for the reply Mark. So a couple of questions. >> >> When is distributed indexing going to be available on Trunk? Are >> there docs on it now? >> >> I think having Roles on the shard would scratch the itch here, because >> as you said I could then include a role which indicated what to do >> with this server. >> >> My use case is actually for something outside of Solr. As of right >> now we are not on the latest trunk (actually a few months back I >> think) but could push to upgrade to it if the distributed indexing >> code was available today, but management may still shoot that down >> because of a short timeline. Suffice it to say that I'll be reading >> this information by another application to handle distributed indexing >> externally. The version that I'm working on requires that the >> application be responsible for performing the distribution. >> >> >> On Tue, Oct 4, 2011 at 12:05 PM, Mark Miller wrote: >>> Because the distributed indexing phase of SolrCloud will not use >>> replication, we have not really gone down this path at all. >>> >>> One thing we are considering is adding the ability to add various roles to >>> each shard as hints - eg a shard might be designated a searcher and another >>> an indexer. >>> >>> You might be able to piggy back on this to label things master/slave. A >>> ZooKeeper aware replication handler could then use this information. >>> >>> There is nothing to stop you from adding this information to zookeeper >>> yourself, using standard zookeeper tools - but just putting the information >>> is only half the problem - something then needs to read it. >>> >>> - Mark Miller >>> lucidimagination.com >>> 2011.lucene-eurocon.org | Oct 17-20 | Barcelona >>> >>> On Oct 4, 2011, at 10:26 AM, Jamie Johnson wrote: >>> Ok, so I am pretty sure this information is not available. What is the most appropriate way to add information like this to ZK? I can obviously look for the system properties enable.master and enable.slave, but that won't be fool proof since someone could put this in the config file instead and not as a system property. Is there a way to determine this quickly programatically without having to go through all of the request handlers in the solrCore? On Mon, Oct 3, 2011 at 5:52 PM, Jamie Johnson wrote: > Is it possible to determine if a solr instance is a master or a slave > in replication terms based on the information that is placed in ZK in > SolrCloud? > >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >
Re: Determining master/slave from ZK in SolrCloud
also as an FYI I created this JIRA https://issues.apache.org/jira/browse/SOLR-2811 which perhaps should be removed if the roles option comes to life. Is there a JIRA on that now? On Tue, Oct 4, 2011 at 12:12 PM, Jamie Johnson wrote: > Thanks for the reply Mark. So a couple of questions. > > When is distributed indexing going to be available on Trunk? Are > there docs on it now? > > I think having Roles on the shard would scratch the itch here, because > as you said I could then include a role which indicated what to do > with this server. > > My use case is actually for something outside of Solr. As of right > now we are not on the latest trunk (actually a few months back I > think) but could push to upgrade to it if the distributed indexing > code was available today, but management may still shoot that down > because of a short timeline. Suffice it to say that I'll be reading > this information by another application to handle distributed indexing > externally. The version that I'm working on requires that the > application be responsible for performing the distribution. > > > On Tue, Oct 4, 2011 at 12:05 PM, Mark Miller wrote: >> Because the distributed indexing phase of SolrCloud will not use >> replication, we have not really gone down this path at all. >> >> One thing we are considering is adding the ability to add various roles to >> each shard as hints - eg a shard might be designated a searcher and another >> an indexer. >> >> You might be able to piggy back on this to label things master/slave. A >> ZooKeeper aware replication handler could then use this information. >> >> There is nothing to stop you from adding this information to zookeeper >> yourself, using standard zookeeper tools - but just putting the information >> is only half the problem - something then needs to read it. >> >> - Mark Miller >> lucidimagination.com >> 2011.lucene-eurocon.org | Oct 17-20 | Barcelona >> >> On Oct 4, 2011, at 10:26 AM, Jamie Johnson wrote: >> >>> Ok, so I am pretty sure this information is not available. What is >>> the most appropriate way to add information like this to ZK? I can >>> obviously look for the system properties enable.master and >>> enable.slave, but that won't be fool proof since someone could put >>> this in the config file instead and not as a system property. Is >>> there a way to determine this quickly programatically without having >>> to go through all of the request handlers in the solrCore? >>> >>> On Mon, Oct 3, 2011 at 5:52 PM, Jamie Johnson wrote: Is it possible to determine if a solr instance is a master or a slave in replication terms based on the information that is placed in ZK in SolrCloud? >> >> >> >> >> >> >> >> >> >> >> >> >
Re: Determining master/slave from ZK in SolrCloud
Thanks for the reply Mark. So a couple of questions. When is distributed indexing going to be available on Trunk? Are there docs on it now? I think having Roles on the shard would scratch the itch here, because as you said I could then include a role which indicated what to do with this server. My use case is actually for something outside of Solr. As of right now we are not on the latest trunk (actually a few months back I think) but could push to upgrade to it if the distributed indexing code was available today, but management may still shoot that down because of a short timeline. Suffice it to say that I'll be reading this information by another application to handle distributed indexing externally. The version that I'm working on requires that the application be responsible for performing the distribution. On Tue, Oct 4, 2011 at 12:05 PM, Mark Miller wrote: > Because the distributed indexing phase of SolrCloud will not use replication, > we have not really gone down this path at all. > > One thing we are considering is adding the ability to add various roles to > each shard as hints - eg a shard might be designated a searcher and another > an indexer. > > You might be able to piggy back on this to label things master/slave. A > ZooKeeper aware replication handler could then use this information. > > There is nothing to stop you from adding this information to zookeeper > yourself, using standard zookeeper tools - but just putting the information > is only half the problem - something then needs to read it. > > - Mark Miller > lucidimagination.com > 2011.lucene-eurocon.org | Oct 17-20 | Barcelona > > On Oct 4, 2011, at 10:26 AM, Jamie Johnson wrote: > >> Ok, so I am pretty sure this information is not available. What is >> the most appropriate way to add information like this to ZK? I can >> obviously look for the system properties enable.master and >> enable.slave, but that won't be fool proof since someone could put >> this in the config file instead and not as a system property. Is >> there a way to determine this quickly programatically without having >> to go through all of the request handlers in the solrCore? >> >> On Mon, Oct 3, 2011 at 5:52 PM, Jamie Johnson wrote: >>> Is it possible to determine if a solr instance is a master or a slave >>> in replication terms based on the information that is placed in ZK in >>> SolrCloud? >>> > > > > > > > > > > > >
Re: Determining master/slave from ZK in SolrCloud
Because the distributed indexing phase of SolrCloud will not use replication, we have not really gone down this path at all. One thing we are considering is adding the ability to add various roles to each shard as hints - eg a shard might be designated a searcher and another an indexer. You might be able to piggy back on this to label things master/slave. A ZooKeeper aware replication handler could then use this information. There is nothing to stop you from adding this information to zookeeper yourself, using standard zookeeper tools - but just putting the information is only half the problem - something then needs to read it. - Mark Miller lucidimagination.com 2011.lucene-eurocon.org | Oct 17-20 | Barcelona On Oct 4, 2011, at 10:26 AM, Jamie Johnson wrote: > Ok, so I am pretty sure this information is not available. What is > the most appropriate way to add information like this to ZK? I can > obviously look for the system properties enable.master and > enable.slave, but that won't be fool proof since someone could put > this in the config file instead and not as a system property. Is > there a way to determine this quickly programatically without having > to go through all of the request handlers in the solrCore? > > On Mon, Oct 3, 2011 at 5:52 PM, Jamie Johnson wrote: >> Is it possible to determine if a solr instance is a master or a slave >> in replication terms based on the information that is placed in ZK in >> SolrCloud? >>
Re: Determining master/slave from ZK in SolrCloud
I'm putting this out there for comment.
Right now I'm in ZKControllers and changed register as follows:
public void register(SolrCore core, boolean forcePropsUpdate) throws
IOException,
and at line 479 I've added this
SolrRequestHandler requestHandler = core.getRequestHandler("/replication");
boolean master = false;
if(requestHandler != null && requestHandler instanceof ReplicationHandler){
ReplicationHandler replicationHandler =
(ReplicationHandler)requestHandler;
master = replicationHandler.isMaster();
}
props.put("replication.master", master);
I also modified CoreContainer and ReplicationHandler to support what I
have above. Does this seem a reasonable way to approach this?
Also to provide some history, I need this so I can programatically
determine which servers are masters and slaves and subsequently which
should be written to (for updates) and which should be queried.
On Tue, Oct 4, 2011 at 10:26 AM, Jamie Johnson wrote:
> Ok, so I am pretty sure this information is not available. What is
> the most appropriate way to add information like this to ZK? I can
> obviously look for the system properties enable.master and
> enable.slave, but that won't be fool proof since someone could put
> this in the config file instead and not as a system property. Is
> there a way to determine this quickly programatically without having
> to go through all of the request handlers in the solrCore?
>
> On Mon, Oct 3, 2011 at 5:52 PM, Jamie Johnson wrote:
>> Is it possible to determine if a solr instance is a master or a slave
>> in replication terms based on the information that is placed in ZK in
>> SolrCloud?
>>
>
Re: Determining master/slave from ZK in SolrCloud
Ok, so I am pretty sure this information is not available. What is the most appropriate way to add information like this to ZK? I can obviously look for the system properties enable.master and enable.slave, but that won't be fool proof since someone could put this in the config file instead and not as a system property. Is there a way to determine this quickly programatically without having to go through all of the request handlers in the solrCore? On Mon, Oct 3, 2011 at 5:52 PM, Jamie Johnson wrote: > Is it possible to determine if a solr instance is a master or a slave > in replication terms based on the information that is placed in ZK in > SolrCloud? >
Determining master/slave from ZK in SolrCloud
Is it possible to determine if a solr instance is a master or a slave in replication terms based on the information that is placed in ZK in SolrCloud?
