Data Propagation Paths in the CDDS
Replicator moves information from one database to another according to the data propagation paths for that CDDS. In a data propagation path, a database can be one of the following three types:
Originator
The database where a user made a change to a replicated table.
Local
The database that propagates the change to the target.
This is the last database that the change goes through before reaching the target. The local database can be the same as the originator database. A local database must be a target database in another path (it must receive the data as a target) before it can propagate the data as a local database.
Target
The database that receives the change.
Every database in the CDDS must be a target (except the originator in that particular path). The target and the originator database cannot be the same in a given path.
Example: Data Propagation Path
In the R.E.P. scenario described in
CDDS Example: Subset of Tables, several databases are allowed to manipulate data. Paths must be defined for each originating database. To do this, a separate data propagation path is defined for each CDDS that resides on an originating database. The path itself consists of separate entries for each target of the originating database.
Here is the example for CDDS 1 in San Francisco, which is set up to transmit inventory information to New York and London.
Data Propagation Paths for CDDS 1 in San Francisco:
Note that the local database is part of all path definitions. It is used to differentiate between a direct and indirect path to a target. In the first entry of the example, the originator and local databases are both SFO; this refers to the start of the replication path. In the second entry, the originator and local databases differ; this indicates that the local database, NYC, is responsible for cascading replication to the target, LON. As a result of cascades, a data propagation path can run through many databases.
Data Propagation Paths for CDDS 1 in New York:
Note that in this example, New York sends inventory data directly to San Francisco and London. The choice between the cascading paths in the SFO example and the direct paths in the NYC example can be influenced by various factors, such as communications infrastructure, transaction volumes at each site, and processor capacities.
Remember that a CDDS is simply a piece of a larger database. These individual pieces can reside at any site in an enterprise. In the R.E.P. scenario, international sales information (CDDS 5) from Hong Kong does not get copied to the master database in New York. Thus, no path definition for Hong Kong to New York for CDDS 5 is required. The New York inventory CDDS (CDDS 1) maintains the same standard, sharing only with the necessary remote sites.
Last modified date: 04/03/2024