You're right; there's no such thing as a "search affinity = disabled" switch.
However in splunk 6.3+ there is a supported way to turn it off, though, by indeed setting your search heads to a site that doesn't exist in your indexer cluster.
Modify your (search head) site (in $SPLUNK_HOME/etc/system/default/server.conf) to site=site0 to "disable" search affinity.
You can read all about it here: http://docs.splunk.com/Documentation/Splunk/6.3.0/DistSearch/DeploymultisiteSHC
Did try this myself, and works like a charm. Away is the latency for synchronization between sites. All you have to do is edit the site=site0 in $SPLUNK_HOME/etc/system/default/server.conf.
Don't forget to restart your search heads.
one solution I was told should work is to create a specific site id for your search heads
this way, every indexers appears in a remote site and all are used, which is in fact like having disabled search affinity.
I should be able to validate it in the future but I'm interested if anybody already did it that way.
indirectly but from a thrusworthy source. I don't see why it would not be supported as it's just a multisite splunk deployment with some thinking on top of it.
I will use this config but haven't yet been able to test it yet for mainly planning reasons.
Edit: Not quite correct, apparently 😞
You must explicitly specify the sites that require search affinity.
I'd say you get no search affinity if you don't explicitly specify any site in your site rep/search factors... for example, if you have three sites and want a copy in every site but no search affinity you'd specify this:
As opposed to the search affinity for everyone version:
origin:1, site1: 1, site2: 1, site3: 1, total: 3
This isn’t quite correct.
Search affinity is automatically set whenever a site has a searchable copy. There are two ways to get a site to have searchable copies of a bucket:
1 explicit: site_search_factor: … site2:1 …
This explicitly sets a searchable copy onto site2, so that a search with site2 will get all events from indexers of site2 (since site2 contains a full set of searchable buckets)
2 implicit: site_search_factor: origin:1 total:3 and 3 sites total
Since we have 3 sites, and total set to ‘3’, we will spread out 3 copies amongst 3 sites, so that each site will have a searchable copy. This means that all sites will have search affinity
Also see http://docs.splunk.com/Documentation/Splunk/6.2.0/Indexer/Sitereplicationfactor#What_is_a_site_repli..., the section that starts with "Because the total value can be greater” ...
Will update the docs with regards to this shortly...