--- title: "Using multi-region failover" date: "2024-02-14T06:18:38+00:00" summary: "Ensure business continuity with Acquia's multi-region failover service. Learn how to implement hot cloud recovery, sync data across regions, and seamlessly switch between primary and secondary infrastructures during emergencies." image: type: "page" url: "/acquia-cloud-platform/using-multi-region-failover" id: "6e950f64-f595-4599-aefc-4c1e5cb1a6c5" --- Table of contents will be added Through Multi-Region Failover (MRF) , Acquia provides Continuity-as-a-Service using a hot cloud recovery model. With multi-region failover, your Production application has a cloned version of its full stack in a secondary failover region. In the event of a failure or substantial impairment in your primary region, you can switch your application immediately to the clone in the secondary region. Multi-region failover is available for Cloud Platform Enterprise applications as an add-on service at an extra cost. To use multi-region failover, you must also use a CDN service, such as [Edge](/acquia-cloud-platform/add-ons/edge). This is important to avoid an interruption in service; the CDN can continue to serve cached content while your application is switching over to the secondary region. Important Multi-region failover is only available for Cloud Platform Enterprise applications. For a list of incompatible features and products with multi-region failover, see [Using multi-region failover with other Acquia products](#multiregion-incompatible-products). Multi-region failover on Cloud Next ----------------------------------- Cloud Platform clones the entire production web layer, file system, and database configuration to a standby region. The system continuously synchronizes code, files, and database content so the secondary region matches your primary region. Under standard operating conditions, resources in the secondary region remain passive. When a failover occurs, the secondary infrastructure scales up to 100% of your primary environment's capacity to handle live production traffic. ### How it works ![Diagram of a multi-region web service architecture with active and passive regions, DNS/CDN, load balancers, and replication processes.](https://acquia.widen.net/content/4ehyw8nm4l/web/cloud-platform_multi-region-failover-architecture-1.png?w=720&v=16faf5cd-397d-4299-8cb7-e24e251a127f&itok=cvaaQPAZ) Important To initiate a failover on Cloud Next, you must contact Acquia Support. ### Key benefits Regional cloud outages can disrupt your digital experiences and risk business revenue. MRF protects your business continuity by meeting strict operational targets: * ****Minimize data loss:**** A Recovery Point Objective (RPO) of less than 1 minute ensures your secondary database and files stay up to date. * ****Restore services quickly:**** A Recovery Time Objective (RTO) of 30 minutes guarantees full application restoration when you have updated your routing. * ****Support modern technologies:**** MRF on Cloud Next upgrades your environment to the MySQL version currently supported on the Cloud Platform with zero scheduled downtime, which makes your application compatible with Drupal 11. ### Availability and requirements MRF on Cloud Next depends on specific subscription tiers, user roles, and technical architectures: * ****Acquia Cloud Elite subscribers:**** This feature is exclusive to Cloud Elite subscriptions. * ****Application Owners and Administrators:**** Only users with administrative roles can view the MRF status or authorize a failover sequence through Acquia Support. * ****Teams with external network control:**** To use MRF, you must have a CDN enabled and possess the access required to change your external DNS records during an outage. Multi-region failover on Cloud Classic -------------------------------------- When you choose multi-region failover for your Cloud Platform Enterprise application, Acquia duplicates your Production environment in a different region from your primary region. ### How it works ![cloud-platform\_multi-region-failover-architecture.png](https://acquia.widen.net/content/oxs0lmufxs/web/cloud-platform_multi-region-failover-architecture.png?v=44a27d9d-6171-4086-956e-d49d4949e0bd) For example, if your application is hosted in the _US-East_ region, your secondary application might be created in the _US-West_ region. The secondary infrastructure cluster is configured to receive the same code deployments as the primary cluster, so that it is always running the same code. In addition, multi-region failover uses database replication to keep the primary and secondary database infrastructure in sync in both the primary and secondary regions. This means that any changes to the database in either the primary or secondary region will immediately sync to the database infrastructure in the other region. During normal operations, your application continuously runs a special one-way `rsync` process on the primary region application, which ensures that any files added to the primary region are also sent to the infrastructure in the secondary (failover) region. The combination of the synced code, databases, and files means that the failover region and primary region are functionally identical. The main difference, aside from the location of the infrastructure, is that each region is assigned its own distinct Elastic IP (EIP) address. ### Identifying MRF applications  The system displays a Multi-Region Failover (MRF) badge only for Cloud Platform Enterprise applications with the MRF add-on active. This badge identifies applications that are configured for regional redundancy. The MRF badge appears in the following locations: * Application cards on Cloud Platform home page. * Application list items in the Applications list view. * Under the application name at the top of the _Environments_ page. The MRF badge confirms the following: * The application has a secondary infrastructure stack in a different region. * The secondary region stays in synchronization with the code, database, and files of the primary region. Important The MRF badge is informational only. It does not initiate a failover. To switch to the secondary region, follow the steps in the failover process. ### The failover process In the event of an emergency in your application’s primary region, the Acquia multi-region failover configuration ensures that there is an alternative functional version of your live production application. This might be an event that causes the primary hosting region to be, in part or in whole, impaired or inoperative in such a way that Acquia’s Support teams cannot restore full service in the primary region immediately or within a reasonable amount of time. The multi-region failover configuration should not to be used to reduce the impact of routine maintenance or upsizes, to mitigate the impact of high-traffic events if your primary region’s infrastructure reaches capacity, or to attempt to work around incidents where adverse code, file, or database changes have been deployed to your Production application. In the event of an emergency, you can begin the failover process at any time; you do not need Acquia’s assistance. If your application uses Acquia Edge CDN, you can request that Acquia Support assist with the failover process. In any case, you should notify Acquia as soon as possible, so that Acquia does not take any conflicting actions in addressing the emergency. To initiate the failover process, configure your application’s CDN settings to point to the Elastic IP address of the secondary region, instead of the primary region. You can find the Elastic IP addresses on the Domains page of the Cloud Platform interface. After the CDN changes take effect, requests to the application will be handled by infrastructure in the secondary region, instead of the primary region. Since the caches in the secondary region will be empty at first, performance may be slower immediately following failover until the caches rebuild. #### Cron and failover Cron jobs in Cloud Platform are set to run on infrastructure in the primary region. Upon failover, Acquia Support can edit cron jobs to run in the secondary region instead of the primary region. Cron jobs do not transfer over to infrastructure in the secondary region upon failover. For more information, see [Using scheduled jobs to maintain your application](/acquia-cloud-platform/manage-apps/cron). ### Operating while in failover While your application is being served from the secondary region, many common Cloud Platform workflow tasks may not function properly. The secondary region includes a clone of your Production environment, but not other environments (such as Development and Staging). Workflow tasks that are designed to facilitate communications between infrastructure in the same region won’t work between environments in different regions. In other cases, such as full or partial region-wide failures, tasks may fail because Acquia’s code repository or task management infrastructure in those regions are also impaired. Important For these reasons, while your application is operating in the secondary region, do not attempt any file or database copy, code commit, or code deployment tasks. ### The failback process After the emergency in the primary region has been resolved, you will need to restore your application to its previous configuration so that it is again served from the primary region. This process is called _failback_. Before initiating failback to the primary region, notify Acquia Support to confirm the date and time of the failback. At the time of the failback, Acquia will perform one final manual sync of the application’s files between the secondary and primary regions to ensure that there are no issues or inconsistencies. Acquia will then authorize you to proceed with the CDN failback to the primary region, pointing the CDN settings to the Elastic IP address of the primary region. If your application uses Acquia Edge CDN, you can request that Acquia Support assist with the failback. Similar to when your application first fails over to the secondary region, caches in the primary region may be stale at the time of failback, so site performance may be reduced while the caches rebuild. ### Multi-sites and multi-region failover Multi-region failover is available to Cloud Platform Enterprise subscribers with multi-site applications. However, this functionality is not supported for Cloud Platform Professional or Site Factory applications. In the event of a failover event, subscribers with applications using multiple databases must ensure that all Production sites on that application are failed over to the secondary region to prevent any risk of data loss after the failover, or as a result of the failback process. ### SSL and multi-region failover Applications configured for multi-region failover should only utilize the [standard](/acquia-cloud-platform/manage-apps/ssl#cloud-standard-and-legacy-certs) method for SSL certificate management. The legacy installation method is not supported for this configuration. ### Using the current Drupal version with multi-region failover Acquia is providing extended support for MySQL 5.6 until Cloud Next offers the multi-region failover functionality. Meanwhile, Cloud Platform customers can use the [current Drupal version](/service-offerings/guide/software-life-cycle#supported-drupal-version) with this functionality. However, certain features or modules in later versions of Drupal might require the database functionality introduced in MySQL 5.7. In this situation, such Drupal features or modules are unavailable until Acquia releases a newer version of the multi-region failover functionality in Cloud Next. Important Drupal 10.2 is compatible with multi-region failover with the [mysql56 module](https://www.drupal.org/project/mysql56). Using multi-region failover with other Acquia products ------------------------------------------------------ The following features and Acquia products are incompatible with multi-region failover configurations: * Cloud Platform Professional * Site Factory * Shield VPC * Secure VPN * Elastic Load Balancers (ELBs) (Legacy SSL install method) * Resilient Edge Clusters * Acquia Search * Node.js * Digital Asset Manager Further, no Acquia Marketing Cloud products support the multi-region failover functionality. All applications requiring any of these features or services must be architected to ensure that sites can continue to serve critical content without these features in the event of a regional impairment and failover. Testing the failover process ---------------------------- Acquia tests multi-region failovers during the setup process. After this functionality is in place, Acquia does not support any additional testing and will not provide assistance with failing infrastructure over or back in events unrelated to an emergency event in your primary region. Note Acquia’s multi-region failover feature utilizes MySQL 5.6 with Tungsten replication to maintain cross-region data syncing. Acquia routinely patches this version of MySQL as part of an extended support program, and will continue to patch it until Acquia releases a newer version of this feature in Cloud Next. Frequently Asked Questions -------------------------- * How is failover triggered?  Failover is a manual process. Automated failover through Content Delivery Network (CDN), without customer or Acquia intervention is out of scope. * What is the recommended frequency to test?  No strict limit exists for the frequency to test. Perform tests annually. Coordinate these tests with Acquia Support. * Do sites experience downtime during failover? Sites experience a brief interruption while DNS propagates and caches warm. Caches do not pre-warm in the secondary region. This interruption fits in the 30-minute Recovery Time Objective (RTO).  * How are secondary environments managed? Acquia provisions secondary environments. These environments do not display in the standard environment list. Customers interact with them only through the MRF tab on the Application page.