The multitier data redundancy model has one top-level master database and multiple replica databases below it. The replicas are updatable but the replica data is always tentative until it has been committed to the master database. A replica can act as a master to some other replica below it in the hierarchy.
This model allows implementation of a bidirectional asynchronous data synchronization mechanism between databases in a way that fully addresses the database consistency and scalability issues of a multi-database system.
The multitier data redundancy model is based on the following principles:
▪For each data item, there is one master version considered the official version of the data. Other copies of the item are tentative versions, that is, replicas.
▪A replica can act as a master to other replicas below it. A replica that is also a master contains a subset (or a full set) of the data in the master version above it.
▪Data in each database of the system is updateable.
▪Modifications made directly to a master database are official.
▪Transactions that are committed in a replica database are tentative until they have been successfully propagated to the master database and committed there.
▪Replica databases are refreshed by sending changed data from the master database to replicas.
In a multi-tier synchronization environment, synchronized databases can be configured to serve a dual role as both a master and a replica. These roles are established by creating a catalog and defining it to be both a replica and a master.
Basic two-tier architecture
The simplest implementation of the multitier redundancy model is a two-tier synchronization architecture as shown below. In a two-tier architecture, there is a top-level master database and multiple replica databases below it.
Transactions are always sent to the master databases where they are committed. The changed master data is then sent to the replicas.
Advanced multitier architecture
A more advanced implementation of the multitier redundancy model enables information flow in more than two tiers through replicas that are also masters to other replicas that below them in the hierarchy. Such a architecture is often used in a scenario that requires the flow of system information to local areas and information from various local areas to specific end nodes.
Note The term many-tiered is used to describe systems that have three or more tiers, that is, systems that have nodes that are both master and replica. The term multitier is sued to describe systems that have two or more tiers.
Transaction models in advanced replication setups
In both two-tiered and multi-tiered architectures, transactions that modify revalidated replica data are always tentative. A tentative transaction becomes official when it has been accepted in the master database. The overall lifecycle of a transaction is extended from the moment of replica commit to the moment of master commit. During this phase, activities can occur within an application that can invalidate a transaction that has already been committed by a replica. Thus, all transactions that are to be propagated to the master database need to have embedded in them sufficient validation logic to ensure the integrity of the master database.
To address the data integrity issues of a synchronized multi-database system, the advanced replication architecture provides a transaction model called intelligent transaction. With the intelligent transaction model, you can implement transactions that always leave the master database in a consistent state.
Note Transactions that are committed in a replica database are propagated only to its master database. These transactions are not propagated to other replicas directly. Instead, the other replicas can request changed data from a master database by requesting refreshes from one or more publications. A publication is a definition of a set of data on the master; replicas can refresh from a publication to get replica-specific data updates from the master.
