IP Library Granted Patent US 12,423,323
Granted Patent B2
US 12,423,323 · App. 18/827,377 · Granted Sep 23, 2025

Data replication and data failover in data storage systems

Inventors: Benoit Dageville (Seattle, WA); Eric Robinson (Sammamish, WA); Martin Hentschel (Seattle, WA)
Assignee: Snowflake Inc.
G06F16/273G06F16/245H04L67/1097
View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 12,423,323
App. No.
18/827,377
Filed
Sep 6, 2024
Granted
Sep 23, 2025
Kind
B2
Art Unit
2165
USPC
707/615
Abstract

Replication and failover of data is disclosed. A method includes replicating the data stored in a primary deployment such that the data is further stored in a secondary deployment. The method includes executing one or more transactions on the data at the primary deployment to cause a change to the data to be stored in the primary deployment. The method includes propagating the one or more transactions on the data to the secondary deployment to perform a failover to the secondary deployment while the change to the data is absent from the secondary deployment.

Claims (60)

1. A system comprising:

a memory to store data; and

a processor, operatively coupled with the memory, the processor to:

replicate the data stored in a primary deployment such that the data is further stored in a secondary deployment;

execute one or more transactions on the data at the primary deployment to cause a change to the data to be stored in the primary deployment;

determine that the primary deployment transitioned from an available state to an unavailable state;

propagate the one or more transactions on the data to the secondary deployment to perform a failover to the secondary deployment while the change to the data is absent from the secondary deployment; and

adhere to a user-defined maximum acceptable time period for the secondary deployment to become available for executing queries on the data after the primary deployment is determined to be unavailable.

2. The system of claim 1 , wherein the processor is further to shift execution of queries on the data from the primary deployment to the secondary deployment for a duration of time the primary deployment is unavailable.

3. The system of claim 1 , wherein to determine that the primary deployment transitioned from the available state to the unavailable state, the processor to determine one or more of:

a power outage has occurred at the primary deployment;

an error resulting in improper modification or deletion of the data at the primary deployment has occurred;

a data center outage has occurred at the primary deployment;

a cloud provider of the primary deployment has experienced an outage;

an error has occurred at the primary deployment; or

the primary deployment is undergoing scheduled downtime.

4. The system of claim 1 , wherein the processor further to adhere to a user-defined maximum number of database transactions an application may tolerate losing when shifting database operations from the primary deployment to the secondary deployment in response to the primary deployment becoming unavailable.

5. The system of claim 1 , wherein to replicate the data stored in the primary deployment, the processor to replicate in response to the primary deployment becoming unavailable.

6. The system of claim 1 , wherein the processor further to shift a client account connection from the primary deployment to the secondary deployment in response to the primary deployment becoming unavailable.

7. The system of claim 1 , wherein to propagate the one or more transactions to the secondary deployment, the processor to propagate only the one or more transactions without replicating any data already existing in the primary deployment before the primary deployment became unavailable.

8. The system of claim 1 , wherein to propagate the one or more transactions to the secondary deployment, the processor to determine the one or more transactions based on a global file identifier indicating which files in the data have been updated since the primary deployment became unavailable.

9. The system of claim 1 , wherein the primary deployment and the secondary deployment are located in different geographic locations.

10. The system of claim 1 , wherein the primary deployment and the secondary deployment are provided by different cloud-based storage providers.

11. The system of claim 1 , wherein the processor is further to provide a notification to an account associated with the data when availability status of either of the primary deployment or the secondary deployment has changed.

12. A method comprising:

replicating data stored in a primary deployment such that the data is further stored in a secondary deployment;

executing, by a processor, one or more transactions on the data at the primary deployment to cause a change to the data to be stored in the primary deployment;

determining that the primary deployment transitioned from an available state to an unavailable state;

propagating the one or more transactions on the data to the secondary deployment to perform a failover to the secondary deployment while the change to the data is absent from the secondary deployment; and

adhering to a user-defined maximum acceptable time period for the secondary deployment to become available for executing queries on the data after the primary deployment is determined to be unavailable.

13. The method of claim 12 , further comprising, in response to determining that the primary deployment is unavailable, shifting execution of queries on the data from the primary deployment to the secondary deployment for a duration of time the primary deployment is unavailable.

14. The method of claim 13 , wherein shifting the execution of the queries from the primary deployment to the secondary deployment occurs within a user-defined maximum acceptable time period for the secondary deployment to become available for executing queries after the primary deployment is determined to be unavailable.

15. The method of claim 12 , wherein determining that the primary deployment transitioned from the available state to the unavailable state comprises at least one or more of:

a power outage has occurred at the primary deployment;

an error resulting in improper modification or deletion of the data at the primary deployment has occurred;

a data center outage has occurred at the primary deployment;

a cloud provider of the primary deployment has experienced an outage;

an error has occurred at the primary deployment; or

the primary deployment is undergoing scheduled downtime.

16. The method of claim 12 , further comprising:

shifting a client account connection from the primary deployment to the secondary deployment in response to the primary deployment becoming unavailable.

17. The method of claim 12 , wherein propagating the one or more transactions to the secondary deployment comprises propagating only the one or more transactions without replicating any data already existing in the primary deployment before the primary deployment became unavailable.

18. The method of claim 12 , wherein propagating the one or more transactions to the secondary deployment comprises determining the one or more transactions based on a global file identifier indicating which files in the data have been updated since the primary deployment became unavailable.

19. A non-transitory computer readable storage media comprising instructions that, when executed by a processor, cause the processor to:

replicate data stored in a primary deployment such that the data is further stored in a secondary deployment;

execute, by the processor, one or more transactions on the data at the primary deployment to cause a change to the data to be stored in the primary deployment;

determine that the primary deployment transitioned from an available state to an unavailable state;

propagate the one or more transactions on the data to the secondary deployment to perform a failover to the secondary deployment while the change to the data is absent from the secondary deployment; and

adhere to a user-defined maximum acceptable time period for the secondary deployment to become available for executing queries on the data after the primary deployment is determined to be unavailable.

20. The non-transitory computer readable storage media of claim 19 , wherein the processor further to, in response to determining that the primary deployment is unavailable, shift execution of queries on the data from the primary deployment to the secondary deployment for a duration of time the primary deployment is unavailable.

21. The non-transitory computer readable storage media of claim 19 , wherein to determine that the primary deployment transitioned from the available state to the unavailable state, the processor is further to at one or more of:

a power outage has occurred at the primary deployment;

an error resulting in improper modification or deletion of the data at the primary deployment has occurred;

a data center outage has occurred at the primary deployment;

a cloud provider of the primary deployment has experienced an outage;

an error has occurred at the primary deployment; or

the primary deployment is undergoing scheduled downtime.

22. The non-transitory computer readable storage media of claim 19 , wherein to replicate the data stored in the primary deployment, the processor to replicate in response to the primary deployment becoming unavailable.

23. The non-transitory computer readable storage media of claim 19 , wherein the processor further to shift a client account connection from the primary deployment to the secondary deployment in response to the primary deployment becoming unavailable.

24. The non-transitory computer readable storage media of claim 19 , wherein to propagate the one or more transactions to the secondary deployment, the processor to propagate only the one or more transactions without replicating any data already existing in the primary deployment before the primary deployment became unavailable.

Assignments (2)
CHANGE OF NAME Recorded Aug 1, 2025
From: SNOWFLAKE COMPUTING, INC.
To: SNOWFLAKE INC.
Reel/Frame 072319/0674 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Jun 13, 2025
From: DAGEVILLE, BENOIT; ROBINSON, ERIC; HENTSCHEL, MARTIN
To: SNOWFLAKE COMPUTING INC.
Reel/Frame 071414/0387 →
Continuity (4)
Continuation 16700958 · Dec 2, 2019
Continuation 16392258 · Apr 23, 2019
Provisional Application 62694656 · Jul 6, 2018
Related Publication 20240427801A1 · Dec 26, 2024
References Cited (15)
US 7627584B2 · Claborn et al. · 2009 [cited by applicant]
US 7653668B1 · Shelat et al. · 2010 [cited by applicant]
US 8949657B2 · Mcgill et al. · 2015 [cited by applicant]
US 20030126137A1 · Mcfadden · 2003 [cited by applicant]
US 20080091737A1 · Lee et al. · 2008 [cited by applicant]
US 20120159234A1 · Mehta et al. · 2012 [cited by applicant]
US 20160124663A1 · Mitkar et al. · 2016 [cited by applicant]
US 20160246865A1 · Bourbonnais et al. · 2016 [cited by applicant]
US 20170213046A1 · Kaduluri et al. · 2017 [cited by applicant]
US 20200012659A1 · Dageville et al. · 2020 [cited by applicant]
US 20200104310A1 · Dageville et al. · 2020 [cited by applicant]
US 20210056095A1 · Srivastava · 2021 [cited by applicant]
MarkMLI, “Micro-Partitioning,” Wikipedia, Dec. 27, 2017, URL: https://en.wikipedia.org/w/index.php?title=Micro%ADPartitioning&oldid=817299099. [cited by applicant]
“Difference between Failover and Failback?”, Storage Servers, WordPress.com, Apr. 4, 2016, URL: https://storageservers.word press.com/2016/04/04/difference-between-failover-and-failback/. [cited by applicant]
Extended European Search Report of Application No. 23197879.8 mailed Jan. 3, 2024, 14 pages. [cited by applicant]