Persistence Clusters

FTL servers run on dedicated host computers and can be organized in clusters. The persistence services cooperate in a persistence cluster. Persistent clusters replicate message data and acknowledgment data to ensure services continue to deliver messages to subscribers, even if some of the individual services become unavailable. An FTL server may run any number of persistence services. However, for good fault-tolerance, multiple persistence services in a given FTL server should not be members of the same persistence cluster. Each persistence cluster has one leader that is responsible for receiving messages and acknowledgments from clients and replicating them to other persistence services in the cluster. All client traffic is directed toward the leader.

For example, in the following diagram, there are three FTL servers with five persistence services in each server. There are five persistence clusters of three members each. Each persistence cluster has a leader to receive messages and acknowledgments and replicate them to other services in the persistence cluster. Each persistence cluster maintains a set of persistence stores. Persistence stores in different persistence clusters have different names. Replication of stores across the persistence cluster protects against hardware or network failures on a small scale. (However, this replication scheme cannot guarantee delivery after catastrophic failures, for example, simultaneous failure of all members of a cluster.)

A publisher publishes to a particular store at a particular persistence cluster, as determined by its endpoint. The message is retained by every durable in the store that is interested in the message (which might be none of them).

Administrators define any number of persistence clusters and services within the realm definition and monitor the health of a persistent cluster.

Durables in Persistence Clusters

Durables are created within a store at a particular persistence cluster when a subscriber (on an endpoint configured for that store) connects to that cluster. The durable exists only at that persistence cluster. However, identical durables may be created at all clusters by separate subscribers at each cluster.

Save and Load a Persistence Cluster State

You can save the state of a persistence service's store to a file on any persistence cluster after suspending the cluster. Suspending the cluster prevents sending and receiving messages until the cluster is restarted. See "Saving and Loading Persistence State" in TIBCO FTL Administration.