Disaster Recovery for Routes
This section describes procedures for disaster recovery failover and failback when routed persistence stores are in use. The information in this section assumes that you understand the previous sections concerning disaster recovery.
At a minimum, you must run FTL server processes at four different sites. The following describes how each site functions in the initial configuration:
-
Primary site: This site controls FTL configuration and offers messaging through one or more persistence clusters.
-
Disaster recovery site: This site connects to the primary site and serves as a standby for the configuration and messaging functions of the primary site. The persistence services at this site connect to persistence services at the primary site, serving as an asynchronous backup for the primary site persistence services.
-
Active satellite site: This site connects to the primary site to retrieve the FTL configuration. This site may offer messaging through one or more persistence clusters. The persistence services at this site may connect to the primary site or other active satellite sites for routing purposes.
-
Standby satellite site: This site connects to the primary site to retrieve the FTL configuration. The persistence services at this site connect to persistence services at the active satellite site, serving as an asynchronous backup for the active satellite of site persistence services.
You can run any number of satellite pairs (active and standby). There must be exactly one primary site and one disaster recovery site. All FTL realm configuration changes are made at the primary site.
For detailed FTL server YAML configuration files and FTL realm configuration files, see the sample files in: