User information for companion servers in a high availability cluster must be synchronized. Operations that affect the configuration of the companions are called cluster operations, and are usually initiated by sp_companion. Because companions must be synchronized, clients performing cluster operations that affect the configuration of the node are only allowed to run serially, not in 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 operations are performed in serial, there is no queue for the clients; you must resubmit the failed cluster operations.
A cluster lock may also be obtained if the cluster operation being run requires it.
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 before it is finished), the client that failed leaves behind a lock that blocks the next client from 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 1-3 describes two companion servers to which four clients are connecting. All of them are attempting to perform cluster operations:
Figure 1-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 obtain a cluster-wide lock, so it cannot perform a cluster operation.
Clients C3 and C4 attempt to obtain a cluster-wide lock from PERSONNEL1 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 finished with its cluster operation, it releases the cluster-wide lock.
Client connections C2, C3, and C4 inform the System Administrator that they cannot obtain a cluster-wide lock. The System Administrator can resubmit these client connections for their cluster operations after client C1 has released its cluster-wide lock.
