Deployment Architecture

Question about the replication factor in searchhead clustering.

munang
Path Finder

Hello. I am a Splunk newbie.

I have a question about the replication factor in searchhead clustering.


Looking at the docs it says that search artifacts are only replicated for scheduled saved searches.

https://docs.splunk.com/Documentation/Splunk/9.1.2/DistSearch/ChooseSHCreplicationfactor

munang_0-1706615714919.png

 

I'm curious as to the reason and advantage of duplicating search artifacts only in this case.

And, then, in the case of real-time search, is it correct that search artifacts are not replicated and only remain on the local server?

In that case, in a clustering environment, member 2 should not be able to see the search results of member 1.
But I can view it by using the loadjob command in member2.

Then, wouldn’t it be possible to view real-time search artifacts as well?

Thank you

0 Karma
1 Solution

PickleRick
SplunkTrust
SplunkTrust

Real-time searches are eeeeeevil and generally should not be used at all. Also there's not much to replicate in case of a real-time search since... they occur real-time and if you tried to run it another time you'd be running it with another set of data.

But if you meant ad-hoc search - I think the assumption is that ad-hoc search are used interactively so that you're not probably gonna need the results in another session, called with loadjob by another person logged in to another SHC member. With scheduled search it's different because a quite common way to optimize load is to schedule separate searches asynchronously so that one search uses the results from the already-performed search.

So it's simply that in some cases it seems to make much more sense than in others.

View solution in original post

munang
Path Finder

@PickleRick 

Sorry for the late reply.

Thank you for the clear explanation. I understand!!! 

 

0 Karma

PickleRick
SplunkTrust
SplunkTrust

Real-time searches are eeeeeevil and generally should not be used at all. Also there's not much to replicate in case of a real-time search since... they occur real-time and if you tried to run it another time you'd be running it with another set of data.

But if you meant ad-hoc search - I think the assumption is that ad-hoc search are used interactively so that you're not probably gonna need the results in another session, called with loadjob by another person logged in to another SHC member. With scheduled search it's different because a quite common way to optimize load is to schedule separate searches asynchronously so that one search uses the results from the already-performed search.

So it's simply that in some cases it seems to make much more sense than in others.

Get Updates on the Splunk Community!

Earn a $35 Gift Card for Answering our Splunk Admins & App Developer Survey

Survey for Splunk Admins and App Developers is open now! | Earn a $35 gift card!      Hello there,  Splunk ...

Continuing Innovation & New Integrations Unlock Full Stack Observability For Your ...

You’ve probably heard the latest about AppDynamics joining the Splunk Observability portfolio, deepening our ...

Monitoring Amazon Elastic Kubernetes Service (EKS)

As we’ve seen, integrating Kubernetes environments with Splunk Observability Cloud is a quick and easy way to ...