High Availability: Warm Standby, Hot Standby
You might have heard these terms kicked around in recent months: warm standby and hot standby. But they’re nowhere to be found in smart data streaming, and they’re never mentioned in the documentation either. So what do they mean?
The short explanation is that these terms refer to groups of high availability (HA) settings. Since there are many different options for configuring high availability, we’re grouping them into these two categories:
- Warm standby (recommended): A single project instance with failover enabled. The project will restart on a different host in a multi-host cluster if the host fails. The exception is if a strong affinity is set for the project, requiring it to always run on a specific host.
- This category includes any type of failover setting for either HA or non-HA projects.
- Hot standby: Two instances of the project, deployed as a primary and secondary pair. All connections go to the primary instance, but are redirected to the secondary instance should the primary fail. The secondary instance remains in sync and will immediately take over, if necessary.
- This category includes active-active settings for HA projects.
Deploying a project in HA mode means enabling hot standby. You can also run either or both the primary and secondary project deployment instances in warm standby mode.
These terms don’t appear in Studio, but they will eventually appear in other places, including the documentation. However, since we are already using these terms in every day conversations about high availability, you’ll need to know what they mean.
Still unsure about how this new terminology works? Here’s a summary:
|Old/Current Term||New Term||Project Deployment Type||Option Type||Description|
A single project instance with
|Hot standby||HA||Specialized option||
Two instances of the project,
deployed as a primary and secondary pair.
For more information, take a look at our documentation for High Availability.
Given the importance of High Availability (HA) would Operational Acceptance testing be the place where the HA and Disaster Recovery (DR) be conducted or assured.
Experience in the past has shown that these two areas are frequently left out of any Development approach and subsequently the organisation ends up losing data, time and money.
Yes both HA and DR should be tested outside of your Production environment. Typical enterprise system landscapes will include Dev, Test/QA and Production. There may also be a Staging environment between Test/QA and Production. HA and DR are often not configured in the Dev environment but should be configured and tested in either or both of Test/QA and Staging.
Thask Robert appreacite the comments