Synchronous database replication with asynchronous transaction recovery
A disaster-recovery system contains a networked array of synchronous-to-asynchronous converter (SATC) modules that connect source databases to target backup databases. During backup, the system replicates each source-database transaction through a chain of these SATCs to a corresponding target, storing a local copy of the transaction on each SATC along the way. Each transaction's path between its source-target pair is identified by a set of tracking entries, where each entry identifies one SATC in the path. Every backup transfer between two SATCs in a chain is performed synchronously, such that a successor SATC confirms a successful transfer to a predecessor SATC only after the successor can confirm a successful transfer to the next SATC in the chain. During a subsequent recovery operation, tracking entries are regenerated to locate locally stored transactions that had not time to be fully replicated before a catastrophic failure had occurred.
1. A disaster-recovery system comprising a processor, a memory coupled to the processor, and a computer-readable hardware persistent-storage device coupled to the processor, the persistent-storage device containing program code configured to be run by the processor via the memory to implement a method for synchronous site-consolidated data backup with synchronous-to-asynchronous traffic conversion, the method comprising:
the processor detecting that a transaction has been performed upon a source database;
the processor identifying a networked backup path, from the source database to a target database, through which each transaction performed on the source database is replicated to the target database,
where each node on the backup path hosts a distinct SATC (Synchronous-to-Asynchronous Converter) module, of a plurality of SATC modules, that stores a copy of any replicating transaction that passes through the distinct SATC module while traversing the backup path, and
the processor creating a set of tracking entries for the detected transaction,
where the set of tracking entries identifies each SATC hosted by a node of the backup path and associates the detected transaction with the source database, with the target database, and with each SATC hosted by a node of the backup path;
the processor receiving a copy of the detected transaction from a predecessor SATC;
the processor confirming that the detected transaction has been locally stored in a successor SATC hosted by a node that immediately follows the predecessor SATC's node along the backup path; and
the processor accepting from the successor SATC confirmation that the successor SATC has in turn accepted confirmation, from a next SATC along the backup path, that the next SATC has successfully received the detected transaction from the successor SATC, and then locally stored the detected transaction.
2. The disaster-recovery system of claim 1 , further comprising:
the processor notifying the predecessor SATC that the detected transaction has been successfully stored by both the predecessor SATC and the successor SATC.
3. The disaster-recovery system of claim 2 ,
where each tracking entry of the set of tracking entries identifies:
the detected transaction,
one SATC, hosted by a node of the backup path, through which a copy of the detected transaction must be replicated in order for the detected transaction to reach the target database, and
a distinct network node of the backup network that hosts the one SATC.
4. The disaster-recovery system of claim 2 , further comprising:
the processor excluding from the set of tracking entries a tracking entry that the processor has already included in a previously created set of tracking entries.
5. The disaster-recovery system of claim 2 , further comprising:
the processor excluding from the set of tracking entries a questionable tracking entry that has not had sufficient time to be replicated from the source database an SATC identified by the questionable tracking entry.
6. The disaster-recovery system of claim 5 , where the processor excludes the questionable tracking entry because the questionable tracking entry identifies an erroneous transaction of the source database and insufficient time has elapsed for a correction to the erroneous transaction to have been replicated from the source database to the SATC identified by the questionable tracking entry.
7. The disaster-recovery system of claim 1 , where the receiving, the storing, the forwarding, the accepting, and the notifying are propagated through all SATCs hosted by nodes on the backup path until the detected transaction has been stored in a local persistent-storage area of the target database.
8. A method for synchronous site-consolidated data backup with synchronous-to-asynchronous the processor detecting that a transaction has been performed upon a source database;
the processor identifying a networked backup path, from the source database to a target database, through which each transaction performed on the source database is replicated to the target database,
where each node on the backup path hosts a distinct SATC (Synchronous-to-Asynchronous Converter) module, of a plurality of SATC modules, that stores a copy of any replicating transaction that passes through the distinct SATC module while traversing the backup path, and
the processor creating a set of tracking entries for the detected transaction,
where the set of tracking entries identifies each SATC hosted by a node of the backup path and associates the detected transaction with the source database, with the target database, and with each SATC hosted by a node of the backup path;
the processor receiving a copy of the detected transaction from a predecessor SATC;
the processor confirming that the detected transaction has been locally stored in a successor SATC hosted by a node that immediately follows the predecessor SATC's node along the backup path; and
the processor accepting from the successor SATC confirmation that the successor SATC has in turn accepted confirmation, from a next SATC along the backup path, that the next SATC has successfully received the detected transaction from the successor SATC, and then locally stored the detected transaction.
9. The method of claim 8 , further comprising:
the processor notifying the predecessor SATC that the detected transaction has been successfully stored by both the predecessor SATC and the successor SATC.
10. The method of claim 9 ,
where each tracking entry of the set of tracking entries identifies:
the detected transaction,
one SATC, hosted by a node of the backup path, through which a copy of the detected transaction must be replicated in order for the detected transaction to reach the target database, and
a distinct network node of the backup network that hosts the one SATC.
11. The method of claim 9 , further comprising:
the processor excluding from the set of tracking entries a tracking entry that the processor has already included in a previously created set of tracking entries.
12. The method of claim 9 , further comprising:
the processor excluding from the set of tracking entries a questionable tracking entry that has not had sufficient time to be replicated from the source database to local persistent storage of an SATC identified by the questionable tracking entry,
where the processor excludes the questionable tracking entry because the questionable tracking entry identifies an erroneous transaction of the source database and insufficient time has elapsed for a correction to the erroneous transaction to have been replicated from the source database to the local persistent storage of the SATC identified by the questionable tracking entry.
13. The method of claim 8 , where the receiving, the storing, the forwarding, the accepting, and the notifying are propagated through all SATCs hosted by nodes on the backup path until the detected transaction has been stored in a local persistent-storage area of the target database.
14. The method of claim 8 , further comprising providing at least one support service for at least one of creating, integrating, hosting, maintaining, and deploying computer-readable program code in the computer system, wherein the computer-readable program code in combination with the computer system is configured to implement the detecting, the identifying, the creating, the receiving, the confirming, and the accepting.
15. A computer program product, comprising a computer-readable hardware storage device having a computer-readable program code stored therein, the program code configured to be executed by a disaster-recovery comprising a processor, a memory coupled to the processor, and a computer-readable hardware storage device coupled to the processor, the storage device containing program code configured to be run by the processor via the memory to implement a method for synchronous site-consolidated data backup with synchronous-to-asynchronous traffic conversion, the method comprising:
the processor detecting that a transaction has been performed upon a source database;
the processor identifying a networked backup path, from the source database to a target database, through which each transaction performed on the source database is replicated to the target database,
where each node on the backup path hosts a distinct SATC (Synchronous-to-Asynchronous Converter) module, of a plurality of SATC modules, that stores a copy of any replicating transaction that passes through the distinct SATC module while traversing the backup path, and
the processor creating a set of tracking entries for the detected transaction,
where the set of tracking entries identifies each SATC hosted by a node of the backup path and associates the detected transaction with the source database, with the target database, and with each SATC hosted by a node of the backup path;
the processor receiving a copy of the detected transaction from a predecessor SATC;
the processor confirming that the detected transaction has been locally stored in a successor SATC hosted by a node that immediately follows the predecessor SATC's node along the backup path; and
the processor accepting from the successor SATC confirmation that the successor SATC has in turn accepted confirmation, from a next SATC along the backup path, that the next SATC has successfully received the detected transaction from the successor SATC, and then locally stored the detected transaction.
16. The computer program product of claim 15 , further comprising:
the processor notifying the predecessor SATC that the detected transaction has been successfully stored by both the predecessor SATC and the successor SATC.
17. The computer program product of claim 16 ,
where each tracking entry of the set of tracking entries identifies:
the detected transaction,
one SATC, hosted by a node of the backup path, through which a copy of the detected transaction must be replicated in order for the detected transaction to reach the target database, and
a distinct network node of the backup network that hosts the one SATC.
18. The computer program product of claim 16 , further comprising:
the processor excluding from the set of tracking entries a tracking entry that the processor has already included in a previously created set of tracking entries.
19. The computer program product of claim 16 , further comprising:
the processor excluding from the set of tracking entries a questionable tracking entry that has not had sufficient time to be replicated from the source database to local persistent storage of an SATC identified by the questionable tracking entry,
where the processor excludes the questionable tracking entry because the questionable tracking entry identifies an erroneous transaction of the source database and insufficient time has elapsed for a correction to the erroneous transaction to have been replicated from the source database to the local persistent storage of the SATC identified by the questionable tracking entry.
20. The computer program product of claim 15 , where the receiving, the storing, the forwarding, the accepting, and the notifying are propagated through all SATCs hosted by nodes on the backup path until the detected transaction has been stored in a local persistent-storage area of the target database.