What Happens When a Cache Host Fails

If a cache host fails (assuming there are still a sufficient number of cache hosts available to keep the cluster running) nothing changes for the cache-enabled application. The cache cluster re-routes requests for the object to the cache host that maintained the secondary copy of the object. Within the cluster, the secondary copies of all the primary objects are then elevated to become the new primary objects. Then, secondary copies of those new primary objects are distributed to other cache hosts across the cluster. Secondary objects on the cache host that failed are replaced by new secondary objects and distributed across the cluster. This process also applies to regions.

For the high availability feature to help insulate your application from the failure of a cache host, at least three cache hosts must be members of the cache cluster. This is due to a strong consistency requirement stating that there must always be two copies of a cached object or region in a high availability-enabled cache. In order to maintain two copies of a cache or region, a high availability-enabled cache requires at least two cache hosts to function.

For example, perhaps you have created a high availability-enabled cached named HACache in a three-server cache cluster as shown in the following table. Assume that SQL Server was configured to perform the cluster management role (so that this example does not need to consider the potential loss of lead hosts).

At T1, when there are three cache hosts available, two copies of cached objects or regions can be stored on one of three available servers. At T2, when one cache server fails, HACache continues to be available because there are still two cache hosts available to store the two copies of cached objects or regions. At T3, when the second cache host fails, HACache becomes unavailable. This is because there is no longer another cache host available to store the second copy of cached objects or regions.