Resolving issues with Search Query component when the server hosting the query component go off line and cannot be restored.

Resolving issues with Search Query component when the server hosting the query component go off line and cannot be restored.

I suspect that this is set to 2 (the default), which would cause problems if one of the Query Components were not available.

1.       Verify  the current value for MinimumReadyQueryComponentsPerPartition using the following shell command :

$ssa = Get-SPEnterpriseSearchServiceApplication "Your Search Service Application Name"
$ssa.MinimumReadyQueryComponentsPerPartition

·         This property defines the minimum number of the query components used in each index partition

·         The value was currently set to 2 (the default value)

o        When the query server in ATT-2 was taken offline, the farm only had 1 query component available for this index partition (e.g. which was below the ‘Minimum’ value)

o        Secondly, during a crawl, the crawler will attempt to propagate to the query components

§         With only 1 query component available and a ‘Minimum’ of 2 required, the propagation could not complete – making the crawl appear hunged ( crawl stuck on running )

§         This will also apparently put the query in a state that prevented queries from completing

2.       Updated the value for MinimumReadyQueryComponentsPerPartition using the following:
$ssa.MinimumReadyQueryComponentsPerPartition = 1

$ssa.update()

·         Upon updating, the query component from the offline server was no longer present in the UI

3.       We then removed the inactive query topology using:

$ssa | Get-SPEnterpriseSearchQueryTopology

$oldTopo = Get-SPEnterpriseSearchQueryTopology -identity [Id-GUID-value-for-inactive-qTopo] -SearchApplication $ssa

$oldTopo | Remove-SPEnterpriseSearchQueryTopology

4.       When we attempted to remove the Query topology in ‘Deactivating’ state, it failed because it was not inactive

o        We attempted to use $oldTopo.cancelActivate(), but this made no difference

o        Attempting to stop the currently running crawl also made no difference

5.        We overcame the pinned crawl and deactivating query component by resetting the index

o        Afterwards, the ‘Deactivating’ Query topology went to an ‘Inactive’ state, which allowed it to then be removed

6.       We were then  able to start a full crawl

I also tested if having 4 query components (e.g. two index partitions with Query Components 1 & 2m on ServerA and Query Components 1m & 2 on ServerB) made any difference, but the crawl also “hung” waiting for query components in my test. Given the definition for this parameter (“This property defines the minimum number of the query components used in each index partition”), this is expected.

Also, in my test, the Query components on the server I took offline (e.g. I simply paused my VM hosting this component) were not marked as Offline or Disabled even after setting this ‘Minimum’ value. Therefore, when I started my crawl after pausing this server, the crawl appeared to hang. However, I was able to manually disable the Query components on this offline server by using the following PowerShell (it’s also worth noting that this took effect immediately – without cloning/activating a topology – and it also took affect during an active crawl):

$qTopo = $ssa | Get-SPEnterpriseSearchQueryTopology -active

$QCs = Get-SpEnterpriseSearchQueryComponent -QueryTopology $qTopo

$QCs | format-list

   #using the IDs of the Query Components in this output

#i entered the Id to the shell identity below

$p2QC = Get-SpEnterpriseSearchQueryComponent -QueryTopology $qTopo -identity 111-111-111-111

$p2QC.setOffline()

   #repeat for any Query Component in the now-offline data center