The companions in a high availability cluster must have their user information synchronized. Operations that affect the configuration of the companions are called cluster operations, and are usually initiated by sp_companion. Because the companions must be synchronized, clients performing cluster operations that affect the configuration of the node are only allowed to run in serial, not parallel. That is, only one client can perform a cluster operation at a time.
Before a client performs a cluster operation, it obtains a cluster-wide lock, which prevents any other client from performing a cluster operation at the same time. The cluster lock is not released until both companions are synchronized. If a client cannot obtain a cluster lock, its cluster operation fails. Even though the operations are performed in serial, there is no queue for the clients; you must resubmit the failed cluster operations.
You can also acquire a cluster lock if the cluster operation you are running requires a lock on the cluster.
Generally, you will never notice a cluster lock. They do not affect any other transactions that occur in the database, only cluster operations. However, if the client connection that holds the cluster lock fails during its cluster operation (for example, if you terminate a cluster operation using Control – c before it is finished). The client that failed leaves behind a lock that blocks the next client attempting to obtain a cluster lock.
Issue dbcc ha_admin to acquire or release cluster locks:
dbcc ha_admin server_name clusterlock [acquire | release]
For more information about dbcc ha_admin, see “dbcc Options for High Availability Systems”.
Figure 2-3 describes two companion servers to which four clients are connecting. All of them attempting to perform cluster operations:
Figure 2-3: Clients connecting for cluster operations
Client connections C1 and C2 simultaneously attempt to obtain a cluster-wide lock to perform a cluster operation.
Client C1 connects to MONEY1 first and receives the cluster-wide lock.
Client C2 cannot get a cluster-wide lock, so it cannot perform a cluster operation.
Clients C3 and C4 attempt to obtain a cluster-wide lock from PERSONEL1 while C1 is performing its cluster operation.
Clients C3 and C4 cannot obtain a cluster-wide lock because it is held by C1.
After client C1 is done with its cluster operation, it releases the cluster-wide lock.
Client connections C2, C3, and C4 inform the SA that they were not able obtain a cluster-wide lock. The SA can resubmit these client connections for their cluster operations after client C1 has released its cluster-wide lock.
