The multi-tier data redundancy model has one top-level master database and multiple replica databases below it. The replica databases can be updated but the replica data is always tentative until it has been committed in the master database. A replica database can act as a master database to other replica databases that are lower 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 multi-tier data redundancy model is based on the following principles:
▪ For each data item, there is one master version that is considered the official version of the data. Other copies of the item are tentative versions, that is, replica versions.
▪ A replica database can act as a master database to other databases. A replica database that is also a master database contains a subset (or a full set) of the data in its own master database.
▪ Data in each database of the system can be updated.
▪ Modifications that are made directly in 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 replica databases.
In a multi-tier synchronization environment, synchronized databases can be configured to serve a dual role as both a master database and a replica database. These roles are established by creating a catalog and defining it to be both a replica catalog and a master catalog.
Basic two-tier architecture
The simplest implementation of the multi-tier redundancy model is a two-tier synchronization architecture as shown in the following diagram. In a two-tier architecture, there is a top-level master database and one or more replica databases below it.
Transactions are always sent to the master databases, where they are committed. The data that is changed in the master database is then sent to the replica databases.
Advanced multi-tier architecture
A more advanced implementation of the multi-tier redundancy model enables information flow in more than two tiers by using replica databases that are also master databases to other replica databases that are below them in the hierarchy. Such an 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 servers.
Note The term many-tiered is used to describe systems that have three or more tiers, that is, systems that have servers that are both master databases and replica databases. The term multi-tier is used 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 top-level master database. The overall lifecycle of a transaction is extended from the moment that the transaction is committed in the replica database to the moment of that the transaction is committed in the master database. During this phase, activities can occur within an application that can invalidate a transaction that has already been committed in the replica database. Thus, all transactions that are to be propagated to the master database must include 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, see Intelligent Transactions.
Transactions that are committed in a replica database are propagated only to the master database, and not directly to other replica databases. Instead, the other replica databases can request changed data from the master database by requesting refreshes from one or more publications.
