We are using solr.SynonymFilterFactory with synonyms.txt in Solr during querying. I realized that there is an error in synonyms.txt, corrected it and uploaded the new file. I can see the modified synonyms.txt from Admin. But it looks like the queries are still using the old synonyms.txt. I am executing test queries from Admin with debugQuery=true and can see the synonyms getting used. How can this be fixed? It is a production environment with 3 nodes using zookeeper for management.
You'll need to reload your core for the changes to take effect.
In a single-node Solr you can do that from the Admin page: go to Core Admin, select your core, and hit Reload. This will slow down some queries but it shouldn't drop queries or connections.
You can also reload the core via the API:
curl 'http://localhost:8983/solr/admin/cores?action=RELOAD&core=your-core'
I am not sure how this works on an environment with 3 nodes, though.
Related
I am new to solr search, i have completed a simple search.
Now I want to index documents directly from Database and want set scheduler or trigger for updating index when there is any change in DB.
I know that I can do it with DataImportHandler but can't understand its flow.
can you help me that from which steps I should have to start this process?
or can anyone just give me pointers to do this ??
I want to do this all things using SolrJ client.
This task requires many parts to work together. Work through https://wiki.apache.org/solr/DataImportHandler
DataImportHandler is a Solr component, which means that it runs inside the Solr instance. All you have to do is configure Solr and than run the DHI through the Dataimport Screen.
On the other hand SolrJ is an API that makes it easy for Java applications to talk to Solr. So you can write your own applications that create, modify, search and delete documents to Solr.
try to do simple edit and delete function on button click event and
send the id with that url in servlet and do your jdbc opertaion
after that successfully commited, call your data import command from solrj and redirect it to your index page
thats it.
I am using Apache Solr 6.5 with Query Elevation Component (/elevate endpoint) to support elevation of particular documents in my queries.
I am using elevate.xml file in
<instanceDir>/conf/<config-file>
directory. However on production server (Solr configured as cloud with zookepper to maintain configuration) changes in the elevate.xml are not loaded. To check if it works, I just query the elevated phrase and as a result I get elevated documents from previous version of elevate.xml.
Of course I am restarting all Solr cloud instances after loading new version of elevate.xml and updated file is visible in the Solr's Admin UI files section (of the particular core of course).
The query I am using to test results, to prove that I am not using stardard /query component:
/elevate?df=name&fl=id,name,[elevated]&indent=on&q=heart&wt=json
What should I do to actually tell Solr that the new elevate.xml was loaded? That works fine on my development standalone configuration of Solr (not cloud one) after the solr service is restarted, the documents are elevated by updated elevate.xml file.
You should be doing this:
upload the elevate.xml file to zookeeper as explained here
reload the collection with the RELOAD collection api, no need to restart Solr
Ok I think I figured it out. The problem was with a directory in which elevate.xml file was anticipated by Solr.
The documentation states (as for 6.5.0 version)
config-file
Path to the file that defines query elevation.
This file must exist in <instanceDir>/conf/<config-file> or <dataDir>/<config-file>.
In my dev configuration that was true for both cases (the file was read either from conf or data directory). However on production (in cloud environment with external zooKeepers) the file was read from the root directory of a core (aka collection), where also solrconfig.xml and schema.xml exists.
Probably it has some explanation and it's just data dir itself, but since I don't know how to check what are values of instanceDir and dataDir variables, the documentation was misleading for me.
I hope it helps other Solr adepts.
We have a cluster of standalone Solr cores (Solr 4.3) for which we had built some custom plugins. I'm now trying to prototype converting the cluster to a Solr Cloud cluster. This is how I am trying to deploy the cores (in 4.7.2).
Start solr with zookeeper embedded.
java -DzkRun -Djetty.port=8985 -jar start.jar
upload a config into Zookeeper (same config as the standalone cores)
zkcli.bat -zkhost localhost:9985 -cmd upconfig -confdir myconfig -confname myconfig
Create a new collection (mycollection) of 2 shards using the Collections API
http://localhost:8985/solr/admin/collections?action=CREATE&name=mycollection&numShards=2&replicationFactor=1&maxShardsPerNode=2&collection.configName=myconfig
So at this point I have two shards under my solr directory with the appropriate core.properties
But when I go to http://localhost:8985/solr/#/~cloud, I see that the two shards' status is "Down" when they are supposed to be active by default.
And when I try to index documents in them using SolrJ (via CloudSolrServer API) , I get the error "No live SolrServers available to handle this request". I restarted Solr but same issue.
private CloudSolrServer cloudSolr;
cloudSolr = new CloudSolrServer(zkHOST);
cloudSolr.setZkClientTimeout(zkClientTimeout);
cloudSolr.setDefaultCollection(collectionName);
cloudSolr.connect();
cloudSolr.add(doc)
What am I doing wrong? I did a lot of digging around and saw an old Jira bug saying that Solr Cloud shards won't be active until there are some documents in the index. If that is the reason, that's kind of like a catch-22 isn't it?
So anyways, I also tried adding some test documents manually and committed to see if things improved. Now on the shard statistics page, it correctly gives me the Numdocs count but when I try to query it says "no servers hosting shard". I next tried passing in shards.tolerant=true as a query parameter and search, but no cigar. It says 0 documents found.
Any help would be appreciated. My main objective is to rebuilt the old standalone cores using SolrCloud and test to see if our custom requesthandlers still work as expected. And at this point, I can't index documents inside of the 4.7 Solr Cloud collection I have created.
Thanks and Regards
I am using Solar 4.6 and changed something inside schema.xml. In order to update schema.xml inside my core I used zkcli. Which works fine and I am able to see the modified schema.xml inside the Solr Admin GUI under cloud\tree\config\foobar\schema.xml.
But after calling
http://localhost:8983/solr/admin/collections?action=RELOAD&name=foobar and
http://localhost:8983/solr/admin/cores?action=RELOAD&name=foobar,
the old schema.xml was still in the core named foobar.
Your 2nd HTTP request to the Core API is wrong. Change name to core:
http://localhost:8983/solr/admin/cores?action=RELOAD&name=foobar should be
http://localhost:8983/solr/admin/cores?action=RELOAD&core=foobar.
http://archive.apache.org/dist/lucene/solr/ref-guide/apache-solr-ref-guide-4.6.pdf (page 277)
RELOAD
The RELOAD action loads a new core from the configuration of an existing, registered Solr core. While the new core is initializing, the existing one
will continue to handle requests. When the new Solr core is ready, it takes over and the old core is unloaded.
This is useful when you've made changes to a Solr core's configuration on disk, such as adding new field definitions. Calling the RELOAD action
lets you apply the new configuration without having to restart the Web container. However the Core Container does not persist the SolrCloud
solr.xml parameters, such as solr/#zkHost and solr/cores/#hostPort, which are ignored.
http://localhost:8983/solr/admin/cores?action=RELOAD&core=core0
The RELOAD action accepts a single parameter, core, which is the name of the core to be reloaded.
see also https://cwiki.apache.org/confluence/display/solr/CoreAdmin+API#CoreAdminAPI-RELOAD
You have to reload your cores after giving it a new schema.
Replace name with core in your query as:
/solr/admin/cores?action=RELOAD&**core**=yourcorename
For example
http://localhost:8983/solr/admin/cores?action=RELOAD&core=foobar
I'm following this tutorial on setting up django-haystack and solr: http://django-haystack.readthedocs.org/en/latest/tutorial.html
I hit a stumbling block here:
If you’re using the Solr backend, you have an extra step. Solr’s
configuration is XML-based, so you’ll need to manually regenerate the
schema. You should run ./manage.py build_solr_schema first, drop the
XML output in your Solr’s schema.xml file and restart your Solr
server.
Where is my schema.xml file located? It says it should in the Solr home directory and the .conf folder. But where is the Solr home directory, and/or how do I configure its location?
The solr home is the place where you can find your schema.xml and solrconfig.xml, as well as some other files depending on the text analysis you're using (dictionaries for stemming, stopwords etc.), and where your index gets created by default.
There are a couple of ways to configure the solr home, since it is located outside of the servlet container:
solr.solr.home java system property (most used one)
java:comp/env/solr/home for JNDI lookup
You can either check your servlet container configuration or go to the Solr admin page http://host:port/solr/admin, which prints out the actual solr home location together with other information about the solr instance running.
First check whether your Solr instance is working.
Got to -> http://localhost:8983/solr
If you can see a Solr web panel you have a live Solr instance.
Now go to Java Properties
Here you will see the the variables. This is where you can find the home DIRs
Note schema is now managed. If you want to override this you will have to hack it a bit. check here