Unexpected downtime costs your organization - in lost revenue or reputation. And even if you have architected database failover into your data centers, that process still impacts your apps - causing them to hang or forcing a restart.
ScaleArc supports application-transparent automated database failover, shielding apps from the downtime and preventing application errors. Operating at the SQL protocol layer, ScaleArc instantly and transparently routes database traffic around downed servers - even across multiple data centers for maximum availability - ensuring business continuity for SQL environments.
Without changing a single line of application code, you can easily overcome the failover limitations of:
SQL Server 2012, 2014, 2016
Deeply integrated with AlwaysOn Availability Groups, ScaleArc can:
- Extend automated failover beyond a single data center to seamlessly migrate load from one data center to another
- Recognize the current status of the entire Availability Group, including which servers are part of the group and what type of replication they utilize
- Support load balancing to all servers within the Availability Group based on the optimal response time
ScaleArc offers the very first and only automated failover solution that works for MySQL environments right out of the box – with MySQL master/master replication, MySQL mater/slave replication, and Galera’s multi-master cluster.
Hard and soft failure detection
ScaleArc quickly detects:
- Authentication failures
- Connection failures
- SQL service failures
- Replication lag failures
Primary server failover
ScaleArc immediately stops traffic to any failed write servers, placing traffic in its write queue until a secondary can be promoted to primary. ScaleArc’s unique surge queue minimizes application disruption by temporarily holding queries during the failover and instantly releasing traffic as soon as the new primary is available – preventing application errors.
Secondary server failover
If a secondary server fails, ScaleArc automatically redistributes load across the remaining servers in the cluster. You can also select to take secondary servers offline, in rotation, to complete patches and other updates, enabling zero-downtime maintenance.