Disaster/Recovery (DR) for the Enterprise
You know that having a robust DR strategy is critical for your business, as unplanned (or even planned) down time can have a huge financial impact on the enterprise, while also eroding customer confidence in your products and services. Unexpected outages will happen at some point, as in March of this year when an entire datacenter in Europe went offline due to a fire. This was not a simple outage, but rather an extended period of time of being completely offline.
We do have a customer using the datacenter that had the fire, and failover was a simple and smooth process with Tungsten Cluster. In times of a disaster, failover (and eventual failback) needs to be fast and easy. Working out the details of failover when disaster happens is NOT going to produce the desired result and thus we advocate testing your DR plan regularly.
InnoDB Cluster with DR
If you do a search for “InnoDB Cluster with DR,” you’ll get quite a few hits with blogs and articles about implementing DR with InnoDB Cluster. The articles generally describe how it’s not advisable to deploy a cluster with nodes over a WAN due to high latencies of WAN’s and group replication. Instead, it’s advised to use native MySQL asynchronous replication to replicate to a standalone MySQL database in another region or datacenter.
After doing this, the articles state that you now have DR. But, is this really considered true DR? I would say this is not DR, but rather simply creating an offsite replica. There are still these points to consider:
- How do you actually do a database failover?
- How do you fail back?
- Are you comfortable with just a standalone MySQL server in your DR site?
- How do you point your applications to the correct datacenter, or have your applications fail over?
- How do you manage and orchestrate all of the above? And where can you see the status of the entire topology?
If you decide to spend the time to try to address the above, the result will be an unsupported “DIY” solution which can have serious risks for the business. Also note: Setting up an asynchronous replication channel from one MySQL InnoDB Cluster to another MySQL InnoDB cluster is not supported and does not work at this time. Thus, per point 3 above, you can only have a single MySQL instance in your DR site.
Real, Supported DR
Fortunately, there’s an easy-to-implement clustering and DR solution for your MySQL databases. Tungsten Cluster includes all of the components needed to implement off-site DR (to multiple sites!), complete with management, orchestration, and a proxy layer that were all built to work with each other. Failover is simple: a single command will orchestrate database failover and reconfigure the proxies, and within seconds your application is online. Failback is much the same with just a single command. The management layer allows a view of the entire database topology, and there is a web-based GUI included as well. For even more cutting-edge DR, Tungsten Cluster also offers active/active clusters. If multiple sites are always active at the same time and one site goes offline, applications will simply be routed to another, unaffected site. There are endless options for configuring routing methods and priorities, but it’s all managed within the product and requires no additional components.
Tungsten Cluster allows you to deploy clusters in multiple sites, each with their own local failover and high availability. It’s quite easy to deploy and manage several DR clusters, on prem, in the cloud, or both!
Also, when questions arise or you simply have questions about your cluster, Tungsten Cluster includes 24/7 support with qualified engineers (each with at least 20+ years of experience) so you don’t have to rely on forum/blog posts or substandard support.
Have a look at our comparison pages - including the InnoDB Cluster comparison; we’ve done the work to look at each product and evaluate them based on a number of factors critical to the enterprise. If you have questions, please feel free to reach out!
Comments
Add new comment