[
https://issues.apache.org/jira/browse/SOLR-583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600774#action_12600774
]
Jason Rutherglen commented on SOLR-583:
---------------------------------------
Node - instance of Solr webapp on a server
Cell - 1 master and 0 or more slaves
Merge service - The solr distributed search code that merges search results
from cells
A name service for Solr will allow efficient scaling beyond a single cell.
The name services are redundant with one master and multiple slaves.
One of the goals of the name service is to allow a solr.war and a set of name
service urls (perferably encoded in the war file) to be deployed on a server
with no further manual configuration. The index schema, multicore.xml,
solrconfig.xml and any other files should be downloaded from the name service.
When these files need to be updated they can be changed on the name service and
hopefully hot deployed to the receiving nodes.
Today there is usually a load balancer in front of a single cell. Using
distributed solr search this becomes costly and complex. The name service
eliminates the need for a load balancer for each cell. The merge service will
communicates the name service to know which cells and nodes are offline/online,
master/slave. The merge service keeps a synced in memory copy of the nodes
listed in the name service. Syncing happens by name initiated event
notifications. The load balancer would only need to be in front of the merge
service.
When a node first starts, it creates a uuid and saves it to solrhome in
nodeid.txt. The node then registers with the master name service. The node
waits to receive a cellid from the name service which it saves under
cellid.txt. The cellid can be assigned automatically or manually via the name
administration.
There needs to be a way to know which node of a cell should be the master. One
way to do this is use the highest segmentinfos generation number.
In production a common issue is a corrupted index going unknown until the user
sees an exception. With the name service, the corrupted index exception is
captured and reported to the name service which marks the node status as
offline. Subsequent requests do not go to that node.
The name database contains the node information containing the following
columns (nodeid, cellid, highestransactionid, status, role,
reportedmasternodeid, nodeurl). The highestransactionid is used for voting and
assertions that the current master should be the master and could be, for
example, the segmentinfos generation. The status is online or offline. The
role is master or slave. The reportedmasternodeid is who the node currently
thinks is master which is used for master/slave voting agreement. The nodeurl
is the URL to the node Solr administration UI.
The name administration UI provides tools for managing files to be deployed to
a node and a table of the nodes. The UI provides a unified view into the Solr
cluster and all the nodes and cells. In the future, the UI can show which
cells are hotter than others so that new nodes may be deployed to that cell.
Any other reportable information from nodes and cells may be centrally located
in the name service for centralized viewing.
An issue that needs discussion is how distributed updates work. One way to
solve this is to have a node return the cellid in each document with the
results. Subsequent updates to a document contain the cellid. The merge
service, on receiving the update, routes the call to the appropriate master
node of a cell.
> Name Service
> ------------
>
> Key: SOLR-583
> URL: https://issues.apache.org/jira/browse/SOLR-583
> Project: Solr
> Issue Type: New Feature
> Affects Versions: 1.3
> Reporter: Jason Rutherglen
>
> Coordinates distributed search servers. Central point of administration for
> a Solr cluster. Enables automatic master slave failover. Should use an open
> source SQL database engine.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
