This is what we do… We have a primary and backup indexer, and a fleet of repeaters. We have a method to detect if the primary indexer has gone down and direct the repeaters to the backup indexer.
—joe > On Mar 15, 2022, at 7:12 AM, Eric Pugh <ep...@opensourceconnections.com> > wrote: > > I am proposing Standalone Solr ;-) > > You are quite right that if the indexer goes offline, then you wouldn’t see > updates in your two separate Solrs…. However, assuming you aren’t in a > near real time situation where your application is broken if the updates > aren’t happening, then you would still be able to serve up search traffic. > > If you are really worried about the indexer going offline, then just have two > of them as well ;-). Depending on your load, you could just run two > indexers, one on each Solr as well. > > Using SolrCloud wouldn’t help you on High Availability of the indexer ;-) > > Eric > > >> On Mar 15, 2022, at 4:26 AM, Sam Lee <samlee...@yahoo.com> wrote: >> >> On 2022/03/14 12:19:10 Eric Pugh wrote: >>> Let me propose a slightly different approach ;-) >>> >>> Since you don’t need Solrcloud to support scaling needs, but instead >>> for redundancy, then I like to set things up where my indexer just >>> sends the updates to TWO SEPARATE single server Solr nodes. >> >> Are you suggesting to use Standalone Solr instead of SolrCloud? >> >> If I am understanding this correctly, you are suggesting to use three >> servers: one for indexing, and two for clients to query. Wouldn't >> there be downtime if the indexer goes offline? >> >> Thank you. > > _______________________ > 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. >
