The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section. Similarly, unless otherwise indicated, it should not be assumed that a problem has been recognized by the prior art merely because the problem is discussed in this section.
An N-way distributed system refers to a set of computer systems, which may be a database system or file-based computer, where each computer shares information with all of the other computer systems via data streams transmitted over one or more network connections. A “source” computer may transmit a data stream to a “destination” computer, for example, to replicate changes, which occurred within the source database, from the source database to the destination database. Each of the source and the destination computers independently maintains its own sequence of SEQs, an ordered set of monotonically increasing values associated with events that indicate the order of events relative to each other. The SEQs serve as the logical clock of a computer system. A well-known algorithm for imposing a partial order on events in a distributed system is a Lamport Clock.
However, there is no easy way to synchronize the SEQ of a source computer (which produces a data stream) to the SEQ of a destination computer, which “consumes” or applies the data stream. Consequently, after a crash of the source computer, to recover the source computer from data at the destination computer, the SEQs are not very useful in narrowing the time period associated with the destination database system or in otherwise reducing the time required for performing a point in time recovery from the data at the destination computer. Additionally, there may be a varying lag between the application of changes at the source database system and at the destination database system. Consequently, the SEQs of the destination database system and time stamps are also not adequate for determining a time period at the destination database system associated with the loss of data at the source database system. As a result, inefficient ways of performing point in time recovery are resorted to, such as to re-instantiate the source database system or to do a complete recovery, which is very expensive in terms of time and resources. At times, a complete recovery may not even be possible.
In view of the above, there is a need for a method of performing a point in time recovery that uses less resources and/or time to recover from data at another database system.