Method for synchronizing replicas of a database

• US 7,475,281 B2
• Filed: 03/10/2005
• Issued: 01/06/2009
• Est. Priority Date: 03/10/2005
• Status: Expired due to Fees

• Current Assignee: International Business Machines Corporation
• Original Assignee: International Business Machines Corporation
• Inventors: Varghese, John
• Primary Examiner(s): Puente; Emerson C
• Application Number:
  US11/078,890
• Publication Number:
  US 20060206768A1
• Time in Patent Office: 1,398 Days
• Field of Search: 714/6
• US Class Current: 714/6.1
• 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: H04L 67/1095 Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes

Abstract

A method for synchronizing replicas of a database. The method includes detecting a failure of update data from a first replica to be applied to a second replica; determining a cause of the failure; and resolving the cause of the failure. According to the method disclosed herein, the present invention synchronizes the replicas of the database without requiring manual intervention.

Claims

1. A computer-implemented method for synchronizing replicas of a database, the method comprising:

sending update data from a first replica to a second replica, the first replica being associated with a first acquire server unit and a first acquire client unit, and the second replica being associated with a second acquire server unit and a second acquire client unit;

automatically detecting a failure of the update data from the first replica to be applied to the second replica, wherein the detecting comprises;

requesting, by the first acquire client unit from the second acquire server, metadata comprising export parameters;

receiving, by the first acquire client unit from the second acquire server, the metadata;

automatically determining a cause of the failure and where the cause of the failure occurred, wherein the determining comprises;

determining, by the first acquire client, if the failure was due to a packet being lost, wherein the packet contains the update data, wherein the first acquire client determines if the failure was due to a packet being lost by requesting from the second acquire server, the result of the last failed import to confirm that the packet was actually lost;

parsing, by the first acquire client, the metadata received from the second acquire server, wherein the parsed metadata indicates if an account is locked out; and

determining, by the first acquire client, if the second replica is updated with current update data;

automatically resolving the cause of the failure, wherein the resolving comprises;

requesting, by the first acquire client, for a packet to be resent if the cause of the failure is due to the packet being lost;

resending, by the first acquire client, a packet containing the update data if the second replica is not updated with current update data;

unlocking, by the first acquire client, an account if the cause of the failure is due to the account being locked out;

deleting, by the first acquire client, an object if the cause of the failure is due to the object not being deleted during a previous export; and

notifying, by the first acquire client, an appropriate authority of the failure if corrective actions need to be taken by the appropriate authority;

resending the update data;

applying the update data to the second replica; and

recording update data in an operations log.