MINIMIZING DATA LOSS IN ASYNCHRONOUS REPLICATION SOLUTION USING DISTRIBUTED REDUNDANCY

• US 20090327805A1
• Filed: 06/26/2008
• Published: 12/31/2009
• 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.
• Granted Patent: US 7,908,514 B2
• Time in Patent Office: Days
• 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; and

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.

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 pruning component for pruning outdated history items from the history based in part on a replication feedback channel.

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

8. 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.

9. 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;

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

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

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

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

12. The system of claim 9, 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.

13. The system of claim 9, wherein 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.

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

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

maintaining a recent history of client changes at a server location;

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; and

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

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

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

18. The method of claim 15, further comprising including changes in the history related to creating a new messaging object and updating an existing messaging object.

19. The method of claim 15, 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 15, further comprising maintaining the history based on at least one of time data or size data.