IP Library Granted Patent US 7,613,742
Granted Patent B2
US 7,613,742 · App. 11/416,653 · Granted Nov 3, 2009

System and method for providing three-way failover for a transactional database

Assignee: Mypoints.Com Inc.
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 7,613,742
App. No.
11/416,653
Granted
Nov 3, 2009
Kind
B2
Abstract

A method for providing three-way failover for a database server group includes identifying a master server failure or a master server shutdown, designating a first replication server as a new master server, and copying data from a second replication server to a new replication server while the first replication server functions as the new master server. The method also includes receiving new data at the server group and saving the new data at the new master server, saving the new data in a queue at the second replication server until the set of data stored on the second replication server has been copied to the new replication server, and reading the new data saved in the queue and applying the new data to the second replication server after the set of data has been copied to the new replication server.

Claims (36)

1. A method for providing three-way failover for a server group, comprising:

identifying one or more of a master server failure or a master server shutdown;

designating a first replication server as a new master server;

copying an existing set of data from a second replication server to a new replication server while the first replication server functions as the new master server;

receiving new data at the server group and saving the new data at the new master server, wherein the new data is associated with a portion of the existing data that is copied to the new replication server and the portion of the existing data was previously stored at the first and second replication servers;

pulling a copy of the new data from a log at the new master server into a persistent storage queue at the second replication server while the existing set of data stored on the second replication server is being copied to the new replication server; and

if the existing set of data stored on the second replication server is still being copied to the new replication server when the new data is received, pulling a copy of the new data from the log at the new master server into the persistent storage queue at the second replication server; or

if the existing set of data stored on the second replication server is not being copied to the new replication server when the new data is received, or once the existing set of data stored on the second replication server is completed being copied to the new replication server, reading the new data saved in the persistent storage queue and applying the new data to the second replication server whereby the new data is accessible to the server group, and reading the new data stored in the master server and applying the new data to the new replication server.

2. The method of claim 1 , wherein pulling the copy of the new data from the log at the new master server into the persistent storage queue is a first thread, and wherein reading the new data saved in the persistent storage queue and applying the new data to the second replication server is a second thread.

3. The method of claim 1 , further comprising saving the new data in a cache memory located at the second replication server.

4. The method of claim 1 , further comprising preventing an e-mail engine from running an e-mail campaign on the second replication server until the set of data stored on the second replication server has been copied to the new replication server.

5. The method of claim 1 , further comprising preventing a query from running on the second replication server until the set of data stored on the second replication server has been copied to the new replication server.

6. The method of claim 1 , further comprising directing a query to the new master server until the set of data stored on the second replication server has been copied to the new replication server.

7. The method of claim 1 , wherein the new data is associated with a set of existing data, the set of existing data previously stored at the first and second replication servers.

8. A method for providing three-way failover for a database server group, comprising:

determining if a master server has experienced a hardware failure or a software failure;

making a first replication server a new master server;

copying existing data stored at a second replication server to a new replication server;

receiving new data at the database server group and saving the new data at the new master server, wherein the new data is associated with a portion of the existing data, the portion of the existing data was previously stored at the first and second replication servers;

initiating a first thread at the second replication server until the existing data stored on the second replication server has been copied to the new replication server, wherein the first thread includes pulling a copy of the new data from a log at the new master server into a persistent storage queue at the second replication server; and

initiating a second thread at the second replication server and the new replication server after the existing data stored on the second replication server has been copied to the new replication server, wherein the second thread includes reading the new data saved in the persistent storage queue and applying the new data to the second replication server and saving the new data from the new master server to the new replication server.

9. The method of claim 8 , further comprising preventing an e-mail engine from running an e-mail campaign on the second replication server until the existing data stored on the second replication server has been copied to the new replication server.

10. The method of claim 8 , further comprising preventing a query from running on the second replication server until the existing data stored on the second replication server has been copied to the new replication server.

11. The method of claim 8 , further comprising directing a query to the new master server until the existing data stored on the second replication server has been copied to the new replication server.

12. A method for providing three-way failover for a database server group, comprising:

identifying one or more of a replication server failure or a replication server shutdown;

designating a new replication server, the new replication server operatively coupled to a first replication server, and a master server;

copying an existing set of data from the first replication server to the new replication server;

receiving new data at the database server group and saving the new data at the master server;

pulling a copy of the new data from a log at the master server into a persistent storage queue at the first replication server while the existing set of data stored on the first replication server is being copied to the new replication server; and

if the existing set of data stored on the first replication server is still being copied to the new replication server when the new data is received, pulling a copy of the new data from the log at the new master server into the persistent storage queue at the first replication server; or

if the existing set of data stored on the first replication server is not being copied to the new replication server when the new data is received, or once the existing set of data stored on the first replication server is completed being copied to the new replication server, reading the new data saved in the persistent storage queue and applying the new data to the first replication server whereby the new data is accessible to the server group, and reading the new data stored in the master server and applying the new data to the new replication server.

13. The method of claim 12 , further comprising preventing an e-mail engine from running an e-mail campaign on the first replication server until the set of data stored on the first replication server has been copied to the new replication server.

14. The method of claim 12 , further comprising preventing a query from running on the first replication server until the set of data stored on the first replication server has been copied to the new replication server.

15. The method of claim 12 , further comprising directing a query to the master server until the set of data stored on the first replication server has been copied to the new replication server.

16. The method of claim 12 , wherein pulling the copy of the new data from the master server into the persistent storage queue is a first thread, and wherein reading the new data saved in the queue and applying the new data to the first replication server is a second thread.

Assignments (10)
RELEASE OF SECURITY INTEREST Recorded Dec 16, 2021
From: TRUIST BANK (SUCCESSOR BY MERGER TO SUNTRUST BANK)
To: MYPOINTS.COM, LLC
Reel/Frame 058523/0885 →
SHORT FORM INTELLECTUAL PROPERTY SECURITY AGREEMENT Recorded Nov 20, 2018
From: MYPOINTS.COM, LLC
To: SUNTRUST BANK, AS COLLATERAL AGENT
Reel/Frame 047605/0852 →
RELEASE OF SECURITY INTEREST : RECORDED AT REEL/FRAME - 43357-0716 Recorded Nov 20, 2018
From: SILICON VALLEY BANK
To: MYPOINTS.COM LLC
Reel/Frame 047609/0502 →
RELEASE OF SECURITY INTEREST : RECORDED AT REEL/FRAME 40936/0199 Recorded Nov 20, 2018
From: SILICON VALLEY BANK
To: PRODEGE LLC; MYPOINTS.COM LLC
Reel/Frame 047609/0582 →
SECURITY INTEREST Recorded Aug 22, 2017
From: MYPOINTS.COM, LLC
To: SILICON VALLEY BANK
Reel/Frame 043357/0716 →
SECURITY INTEREST Recorded Jan 10, 2017
From: PRODEGE, LLC; MYPOINTS.COM, LLC
To: SILICON VALLEY BANK
Reel/Frame 040936/0199 →
CHANGE OF NAME Recorded Jun 8, 2016
From: MYPOINTS.COM, INC.
To: MYPOINTS.COM, LLC
Reel/Frame 038907/0502 →
RELEASE Recorded May 3, 2010
From: SILICON VALLEY BANK
To: MYPOINTS.COM, INC.
Reel/Frame 024320/0947 →
SECURITY AGREEMENT Recorded Aug 13, 2008
From: MYPOINTS.COM, INC.
To: SILICON VALLEY BANK
Reel/Frame 021380/0495 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Jun 22, 2006
From: BOHANNON, JAMES J.; REDDY, ANANTH A.
To: MYPOINTS.COM INC.
Reel/Frame 017834/0015 →
Continuity (1)
Related Publication 20070260696A1 · Nov 8, 2007