This page is meant as a template for writing a SIP. To create a SIP choose Tools->Copy on this page and modify with your content and replace the heading with the next SIP number and a description of your issue. Replace anything in italics with your own description.
Status
Current state: Under Discussion
Discussion thread: https://lists.apache.org/thread.html/r186364d4d22a6301887b54023cb3db48a5324f197590a3b3e95535fd%40%3Cdev.solr.apache.org%3E
JIRA: here (<- link to https://issues.apache.org/jira/browse/SOLR-XXXX)
Jira | ||||||
---|---|---|---|---|---|---|
|
Released: <Solr Version>
Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast). Confluence supports inline comments that can also be used.
...
Many organizations are frustrated with Solr Cloud deployments due to the perceived cost of managing a separate, dedicated Apache ZooKeeper ensemble. We can ameliorate this complexity by running our own embedded Zookeeper ensemble, based on on
Jira | ||||||
---|---|---|---|---|---|---|
|
...
We will need to expose additional ports from Solr nodes for ZK functionality. This will likely include the ZK secureClientPort
, and possibly the serverPort
, electionPort
and , Admin port and others.
Proposed Changes
There are several phases to accomplishing what we would need to do.
...
Compatibility, Deprecation, and Migration Plan
Existing users will be able to continue to run Solr Cloud with an external ZooKeeper quorum.
Major Risks
Zookeeper services launched this way may be subject to Solr availability - if the server is exhausted from too many queries or bad queries then that may adversely impact the health of the whole cluster rather than causing isolated failure on given replicas. This should be mitigated by offering multiple ZK services in a quorum that can tolerate individual node failure, but may be enough motivation to use a larger default quorum size of 5 or 7 members instead of the minimal 3 node setup.
Security considerations
When running our own ZK services, the security of ZK becomes our responsibility instead of being something that we can delegate. The ZK Servers that we start should be secure by default using available authentication methods and practices.
...
[ TBD ]
Rejected Alternatives
- Continue to launch embedded ZK process the same way that we do now. This is an unattractive proposal because we will be tied to ZK internals which are subject to change and not part of their public APIs.
bin/solr -cloud mode should launch a local ZK in its own process using zkcli's runzk option (instead of embedded in the first Solr process)Jira server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key SOLR-7099
Simple script to start external ZookeeperJira server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key SOLR-7074
Standalone solr as *two* applications -- Solr and a controlling agentJira server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key SOLR-6734