Stopping replication?
Hello, and Help! We've just moved solr (3.3.0) to a new set of servers, and the slaves are not working. The new servers have the DNS cnames of the previous servers, and no configuration files have changed. The master shows index generation 1940, but slaves show generation 1. I have replicateAfter commit and startup defined, pollInterval is 60 seconds and I've tried "http://slave_host:port/solr/replication?command=fetchindex"; and "http://slave_host:port/solr/replication?command=enablepoll";. It is of note that the admin replication page for the master (http://slave_host:port/solr/admin/replication) shows a title "Solr Replication Master", but that same page on each of the slave servers shows "Solr Replication ". I seem to recall that the slaves USED TO say "Solr Replication Slave". I need to resolve the problem this is causing, and the simplest solution seems to me to just stop replication. How does one do that (or fix the problem I'm experiencing)? Your help is most welcomed and appreciated. Tim H -- View this message in context: http://lucene.472066.n3.nabble.com/Stopping-replication-tp3999272.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Stopping replication?
First thing: Are you absolutely certain that the slaves are pointing at the master? My first guess would be that somehow your slaves aren't talking to the master. Take a look at the log files on one of the slaves, you should see some information about the replication attempt, that would be good info to share. Second thing I'd try: take a test machine and point it at your master. First blow away the entire index (rm -rf /data/index) Make sure you get the index directory, not just the contents. See if that works. Third thing. It's vaguely possible that replication on the master is disabled. The same screen that had the HTTP commands on it also has some commands to insure that the master is willing to do replications. The logs on the master might help here too. If none of that makes any difference, could you post the relevant portions of the logs? Best Erick On Sun, Aug 5, 2012 at 7:04 AM, csscouter wrote: > Hello, and Help! We've just moved solr (3.3.0) to a new set of servers, and > the slaves are not working. The new servers have the DNS cnames of the > previous servers, and no configuration files have changed. The master shows > index generation 1940, but slaves show generation 1. I have replicateAfter > commit and startup defined, pollInterval is 60 seconds and I've tried > "http://slave_host:port/solr/replication?command=fetchindex"; and > "http://slave_host:port/solr/replication?command=enablepoll";. > > It is of note that the admin replication page for the master > (http://slave_host:port/solr/admin/replication) shows a title "Solr > Replication Master", but that same page on each of the slave servers > shows "Solr Replication ". I seem to recall that the slaves USED TO > say "Solr Replication Slave". > > I need to resolve the problem this is causing, and the simplest solution > seems to me to just stop replication. How does one do that (or fix the > problem I'm experiencing)? > > Your help is most welcomed and appreciated. > > Tim H > > > > -- > View this message in context: > http://lucene.472066.n3.nabble.com/Stopping-replication-tp3999272.html > Sent from the Solr - User mailing list archive at Nabble.com.
Re: Stopping replication?
Erick, Thank you for the courtesy of your reply. I was able to figure out the problem, and for the benefit of the list, I list the analysis. Judging by the caliber of those on this list, this is likely too basic for the interests of most, but newbies (among whom I still classify myself) might benefit. Here's what occurred: Recall that the version I'm using is 3.3. I don't know if these comments can extend to versions other than 3.3, but I suspect so. I noted in my initial "plea": /I seem to recall that the slaves USED TO > say "Solr Replication Slave"./ It turns out that is indeed the case, and > that was a clue that they weren't being recognized as slave servers. The > file solrconfig.xml contains the configuration setup for replication, > under the entry " </requestHandler>. A slave "knows" it's a slave by the following entry: true http://://replication 00:00:60 The key here is the line true. There is at least one "fancy" way to define "trueness" or "falseness" - by defining the value as a parameter, and passing the resolution to the parameter in to solr when it starts. The reason for using this technique is to allow a single solrconfig.xml file to be deployed to all servers running solr, and then configuring those servers as slaves or the master at the time the servers start. (The information on doing this is in the solr wiki documentation for Replication at http://wiki.apache.org/solr/SolrReplication#enable.2BAC8-disable_master.2BAC8-slave_in_a_node, incidentally). In my case, I'm running solr under WebLogic 10.3.2 application server. I had defined the line: true as: ${org.apache.solr.handler.enable.slave:false} in my solrconfig.xml, and had been starting the WebLogic managed servers with the parameter "-Dorg.apache.solr.handler.enable.master=false". Note that this parameter deals with the *master* and not the slave. This was working in my existing environment, and despite the fact that no "-Dorg.apache.solr.handler.enable.slave=true" parameter was being passed in from WebLogic, the slaves were able to recognize themselves as slaves. In the new WebLogic environment, this was no longer the case. I don't know why at this point. To solve the problem for the short term, I created a separate file for the slave servers that bypassed the whole parameter-resolution mechanism by defining that line under the slave configuration in its solrconfig.xml as: true That, of course, now leaves me with 2 solrconfig.xml files - one for the master server, and one for the slave servers. My bottom line is that at least it's now working, people are not being impacted, and I can troubleshoot the underlying issue at a more leisurely pace. Hope this helps someone, somewhere. Erick, thanks for taking an interest. Tim Hibbs -- View this message in context: http://lucene.472066.n3.nabble.com/Stopping-replication-tp3999272p3999445.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Stopping replication?
Erick, Thank you for the courtesy of your reply. I was able to figure out the problem, and for the benefit of the list, I list the analysis. Judging by the caliber of those on this list, this is likely too basic for the interests of most, but newbies (among whom I still classify myself) might benefit. Here's what occurred: Recall that the version I'm using is 3.3. I don't know if these comments can extend to versions other than 3.3, but I suspect so. I noted in my initial "plea": /I seem to recall that the slaves USED TO > say "Solr Replication Slave"./ It turns out that is indeed the > case, and that was a clue that they weren't being recognized as slave > servers. The file solrconfig.xml contains the configuration setup for > replication, under the entry " </requestHandler>. A slave "knows" it's a slave by the following entry: true http://://replication 00:00:60 The key here is the line true. There is at least one "fancy" way to define "trueness" or "falseness" - by defining the value as a parameter, and passing the resolution to the parameter in to solr when it starts. The reason for using this technique is to allow a single solrconfig.xml file to be deployed to all servers running solr, and then configuring those servers as slaves or the master at the time the servers start. (The information on doing this is in the solr wiki documentation for Replication at http://wiki.apache.org/solr/SolrReplication#enable.2BAC8-disable_master.2BAC8-slave_in_a_node, incidentally). In my case, I'm running solr under WebLogic 10.3.2 application server. I had defined the line: true as: ${org.apache.solr.handler.enable.slave:false} in my solrconfig.xml, and had been starting the WebLogic managed servers with the parameter "-Dorg.apache.solr.handler.enable.master=false". Note that this parameter deals with the *master* and not the slave. This was working in my existing environment, and despite the fact that no "-Dorg.apache.solr.handler.enable.slave=true" parameter was being passed in from WebLogic, the slaves were able to recognize themselves as slaves. In the new WebLogic environment, this was no longer the case. I don't know why at this point. To solve the problem for the short term, I created a separate file for the slave servers that bypassed the whole parameter-resolution mechanism by defining that line under the slave configuration in its solrconfig.xml as: true That, of course, now leaves me with 2 solrconfig.xml files - one for the master server, and one for the slave servers. My bottom line is that at least it's now working, people are not being impacted, and I can troubleshoot the underlying issue at a more leisurely pace. Hope this helps someone, somewhere. Erick, thanks for taking an interest. Tim Hibbs -- View this message in context: http://lucene.472066.n3.nabble.com/Stopping-replication-tp3999272p3999447.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Stopping replication?
Thanks for wrapping that up. Erick On Mon, Aug 6, 2012 at 2:52 PM, csscouter wrote: > Erick, > > Thank you for the courtesy of your reply. > > I was able to figure out the problem, and for the benefit of the list, I > list the analysis. Judging by the caliber of those on this list, this is > likely too basic for the interests of most, but newbies (among whom I still > classify myself) might benefit. Here's what occurred: > > Recall that the version I'm using is 3.3. I don't know if these comments can > extend to versions other than 3.3, but I suspect so. > > I noted in my initial "plea": /I seem to recall that the slaves USED TO >> say "Solr Replication Slave"./ It turns out that is indeed the >> case, and that was a clue that they weren't being recognized as slave >> servers. The file solrconfig.xml contains the configuration setup for >> replication, under the entry "> </requestHandler>. A slave "knows" it's a slave by the following entry: > > > true > http://:/ 'apache-solr-3.3.0'>/replication > 00:00:60 > > > The key here is the line true. There is at least > one "fancy" way to define "trueness" or "falseness" - by defining the value > as a parameter, and passing the resolution to the parameter in to solr when > it starts. The reason for using this technique is to allow a single > solrconfig.xml file to be deployed to all servers running solr, and then > configuring those servers as slaves or the master at the time the servers > start. (The information on doing this is in the solr wiki documentation for > Replication at > http://wiki.apache.org/solr/SolrReplication#enable.2BAC8-disable_master.2BAC8-slave_in_a_node, > incidentally). > > In my case, I'm running solr under WebLogic 10.3.2 application server. I had > defined the line: > > true > > as: > > ${org.apache.solr.handler.enable.slave:false} > > in my solrconfig.xml, and had been starting the WebLogic managed servers > with the parameter "-Dorg.apache.solr.handler.enable.master=false". Note > that this parameter deals with the *master* and not the slave. This was > working in my existing environment, and despite the fact that no > "-Dorg.apache.solr.handler.enable.slave=true" parameter was being passed in > from WebLogic, the slaves were able to recognize themselves as slaves. In > the new WebLogic environment, this was no longer the case. I don't know why > at this point. > > To solve the problem for the short term, I created a separate file for the > slave servers that bypassed the whole parameter-resolution mechanism by > defining that line under the slave configuration in its solrconfig.xml as: > > true > > That, of course, now leaves me with 2 solrconfig.xml files - one for the > master server, and one for the slave servers. My bottom line is that at > least it's now working, people are not being impacted, and I can > troubleshoot the underlying issue at a more leisurely pace. > > Hope this helps someone, somewhere. Erick, thanks for taking an interest. > > Tim Hibbs > > > > -- > View this message in context: > http://lucene.472066.n3.nabble.com/Stopping-replication-tp3999272p3999447.html > Sent from the Solr - User mailing list archive at Nabble.com.