Method for ensuring referential integrity in multi-threaded replication engines

• US 20050021567A1
• Filed: 06/30/2004
• Published: 01/27/2005
• Est. Priority Date: 06/30/2003
• Status: Active Grant

• Current Assignee: Intel Corporation
• Original Assignee: Gravic Incorporated
• Inventors: Holenstein, Bruce D., Holenstein, Paul J., Highleyman, Wilbur H.
• Granted Patent: US 7,801,851 B2
• Time in Patent Office: Days
• US Class Current: 1/1
• 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

During replication of transaction data from a source database to a target database via a change queue associated with the source database, one or more multiple paths are provided between the change queue and the target database. The one or more multiple paths cause at least some of the transaction data to become unserialized. At least some of the unserialized data is reserialized prior to or upon applying the originally unserialized transaction data to the target database. If the current transaction load is close or equal to the maximum transaction load capacity of a path between the change queue and the target database, another path is provided. If the maximum transaction threshold limit of an applier associated with the target database has been reached, open transactions may be prematurely committed.

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 one or more multiple paths between the change queue and the target database, the one or more multiple paths causing at least some of the transaction data to become unserialized; and

(b) 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 step (b) is performed by a database of change (DOC) file, the DOC file:

(i) receiving and storing the unserialized data, and

(ii) making the unserialized data available to be replayed in serialized order.

3. The method of claim 2 wherein step (b)(ii) is performed when a transaction end state occurs.

4. The method of claim 2 wherein step (b)(ii) is performed when all of the unserialized data to be serialized has been received.

5. The method of claim 1 further comprising:

(c) providing a plurality of communication channels at one or more points between the change queue and the target database, the plurality of communication channels being one of the multiple paths.

6. The method of claim 5 wherein only a single communication channel is initially provided at the one or more points between the change queue and the target database, the method further comprising:

(d) prior to step (a), detecting whether the current transaction load is close or equal to to the transaction load capacity of the single communication channel, and if so, performing step (c).

7. The method of claim 1 further comprising:

(c) providing a plurality of extractors associated with the change queue, the plurality of extractors being one of the multiple paths.

8. The method of claim 7 wherein only a single extractor is initially associated with the change queue, the method further comprising:

(d) prior to step (a), detecting whether the current transaction load is close or equal to to the transaction load capacity of the single extractor, and if so, performing step (c).

9. The method of claim 1 further comprising:

(c) providing a plurality of appliers associated with the target database, the plurality of appliers being one of the multiple paths.

10. The method of claim 9 wherein only a single applier is initially associated with the target database, the method further comprising:

(d) prior to step (a), detecting whether the current transaction load is close or equal to to the transaction load capacity of the single applier, and if so, performing step (c).

11. The method of claim 1 further comprising:

(c) sending an indication along each of the multiple paths which previously received transaction data that all of the transaction data has been sent, wherein step (b) is performed only after an indication has been received for each of the multiple paths that previously received transaction data.

12. The method of claim 11 wherein the indication is a commit.

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

14. The method of claim 1 wherein the multiple paths cause at least some of the transaction data within and across respective and successive transactions to become unserialized, wherein step (b) further comprises reserializing at least some of the unserialized data within and across the respective and successive transactions prior to or upon applying the originally unserialized transaction data to the target database.

15. The method of claim 1 further comprising:

(c) providing a plurality of databases of change (DOCs) at one or more points between the change queue and the target database, the plurality of DOCs being one of the multiple paths.

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

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

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

19. The method of claim 1 wherein there is a communication channel between the target database and the one or more multiple paths, and step (b) is performed by a transaction serializer queuing intra-transaction data to the communication channel in a serialized order.

20. The method of claim 1 wherein there is a communication channel between the target database and the one or more multiple paths, and step (b) is performed by a transaction serializer queuing inter-transaction data to the communication channel in a serialized order.

21. The method of claim 1 wherein step (b) is performed by extractor coordination.

22. The method of claim 1 wherein step (b) is performed by applier coordination.

23. The method of claim 1 further comprising:

(c) maintaining a record in a control table of which path a transaction is first initiated on, and step (b) is performed by the control table assigning all subsequent transaction data related to each initiated transaction to the same path.

24. The method of claim 1 further comprising:

(c) maintaining a record in a control table of transaction completion order on the source database, and step (b) is performed by the control table allowing the transactions to be replayed in the transaction completion order.

25. The method of claim 1 wherein a plurality of appliers are associated with the target database, the method further comprising:

(c) providing a router/serializer at a location along the one or more multiple paths, and step (b) is performed by the router/serializer receiving the unserialized data and making the unserialized data available to be replayed in serialized order, the router/serializer also assigning transactions to specific appliers associated with the target database, and coordinating commits between the appliers.

26. The method of claim 1 wherein a plurality of appliers are associated with the target database, the method further comprising:

(c) providing a database of change (DOC) and a router in series with each other at locations along the one or more multiple paths, and step (b) is performed by the DOC receiving the unserialized data and making the unserialized data available to be replayed in serialized order, the router assigning transactions to specific appliers associated with the target database, and coordinating commits between the appliers.

27. The method of claim 1 wherein a plurality of appliers are associated with the target database, the method further comprising:

(c) providing a router at a location along the one or more multiple paths, the router assigning transactions to specific appliers associated with the target database.

28. 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, wherein the source database spans multiple nodes, the change queue receiving transaction data posted at all of the nodes, the method comprising:

(a) providing one or more multiple paths between the change queue and the target database, the aggregate of at least some of the transaction data output from the change queue being unserialized; and

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

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

30. The method of claim 28 wherein the source database and the change queue span multiple nodes, the change queue at each of the nodes being associated with the respective source database at that node, wherein step (b) further comprises providing one or more multiple paths between the plurality of change queues and the target database, the aggregate of at least some of the transaction data output from the plurality of change queues being unserialized.

31. The method of claim 28 wherein the change queue is a change log.

32. The method of claim 28 wherein the change queue is an audit trail.

33. The method of claim 28 wherein the change queue is a database of changes.

34. A method of processing base level data of a change queue that is not serialized at the logical level, the base level change queue data being transaction data previously posted to a source database, the method comprising:

(a) providing a logical replication engine to replicate and post the change queue data to a target database in the order that the transaction data is stored in the change queue; and

(b) upon detection in the logical replication engine of change queue data that is not serialized at the logical level, reserializing the change queue data at the logical level before the logical replication engine applies the change queue data to the target database.

35. The method of claim 34 wherein the reserializing in step (b) is performed by accumulating index inserts.

36. The method of claim 34 wherein the reserializing in step (b) is performed with a set-aside queue.

37. The method of claim 34 wherein the reserializing in step (b) is performed with a set-aside queue with transaction end-state processing.

38. The method of claim 34 wherein the change queue is a change log.

39. The method of claim 34 wherein the change queue is an audit trail.

40. The method of claim 34 wherein the change queue is a database of changes.

41. A method of processing base level data of a change queue that is not serialized at the logical level, the base level change queue data being transaction data previously posted to a source database, the method comprising:

(a) providing a logical replication engine to replicate the change queue data that is not serialized at the logical level to a target database; and

(b) posting the change queue data that is not serialized at the logical level to the target database using asynchronous database access.

42. The method of claim 41 wherein step (a) replicates the change queue data to the target database in the order that the transaction data is stored in the change queue.

43. The method of claim 41 wherein the asynchronous database access uses asynchronous calls to the target database.

44. The method of claim 41 wherein the change queue is a change log.

45. The method of claim 41 wherein the change queue is an audit trail.

46. The method of claim 41 wherein the change queue is a database of changes.

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

(c) if so, providing another path between the change queue and the target database.

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

49. The method of claim 48 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:

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

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

50. The method of claim 49 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.

51. The method of claim 49 further comprising:

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

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

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

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

54. The method of claim 47 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:

(d) removing the other path.

55. The method of claim 47 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.

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

57. The method of claim 47 wherein the change queue is a change log.

58. The method of claim 47 wherein the change queue is an audit trail.

59. The method of claim 47 wherein the change queue is a database of changes.

60. A method of replicating transaction data from a source database to a target database, an applier being associated with the target database, the applier having a maximum transaction threshold limit, the applier normally posting transaction data to the target database only upon receipt of a commit step or operation associated with respective transaction data, the method comprising:

(a) detecting whether the maximum transaction threshold limit of the applier has been reached, and, if so;

(b) prematurely conducting a commit step or operation on at least some of the transaction data in the applier, thereby causing the transaction data to become posted to the target database and deleted from the applier.

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

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

62. The method of claim 60 further comprising:

(c) the applier starting a new transaction upon receipt of a modification to a prematurely committed transaction.

63. The method of claim 60 wherein the maximum transaction threshold limit is the maximum transaction threshold capacity.

64. The method of claim 60 wherein the maximum transaction threshold limit is the maximum number of change events allowed to exist in the applier for a single transaction.

65. The method of claim 60 wherein the maximum transaction threshold limit is the maximum elapsed timespan of a transaction.