Method for ensuring replication from a change queue of a source database to a target database when transaction load exceeds data path by spawning a new transaction path between the change queue and the target database

• US 8,250,029 B2
• Filed: 01/04/2012
• Issued: 08/21/2012
• Est. Priority Date: 06/30/2004
• Status: Active Grant

• Current Assignee: Intel Corporation
• Original Assignee: Gravie, Inc.
• Inventors: Holenstein, Paul J., Holenstein, Bruce D., Highleyman, Wilbur H.
• Primary Examiner(s): Vy, Hung T
• Application Number:
  US13/343,453
• Publication Number:
  US 20120101990A1
• Time in Patent Office: 230 Days
• Field of Search: 707/615, 707/602, 707/716, 707/720, 370/390, 370/230, 370/412, 370/252, 370/392, 370/401
• US Class Current: 707/615
• CPC Class Codes: G06F 11/2048 where the redundant components share neither address space nor persistent storage
• CPC Class Codes: G06F 11/2064 while ensuring consistency
• CPC Class Codes: G06F 11/2066 Optimisation of the communication load
• CPC Class Codes: G06F 11/2071 using a plurality of controllers
• 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/2365 Ensuring data consistency and integrity
• CPC Class Codes: G06F 16/273 Asynchronous replication or reconciliation
• CPC Class Codes: G06Q 10/087 Inventory or stock management, e.g. order filling, procurement or balancing against orders

Abstract

A method is provided for replicating transaction data from a source database to a target database wherein the transaction data is communicated from a change queue associated with the source database to the target database. An initial path is provided between the change queue and the target database for transaction data to flow. The initial path has a maximum transaction load capacity. It is then detected whether the current transaction load is close or equal to the maximum transaction load capacity of the initial path. If so, another path is provided between the change queue and the target database.

Claims

1. A method of replicating transaction data from a source database to a target database, the transaction data being communicated from a change queue associated with the source database to the target database, the method comprising:

(a) providing an initial path between the change queue and the target database for transaction data to flow, the initial path having a maximum transaction load capacity;

(b) detecting whether the current transaction load is close or equal to the maximum transaction load capacity of the initial path;

(c) providing another path between the change queue and the target database if the current transaction load is close or equal to the maximum transaction load capacity of the initial path, wherein the plural paths cause at least some of the transaction data to become unserialized; and

(d) reserializing at least some of the unserialized data prior to or upon applying the originally unserialized transaction data to the target database.

2. The method of claim 1 wherein there is an initial applier associated with the target database, and the other path includes another applier.

3. The method of claim 2 wherein the appliers normally post transaction data to the target database only upon receipt of a commit step or operation associated with respective transaction data, the method further comprising:

(e) repeating steps (b) and (c) by adding additional appliers as the current transaction load becomes close or equal to the total transaction capacity associated with all of the previously added appliers;

(f) upon reaching a system limit wherein no more appliers can be added and the current transaction load becomes close or equal to the maximum transaction load capacity of all of the appliers, prematurely conducting a commit step or operation on at least some of the transaction data in at least some of the appliers, thereby causing the transaction data to become posted to the target database and deleted from the respective appliers.

4. The method of claim 3 wherein undo events associated with aborted transactions at the source database are also replicated, the method further comprising:

(g) upon receipt of an undo event at an applier, conducting an undo event on the respective prematurely committed transaction data in the target database, thereby causing the transaction at the target database to also be aborted.

5. The method of claim 3 further comprising:

(g) the appliers starting new transactions upon receipt of a modification to a prematurely committed transaction.

6. The method of claim 1 wherein the transaction data is unserialized at the logical level, and becomes reserialized at the logical level.

7. The method of claim 1 wherein if the current transaction load becomes less than the maximum transaction load capacity of the initial path subsequent to reaching the maximum transaction load capacity of the initial path, the method further comprising:

(e) removing the other path.

8. The method of claim 1 wherein there is an initial communication channel at one or more points between the change queue and the target database, and the other path is another communication channel.

9. The method of claim 1 wherein there is an initial extractor associated with the change queue, and the other path includes another extractor.

10. The method of claim 1 wherein the change queue is a change log.

11. The method of claim 1 wherein the change queue is an audit trail.

12. The method of claim 1 wherein the change queue is a database of changes.

13. A method of replicating transaction data from a source database to a target database, the transaction data being communicated from a change queue associated with the source database to the target database, the method comprising:

(a) providing an initial path between the change queue and the target database for transaction data to flow, the initial path having a maximum transaction load capacity;

(b) detecting whether the current transaction load is close or equal to the maximum transaction load capacity of the initial path;

(c) providing another path between the change queue and the target database if the current transaction load is close or equal to the maximum transaction load capacity of the initial path, wherein there is an initial applier associated with the target database, and the other path includes another applier, and wherein the appliers normally post transaction data to the target database only upon receipt of a commit step or operation associated with respective transaction data;

(d) repeating steps (b) and (c) by adding additional appliers as the current transaction load becomes close or equal to the total transaction capacity associated with all of the previously added appliers; and

(e) upon reaching a system limit wherein no more appliers can be added and the current transaction load becomes close or equal to the maximum transaction load capacity of all of the appliers, prematurely conducting a commit step or operation on at least some of the transaction data in at least some of the appliers, thereby causing the transaction data to become posted to the target database and deleted from the respective appliers.

14. The method of claim 13 wherein undo events associated with aborted transactions at the source database are also replicated, the method further comprising:

(f) upon receipt of an undo event at an applier, conducting an undo event on the respective prematurely committed transaction data in the target database, thereby causing the transaction at the target database to also be aborted.

15. The method of claim 13 further comprising:

(f) the appliers starting new transactions upon receipt of a modification to a prematurely committed transaction.

16. The method of claim 13 wherein the plural paths cause at least some of the transaction data to become unserialized, the method further comprising:

(f) reserializing at least some of the unserialized data prior to or upon applying the originally unserialized transaction data to the target database.

17. The method of claim 16 wherein the transaction data is unserialized at the logical level, and becomes reserialized at the logical level.

18. The method of claim 13 wherein if the current transaction load becomes less than the maximum transaction load capacity of the initial path subsequent to reaching the maximum transaction load capacity of the initial path, the method further comprising:

(f) removing the other path.

19. The method of claim 13 wherein there is an initial communication channel at one or more points between the change queue and the target database, and the other path is another communication channel.

20. The method of claim 13 wherein there is an initial extractor associated with the change queue, and the other path includes another extractor.

21. The method of claim 13 wherein the change queue is a change log.

22. The method of claim 13 wherein the change queue is an audit trail.

23. The method of claim 13 wherein the change queue is a database of changes.