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!


  1. Set aside my effort to peruse all the remarks, however I truly delighted in the article. It's consistently pleasant when you can not exclusively be educated, yet in addition, engaged!

  2. This is a great motivational article. In fact, I am happy with your good work. They publish very supportive data, really. Continue. Continue blogging. Hope you explore your next post
    hrdf claimable courses

  3. You re in motivation behind fact an on-target site administrator. The site stacking speed is amazing. It kind of feels that you're doing a specific trick. What's more, The substance is a masterpiece. you have done a marvelous development concerning this issue!360DigiTMG Data Analytics Course

  4. Two full endorsement for this magnificent article of yours. I've genuinely refreshing scrutinizing this article today and I figure this might be uncommon contrasted with other articles that I've examined now. On the off chance that it's not all that much difficulty prop this work up on in a comparable quality.
    data science course in delhi


  5. Hey friend, it is very well written article, thank you for the valuable and useful information you provide in this post. Keep up the good work!


Powered by Blogger.