Dataloss Failover Configuration in Cloud Data Services
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Cloud applications using geo-redundant data replication face challenges in minimizing performance impact due to latency, often resulting in data loss during failover to secondary data stores, which complicates failover management workflows.
Innovation Solution
The data-tier service allows application services to configure dataloss failover and dataloss-avoidant failover times, enabling failover without data loss if recovery is confirmed, and performing dataloss failover if dataloss-avoidant failover is not possible, thus simplifying failover workflows while balancing operational latency and data integrity.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Speed
If asynchronous replication protocols are used to minimize performance impact of latency, then operational latency is reduced, but data loss occurs during failover
Solution Approach 1:
The system dynamically adjusts failover timing based on replication status. It implements two configurable failover times: dataloss failover time for immediate failover when performance is critical, and dataloss-avoidant failover time for coordinated failover when data integrity is critical. This dynamic approach allows the system to adapt between minimizing latency and preventing data loss based on operational needs.
Solution Approach 2:
The system changes the failover timing parameter based on replication synchronization status. By configuring different failover times (dataloss vs. dataloss-avoidant), the system modifies the timing parameter to balance between operational latency and data integrity, allowing asynchronous replication to proceed with minimal latency impact while providing options to avoid data loss when needed.
2Reliability
If complex failure monitoring and failover management workflows are implemented in cloud applications, then failover reliability is improved, but system complexity increases
Solution Approach 1:
The patent extracts failover management functionality from the cloud application layer and places it in the data-tier service layer. The data-tier service now handles failure monitoring and failover execution directly, while applications simply configure failover policies. This extraction simplifies application complexity while maintaining or improving failover reliability through centralized management.
Solution Approach 2:
The data-tier service acts as an intermediary between the primary and secondary data stores, managing the failover process. Instead of applications directly monitoring failures and executing failover workflows, the data-tier service mediates this process based on configured policies, reducing application complexity while ensuring reliable failover execution.
3Loss of information
If dataloss-avoidant failover is attempted, then data integrity is improved, but failover time increases due to coordination requirements
Solution Approach 1:
The system performs preliminary actions by configuring both dataloss failover time and dataloss-avoidant failover time in advance. The dataloss-avoidant failover time is set to allow sufficient time for replication coordination before failover. By preparing these timing parameters beforehand, the system can execute coordinated failover without excessive delay when data integrity is the priority.
Data Source
AI summary
Application service configuration of a timeframe for performing dataloss failover (failover that does not attempt full data replication to the secondary data store) from a primary data store to the secondary data store. A data-tier service, such as perhaps a database as a service (or DBaaS), could receive that configuration from the application service and automatically perform the dataloss failover as configured by the application service. This relieves the application service from having to manage the failover workflow while still allowing the application service to appropriately balance the timing of dataloss failover, which will depend on a very application-specific optimal balance between the negative effects of operational latency versus dataloss.