For more information about cluster-level failover, including concepts, benefits, use cases, constraints, usage and working principles, see Cluster-level failover concepts.
tip
You should configure cluster-level failover only when the cluster contains sufficient resources to handle all possible consequences. Workload intensity on the backup cluster may increase significantly.
Connect your clusters to an uninterruptible power supply (UPS) unit to reduce the risk of unexpected power loss.
You can specify several backup clusters using a comma-separated list.
Note that: - The backup cluster is chosen in the sequence shown in the list. - If all backup clusters are available, the Pulsar client chooses the first backup cluster.
failoverDelay
N/A
Yes
The delay before the Pulsar client switches from the primary cluster to the backup cluster.
Automatic failover is controlled by a probe task: 1) The probe task first checks the health status of the primary cluster. 2) If the probe task finds the continuous failure time of the primary cluster exceeds failoverDelayMs, it switches the Pulsar client to the backup cluster.
switchBackDelay
N/A
Yes
The delay before the Pulsar client switches from the backup cluster to the primary cluster.
Automatic failover switchover is controlled by a probe task: 1) After the Pulsar client switches from the primary cluster to the backup cluster, the probe task continues to check the status of the primary cluster. 2) If the primary cluster functions well and continuously remains active longer than switchBackDelay, the Pulsar client switches back to the primary cluster.
checkInterval
30s
No
Frequency of performing a probe task (in seconds).
secondaryTlsTrustCertsFilePath
N/A
No
Path to the trusted TLS certificate file of the backup cluster.
This is an example of how to construct a Java Pulsar client to use controlled cluster-level failover. The switchover is triggered by administrators manually.
note
You can have one or several backup clusters but can only specify one.
Frequency of performing a probe task (in seconds).
urlProvider
N/A
Yes
URL provider service.
urlProviderHeader
N/A
No
urlProviderHeader is a map containing tokens and credentials.
If you enable authentication or authorization between Pulsar clients and primary and backup clusters, you need to provide urlProviderHeader.
Here is an example of how urlProviderHeader works.
Assume that you want to connect Pulsar client 1 to cluster A.
Pulsar client 1 sends the token t1 to the URL provider service.
The URL provider service returns the credential c1 and the cluster A URL to the Pulsar client.
The URL provider service manages all tokens and credentials. It returns different credentials based on different tokens and different target cluster URLs to different Pulsar clients.
note
The credential must be in a JSON file and contain parameters as shown.