Simplified Disaster Recovery

To use the simplified DR model, specify dr, rather than drfor and drto, in the FTL server yaml configuration file at both sites. See FTL Server Configuration Parameters.

The main difference between the classic and simplified DR models involves the availability of the primary site. Keep the following in mind:

• Whenever the primary site suffers a complete shutdown and restart (as opposed to a normal rolling upgrade/restart), it attempts to contact the DR site to ensure that the DR site has not been activated. (Otherwise, split-brain might occur.)

• If the primary site suffers a complete shutdown and restart, and the DR site is unreachable, the primary site does not accept client connections by default.

• You can override this behavior by specifying auto.init.primary.on.no.contact in the FTL server yaml configuration file.

• You can also run the activate_dr command at the primary site. In this case, the primary site is already activated; the command just forces the primary site to start accepting client connections.

Consider the following key choices:

• Whether you want FTL server to initialize the primary site automatically during first-time startup (when there is no state on disk). If you do, make sure you specify auto.init.primary.on.first.startup as described in Simplified Disaster Recovery: Setup. Otherwise, be ready to run the activate_dr command at the intended primary site using the FTL server web API or FTL administration tool (tibftladmin). See POST Cluster and FTL Administration Utility.

• Whether you want FTL server to initialize the primary site automatically following a complete shutdown and restart, even if the DR site is unreachable. If you do, make sure you specify auto.init.primary.on.no.contact as described in Simplified Disaster Recovery: Setup. Also, make sure you know which strategy you would use to avoid split-brain following an unplanned DR failover, as described in Simplified Disaster Recovery: Failback After Unplanned Failover. If not using auto.init.primary.on.no.contact, be ready to run the activate_dr command at the primary site using the FTL server web API or FTL administration tool (tibftladmin). See POST Cluster and FTL Administration Utility.

• Whether you want FTL to perform realm configuration updates automatically during DR failover and failback. If so, ensure that you specify --auto_config_update when invoking the activate_dr command during failover or failback. This flag can also be specified in the request body when invoking the web API. See POST Cluster and FTL Administration Utility. Otherwise, be prepared to use the FTL server GUI or web API to update the primary set of each persistence cluster in the FTL realm definition after activating a site. This choice applies to the following procedures:

  • Simplified Disaster Recovery: Unplanned Failover

  • Simplified Disaster Recovery: Failback after Unplanned Failover

  • Simplified Disaster Recovery: Planned Failover

  • Simplified Disaster Recovery: Failback after Planned Failover

Finally, if you need to enable DR on a pre-existing standalone deployment, see Simplified Disaster Recovery: Enable Disaster Recovery. You can also remove DR from an existing deployment; see Simplified Disaster Recovery: Disable Disaster Recovery. You can also move the DR site by performing the disable DR procedure, followed by the enable DR procedure.