I agree we need to keep manual mode until SolrCloud is easier for small deploys.
With Zookeeper now supporting dynamic re-configuration (3.6+), and in the latest 3.7 release also officially supporting bootstrapping from Java (ZOOKEEPER-3874 <https://issues.apache.org/jira/browse/ZOOKEEPER-3874>) I think we have the building blocks necessary to support such automatic/managed cluster growth. Then running external ZK cluster would be an expert option! I'd rather prefer to get rid of ZK and embed something like Ratis (https://ratis.apache.org/) for consensus, but that is a much bigger effort and not reaistic short-term. Jan > 11. aug. 2021 kl. 13:39 skrev Eric Pugh <ep...@opensourceconnections.com>: > > For small setups I’ve used a single ZK and a single Solr node very > successfully, the operational benefits of all the SolrCloud API’s has been > fantastic. > > I’ve always thought that us having ZooKeeper as this “front and center” > requirement for SolrCloud was always a weird decision that would put off a > lot of folks. We don’t beat our potential users over the head with the fact > we use Jetty for example. It’s just part of the stack. > > The flow that Gus proposed should have been added to SolrCloud a long time > ago, how much easier would it have made all our lives! The entire existence > of ZooKeeper should be behind APIs and be an abstraction. We should do this > regardless of if deprecated standalone! > > Uwe, if we had what Gus proposed, but eliminate zk, would that map much more > to what you wanted? Here is my attempt at retelling the story that Gus told, > but to meet the goals of folks who might want to move to ES for ease: > > A) Start Node 1. > B) Start Node 2 telling it that Node 1 exists. node 2 comes up, joins network > and messages “at risk for split brain”. > C) Start Node 3 telling it that node 1 exists. node 1, node 2, node 3 all > under the covers are sharing state via ZK and messages “no risk for split > brain" > D) Node 4 - like node 2 but since we have optimum quorum doesn’t add to ZK > (under covers, hidden from user). > E) Node 5 - like node 3, but since we have optimum quorum doesn’t add to ZK > (under covers, hidden from user). > > > > > >> On Aug 11, 2021, at 7:15 AM, Uwe Schindler <u...@thetaphi.de >> <mailto:u...@thetaphi.de>> wrote: >> >> Hi, >> >> most of my customers prefer standalone mode and manual replication. A lot of >> setups, especially in Germany, are very >> >> Solr Cloud is only interesting to large customers that want to scale hugely. >> But from what I have seen, most of those have moved to Elasticsearch or >> Opensearch (see below). The biggest issue is always the stupidness of having >> to maintain a separate Zookeeper cloud, which adds more hardware/VMs to the >> game and makes the thing more complex. If you want to maintain up to 4 or 6 >> Solr nodes with one index and a few shards, the overhead by Zookeeper (you >> need 3 of them) is – sorry to say – unmaintainable. With Elasticsearch it’s >> easy to setup. No dedicated cloud/standalone mode. You just start a single >> node and test it. If it works fine, you start additional nodes to form a >> cloud. Plain simple. Config files are easy to handle, you need no ip >> addresses hardcoded into Zookeeper nodes, it just works. If you don’t want >> to make people move to Elasticsearch/Opensearch, make them happy with their >> fully controllable local master/slave mode. >> >> So my strong -1 to make cloud mode the default and deprecate standalone >> mode. Unless both is the same and works without a separate zookeeper >> cluster, I won’t change my vote. >> >> Uwe >> >> ----- >> Uwe Schindler >> Achterdiek 19, D-28357 Bremen >> https://www.thetaphi.de <https://www.thetaphi.de/> >> eMail: u...@thetaphi.de <mailto:u...@thetaphi.de> >> >> From: Gus Heck <gus.h...@gmail.com <mailto:gus.h...@gmail.com>> >> Sent: Tuesday, August 10, 2021 8:34 PM >> To: dev@solr.apache.org <mailto:dev@solr.apache.org> >> Subject: Re: SolrCloud Alone: Deprecate Standalone Mode >> >> Or to keep things fast without retaining all the checks, one could provide >> slow/fast modes for test, fast requiring a local zookeeper external to the >> tests, with the tests properly namespacing themselves... that does imply >> reworking some tests. >> >> Now that I say the above, it would be interesting if the some of the tests >> could (also optionally) properly isolate themselves within an externally >> running solr (probably started via cloud.sh with the latest edits. ... >> develop, cloud.sh, test manually, run tests against same I expect that there >> are still tests for which that makes no sense of course. This is probably a >> crazier idea than using an external zookeeper however, where zkChroot should >> be sufficient to isolate things I think... >> >> -Gus >> >> On Tue, Aug 10, 2021 at 2:22 PM David Smiley <dsmi...@apache.org >> <mailto:dsmi...@apache.org>> wrote: >>> Good call-out on perceived complexity due to running 3 ZK nodes. For many >>> small installations, honestly Solr's embedded ZK is fine. Also, again for >>> small installations, running ZK alongside Solr (same hardware) is fine. We >>> shouldn't needlessly shame users away from doing these things as if it's >>> irresponsible. There's a spectrum of demands on Solr from low to high. >>> Anyway, I suspect it's increasingly moot with more Docker & Kubernetes >>> being used to reduce the hassles of deploying any service (be it Solr or >>> whatever). This will only increase going forward. >>> >>> Even if ZK becomes the only mode, I expect many checks in our codebase that >>> conditionally check for ZK to remain. We want tests that don't care about >>> SolrCloud mode to be fast, and that means not running unnecessary things >>> like ZooKeeper. >>> >>> ~ David Smiley >>> Apache Lucene/Solr Search Developer >>> http://www.linkedin.com/in/davidwsmiley >>> <http://www.linkedin.com/in/davidwsmiley> >>> >>> >>> On Tue, Aug 10, 2021 at 12:23 PM Gus Heck <gus.h...@gmail.com >>> <mailto:gus.h...@gmail.com>> wrote: >>>> I've met several clients who really didn't want to manage zookeeper as an >>>> additional service (I've talked some into it anyway, but it was clearly a >>>> key reason they hadn't started/gone cloud). I think it would be far more >>>> palatable if it's all "part of solr", doesn't require plumbing the docs of >>>> some other project entirely, and requires neither requisitioning >>>> additional hardware nor service scripts, monitoring, support that isn't >>>> "solr" support... etc... then I think that alleviates some of the pain >>>> that folks in small sub-sections of moderate to large orgs feel at the >>>> idea of using cloud. These folks face long procurement cycles and >>>> disaster/recovery plans etc, despite often having team sizes under 20... >>>> or face having to educate large IT departments into handling deployments >>>> when they themselves are new (of course that's how some of them wind up >>>> hiring folks like me... but that's a barrier too since that has to be >>>> approved too). Also I've met folks who didn't understand that it was >>>> possible to have a 1 node "cluster" with zk on the same machine, and had >>>> the impression that 5 boxes (2 solr and 3 zk) were absolutely required to >>>> run cloud. Which it is of course for high availability with no SPOF, but >>>> it is not required if you don't need high availability. >>>> >>>> I think to sunset "user managed" we need to figure out how to self manage >>>> embedded zookeepers, most particularly setup for smaller orgs or lower >>>> traffic installs should look like: >>>> >>>> A) Start Node 1 with zk embedded ... if you only need one node, don't want >>>> high availability etc, done. >>>> B) Start Node 2 telling it the zk url for node 1. node 2 comes up, offers >>>> to participate in zk, but does not because that would make an even number >>>> C) Start Node 3 telling it the zk url for node 1. node 1 (node 2 hasn't >>>> started zk) node 3 offers to participate in zk, and now with 2 offers >>>> pending, both 2 and 3, get up to date on the current state and th join, >>>> now the embedded zk cluster is 3 nodes, not one, and no SPOF... as they >>>> grow... >>>> D) Node 4 - like node 2 but can use zk url of any of 1,2,3 >>>> E) Node 5 - like node 3, but can use zk url of any 1,2,3 >>>> >>>> Obviously, features for users to set a cap the size of zk clusters, don't >>>> need 49 nodes on 50 servers... , ensure they put their data in a >>>> convenient place that is well documented, document how to secure the >>>> inter-node connections, clarity in the admin UI of what nodes have zk etc. >>>> >>>> For this embedded zk use case we should document whatever the user needs >>>> to know so they don't have to sort through docs at an entirely different >>>> project not necessarily focused on the things solr users need. >>>> >>>> Certainly we would still advocate for a separate zk cluster for better >>>> performance/stability. In essence a supported mode with known >>>> limitations... True we have to support all THAT code instead, but the >>>> available feature set becomes consistent and a bazillion checks to see if >>>> we have zkStateReader (or some other sentinel for cloud mode) can >>>> disappear, so probably a net gain etc. >>>> >>>> On the flip side I"ve also had the thought that cluster state management >>>> should be pluggable such that if a better tool than zk, or merely an >>>> "already installed" tool is available solr could use it. Without careful >>>> thought everything I just said could take us in the opposite direction >>>> >>>> Maybe running zk embedded is "Solr Fog" mode :) >>>> >>>> On Mon, Aug 9, 2021 at 2:55 PM Houston Putman <houstonput...@gmail.com >>>> <mailto:houstonput...@gmail.com>> wrote: >>>>> I agree with David that the first step would be to make SolrCloud the >>>>> default mode. >>>>> I made a dev list thread about this a few months ago, but I think I >>>>> failed to respond at some point. >>>>> I will get back on that and address the >>>>> >>>>> I also really like Mike's idea that we enable very similar use cases with >>>>> embedded Zookeeper's, >>>>> if at all possible, to make the transition easy for users who want to >>>>> stay on the user-manager mode. >>>>> >>>>> Marcus, I think it would be a great idea to fix up the documentation to >>>>> make SolrCloud the first and most prominent mode advertised. >>>>> Never saw your original PR, but would love to give it a look if you >>>>> resuscitate it at some point. >>>>> >>>>> - Houston >>>>> >>>>> On Mon, Aug 9, 2021 at 2:48 PM David Smiley <dsmi...@apache.org >>>>> <mailto:dsmi...@apache.org>> wrote: >>>>>> Given that SolrCloud is not even the default mode, I think it is >>>>>> premature to deprecate standalone mode. Let's do this first and maybe >>>>>> consider deprecating standalone after some time? >>>>>> >>>>>> ~ David Smiley >>>>>> Apache Lucene/Solr Search Developer >>>>>> http://www.linkedin.com/in/davidwsmiley >>>>>> <http://www.linkedin.com/in/davidwsmiley> >>>>>> >>>>>> >>>>>> On Mon, Aug 9, 2021 at 1:58 PM Mike Drob <md...@mdrob.com >>>>>> <mailto:md...@mdrob.com>> wrote: >>>>>>> Could we simulate user managed replication with an embedded zookeeper >>>>>>> on the primary and pull replicas on the followers? >>>>>>> >>>>>>> On Mon, Aug 9, 2021 at 12:56 PM Jason Gerlowski <gerlowsk...@gmail.com >>>>>>> <mailto:gerlowsk...@gmail.com>> wrote: >>>>>>> > >>>>>>> > Hey Marcus, >>>>>>> > >>>>>>> > The places I've worked in the past have all used SolrCloud primarily >>>>>>> > so I can't speak to any specifics, but my impression from reading >>>>>>> > user-list traffic is that a sizable chunk of Solr's user base prefers >>>>>>> > "User-Managed" mode (formerly called "standalone"). Some because they >>>>>>> > don't want to manage a ZooKeeper cluster. Some because the >>>>>>> > replication model in 'user-managed' fits their needs better. Some I >>>>>>> > imagine just haven't bothered to update in many years. >>>>>>> > >>>>>>> > I'm absolutely sympathetic to efforts to streamline development and >>>>>>> > reduce collective debt, but it might be tough to displace such a big >>>>>>> > chunk of users. I'm curious what others think though. Maybe the >>>>>>> > proportion of 'user-managed' users out there is smaller than I >>>>>>> > imagine. >>>>>>> > >>>>>>> > Jason >>>>>>> > >>>>>>> > On Fri, Aug 6, 2021 at 11:59 PM Marcus Eagan <marcusea...@gmail.com >>>>>>> > <mailto:marcusea...@gmail.com>> wrote: >>>>>>> > > >>>>>>> > > Hello again, >>>>>>> > > >>>>>>> > > Has the time come for us to reduce scope to move faster and with >>>>>>> > > more focus? Even for those not in the cloud, SolrCloud has been the >>>>>>> > > undisputed performance and usability champ since version 8.0. In >>>>>>> > > version 9.0, I'd like to propose that the deciders in the community >>>>>>> > > deprecate standalone mode in favor of SolrCloud. >>>>>>> > > >>>>>>> > > There are a few drivers: >>>>>>> > > >>>>>>> > > We only need to support changes that impact SolrCloud going >>>>>>> > > forward. I know that this is hard to stomach. But by the time Solr >>>>>>> > > reaches version 10.0, everyone should have migrated to SolrCloud as >>>>>>> > > there is little reason to continue to run standalone. >>>>>>> > > The new features keep coming to SolrCloud, but not to standalone. >>>>>>> > > You can see in a few ways how I embarrassingly discovered this late >>>>>>> > > one night while trying out a PR. If not careful, users can >>>>>>> > > accidentally start Solr in standalone mode. Think of all the >>>>>>> > > features that they will see documented but not in their >>>>>>> > > environment. What a confusing user experience? >>>>>>> > > Last but certainly not least, the number of contributors to the >>>>>>> > > project, and the velocity of those contributions has dropped. . It >>>>>>> > > does not have to be that way, though. Two ways are for the >>>>>>> > > community to observe our push for modernization and improved user >>>>>>> > > experience. Simply eliminating the need to include the -c flag in >>>>>>> > > the start command would be a huge win for many engineers.We should >>>>>>> > > make life easier for our users as much as the maintainers here. We >>>>>>> > > can strive to make the upgrade process from 9 to 10 very simple. >>>>>>> > > >>>>>>> > > I tried to make one step in this direction last year by re-ordering >>>>>>> > > the README to show the Solr Cloud command before the standalone >>>>>>> > > command. I believe that patch died on the vine, but I would be >>>>>>> > > excited to revive it to document this effort when the time is >>>>>>> > > appropriate. >>>>>>> > > >>>>>>> > > Reason not to do it: >>>>>>> > > >>>>>>> > > Some large company out there might view this move as introducing >>>>>>> > > risk. I view the risk here as negligible but I welcome any >>>>>>> > > perspective there. >>>>>>> > > Some things I inevitably don't know. >>>>>>> > > >>>>>>> > > What do you all think? >>>>>>> > > >>>>>>> > > Thank you all for your voluntary contributions, >>>>>>> > > -- >>>>>>> > > Marcus Eagan >>>>>>> > > >>>>>>> > >>>>>>> > --------------------------------------------------------------------- >>>>>>> > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>>>>>> > <mailto:dev-unsubscr...@solr.apache.org> >>>>>>> > For additional commands, e-mail: dev-h...@solr.apache.org >>>>>>> > <mailto:dev-h...@solr.apache.org> >>>>>>> > >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>>>>>> <mailto:dev-unsubscr...@solr.apache.org> >>>>>>> For additional commands, e-mail: dev-h...@solr.apache.org >>>>>>> <mailto:dev-h...@solr.apache.org> >>>> >>>> >>>> -- >>>> http://www.needhamsoftware.com <http://www.needhamsoftware.com/> (work) >>>> http://www.the111shift.com <http://www.the111shift.com/> (play) >> >> >> >> -- >> http://www.needhamsoftware.com <http://www.needhamsoftware.com/> (work) >> http://www.the111shift.com <http://www.the111shift.com/> (play) > > _______________________ > Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | > http://www.opensourceconnections.com <http://www.opensourceconnections.com/> > | My Free/Busy <http://tinyurl.com/eric-cal> > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed > <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> > > This e-mail and all contents, including attachments, is considered to be > Company Confidential unless explicitly stated otherwise, regardless of > whether attachments are marked as such. >
