Minimizing data loss in asynchronous replication solution using distributed redundancy

• US 7,908,514 B2
• Filed: 06/26/2008
• Issued: 03/15/2011
• Est. Priority Date: 06/26/2008
• Status: Active Grant

• Current Assignee: Microsoft Technology Licensing LLC (Microsoft Corporation)
• Original Assignee: Microsoft Corporation
• Inventors: Bracewell, Shawn, Benfield, Rebecca, Thiel, Gregory, Wetmore, Alexander R.
• Primary Examiner(s): DUNCAN, MARC M
• Application Number:
  US12/146,602
• Publication Number:
  US 20090327805A1
• Time in Patent Office: 992 Days
• Field of Search: 714/6, 714/15, 714/16
• US Class Current: 714/15
• CPC Class Codes: G06F 11/1658 Data re-synchronization of a redundant component, or initial sync of replacement, additional or spare unit
• CPC Class Codes: G06F 11/2097 maintaining the standby controller/processing unit updated initialisation or re-synchronisation thereof G06F11/1658 and subgroups
• CPC Class Codes: G06F 16/273 Asynchronous replication or reconciliation
• CPC Class Codes: G06F 2201/835 Timestamp

Abstract

Architecture that reduces data loss resulting from failover in an asynchronous log shipping deployment, but leveraging mid-tier and frontend servers to fill in lost data. In an asynchronous log shipping operation, a replication component asynchronously replicates messaging data to a backend server in accordance with one or more replication operations, which can be updates to databases on the backend server. These databases can include messaging data, such as email address books, mailboxes, etc. A history component maintains a history of replication operations on a frontend server. In the event of a lossy failover, a replay component is used for replaying the replication operations from the history to the backend server.

Claims

1. A computer-implemented data management system, comprising:

a history component for maintaining a history of changes made by clients to backend servers;

a storage component for storing the history of the changes for resubmission of the changes in response to a lossy failover of the backend servers;

a pruning component for pruning outdated history items from the history based in part on a replication feedback channel; and

a processor that executes computer-executable instructions associated with at least the history component.

2. The system of claim 1, wherein the history component is part of a frontend server for resubmission of a recent history of the changes from the frontend server to the backend servers.

3. The system of claim 1, wherein the history component is part of a middle-tier server for resubmission of a recent history of the changes to the backend servers.

4. The system of claim 1, further comprising a failover detection component for detecting a lossy failover of the backend servers during data replication.

5. The system of claim 1, further comprising a resubmission component for resubmitting changes of the history to the backend servers in response to detection of a lossy failover.

6. The system of claim 1, further comprising a resubmission component for defining a time interval that defines which items of the history to resubmit.

7. The system of claim 1, wherein the history includes at least one of mid-tier server or frontend server operations selected from operations that create a new messaging object, operations that update an existing object, or operations that are performed on an original item and are distributed to recipients.

8. The system of claim 1, further comprising a timestamp at which the changes are up-to-date and correct, the pruning component expires changes from the history that are older than the timestamp.

9. The system of claim 1, further comprising a time interval, defined by the replication feedback channel, for which items in the history are considered for resubmission.

10. The system of claim 1, further comprising resubmission progress, periodically obtained from the backend servers, represented as a timestamp of changes successfully resubmitted.

11. A computer-implemented data management system, comprising:

a history component for maintaining a history of recent changes made by clients to mid-tier and/or frontend servers, the history includes changes related to update of an existing messaging object, the changes and backend version information of the object are stored in the history;

a failover detection component for detecting lossy failover of asynchronous replication of data to backend servers;

a resubmission component for requesting resubmission of the recent changes from the history to fill in the changes lost during the replication; and

a processor that executes computer-executable instructions associated with at least one of the history component, the failover detection component, or the resubmission component.

12. The system of claim 11, wherein the resubmission component sends a request to the mid-tier and/or frontend servers to resubmit changes defined within a time range.

13. The system of claim 11, further comprising a duplicate detection component for detecting duplications between the recent changes resubmitted and data replicated at the backend servers.

14. The system of claim 11, wherein the history includes changes related to creation of a new messaging object, identity information of the new messaging object, and a global unique ID for the new messaging object.

15. The system of claim 11, wherein the history includes changes performed on an item of an originator, and which changes are distributed to messaging system recipients.

16. A computer-implemented method of data management, comprising acts of:

maintaining a recent history of client changes at a server location including changes in the history related to creating a new messaging object and updating an existing messaging object;

detecting lost replication data during lossy failover of backend servers;

requesting resubmission of the changes from the history of the server location to the backend servers;

resubmitting the changes from the history to the backend servers to replace the lost replication data; and

utilizing a processor that executes instructions stored in memory to perform at least one of the acts of maintaining, detecting, requesting, or resubmitting.

17. The method of claim 16, further comprising employing a feedback loop from the backend servers to the server location to coordinate the history with replication history.

18. The method of claim 16, further comprising defining a time interval within which recent changes of the history will be resubmitted, the recent changes associated with timestamp information.

19. The method of claim 16, further comprising:

processing the recent changes of the history beginning with the oldest history entry;

detecting and removing duplicates; and

removing successfully replicated changes from the history as soon as replication of the changes is successful.

20. The method of claim 16, further comprising maintaining the history based on at least one of time data or size data.