Open topic with navigation

# 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.

Figure 14: Persistent Clusters

## 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.

Did you find this helpful?

Yes No
Great!
Thanks for taking the time to give us some feedback.
Sorry about that

Why wasn't this helpful? (check all that apply)

Could not find what I was looking for
Instructions confusing or unclear
Instructions did not work

Want to tell us more?

Please select at least one option or provide details about the issue!!

Error occurred while submitting feedback.

Error2 occurred while submitting feedback.

TIBCO FTL® - Enterprise Edition

Copyright © 2009-2024. Cloud Software Group, Inc. All Rights Reserved.