Attunity Replication Topologies

Attunity Replicate supports the following topologies for replication tasks: 
  1. One to One
  2. Logical Independence
  3. Hub and Spoke
One to One: In a one-one topology, there is one source and one target endpoint. When the source and target endpoints are distinct, Attunity Replicate guarantees transactional integrity and consistency of data. If you use two different replication tasks, the endpoints may switch roles, allowing two-way synchronization. This is the most used topology in most organization.

 Caution: If the same row in a table is updated by two different replication tasks, the result of two-way synchronization may be unpredictable. A problem can occur even if two different rows are referentially related, that is if some application updates a row based on reading a value in a different row. If the rows are updated concurrently on the source and the target, the result may be unpredictable1 . Such occurrences are rare, but they can occur. 

Logical Independence: Two-way replication works best when updates of a row on a source and on a target are entirely autonomous and do not affect each other. There is an assumption that any table or a horizontal or vertical segment of a partitioned table can only be updated in one source. Attunity Replicate allows updating the same row in several places, but in this case, the columns being updated must be distinct. Another assumption is that if a data value in one row depends on or is derived from a value in another row, the values can be changed only on the same server but nowhere else (except by the Replicator). This is called logical independence. With logical independence, concurrent update conflicts cannot occur during replication. 

Hub and Spoke: Many-to-one and one-to-many relationships can be combined into a hub-and-spoke topology, which allows the merging of data into multiple targets and then distributing to other targets. It does not allow cycles or multiple paths for propagating changes. The huband-spoke topology is that of an acyclic directed graph. 1CDC has no way of knowing exactly when a row was read by an application on one system relative to its having been changed on another system. Read operations are typically not logged. 

Interested in working with me? I can be reached at pbaniya04[at] for any questions, consulting opportunities or you may drop a line to say HELLO. Thank your again for visiting my blog and looking forward to serving you more.

Have a Database-ious Day!

No comments

Powered by Blogger.