Three Tier Replication Done in Two Tiers

One of the most common replication patterns we see here at JumpMind is a three tier setup with a central, regional, and site group.  Retailers commonly use this approach with groups named: corp, store, and register.   However we often see setups that try to reduce this approach down to two tiers with a similar set of functionality.  Deciding between a two or three tier approach can be tricky and each may have advantages and disadvantages based on your needs.  This article will help to explain these differences and hopefully help in making the best design choice for your needs.

Three Tier

• Advantages
  • Designed for replication across geographical locations.
  • Allows subsetting of data to a specific middle tier (store) and lower.
  • Allows the lowest tier (register) to replicate with each other through their parent (store) using the sync on incoming feature.
  • Spreads performance across more systems.
  • Preferred approach for a larger number of child nodes.

• Disadvantages
  • Requires additional hardware and a database to support the middle tier (could be a performance advantage though).
  • Potential bottleneck at the middle tier with an outage or error.
  • Requires more SymmetricDS nodes.

 Two Tier

• Advantages
  • Designed for replication across geographical locations.
  • Allows subsetting of data to a specific middle tier (store) and lower.
  • Fewer SymmetricDS nodes
  • Reduces hardware cost and setup
  • Eliminates middle tier bottleneck from an outage or error

• Disadvantages
  • Requires more SymmetricDS setup.
  • Peer to peer replication within group 1 goes through the top tier.
  • Performance is spread between two tiers only.
  • May need to be clustered at the central node or converted to a 3 tier once the number child number of nodes impacts performance.

Three Tier Configuration Overview

Basic

• Create three node groups named appropriately for your use case.
• Create the group links and default routers between these groups in each direction (even if data is not being moved, configuration and heartbeats will need them).
• Setup the tables that will replicate between each tier and in each direction (quick config wizard)

Advanced

• Create non default routers to subset data from top tier to middle tiers and lower (column match router).
• Create a separate set of triggers for the middle tier that will use the sync on incoming feature to replicate from a third tier node to its peers under the same parent.

Two Tier Configuration Overview

Basic

• Create two node groups named appropriately for your use case.
• Create the group links and default routers between these groups in each direction (even if data is not being moved, configuration and heartbeats will need them).
• Setup the tables that will replicate between each tier and in each direction (quick config wizard)

 Setup a two tier to behave like a three tier

• Set the following parameter to false: external.id.is.unique.enabled=false
  • This allows external id’s to be reused and provides a way to group nodes based on the same external id
• Set the following parameter one of two ways to control how Node IDs are created.

  1. node.id.creator.script=remoteHost

     • This uses the hostname of the remote node as the NodeID

  2. node.id.creator.script=node.getSchemaVersion();

     • This uses the property schema.version in the engine property file on the remote node as the NodeID

• While setting up new nodes for the second tier set the external ids to the same value that belong to the same group (store or site).  This is what replaces the need for the middle tier.

Example 

• Use a column match router type with the expression STORE_ID = :EXTERNAL_ID to subset data going from the corp to a register.  This assumes the table(s) associated with this router all have a STORE_ID column with a value that matches your NodeID