Configuring Multidirectional Replication

Multidirectional replication assumes that data is replicated between two (bi-directional) or more locations in both directions, and end users (applications) modify data on both sides. For more information on different Fivetran HVR replication types, see Replication Topologies.

For the list of locations, on which bi-directional replication is supported, refer to the relevant section in Capabilities.

Channel Setup for Multi-Directional Replication

The steps described in this section are applicable for both bi-directional and multidirectional replication.

By default, all locations in a multidirectional channel will be added to a single location group named SOURCE_TARGET with the Capture and Integrate actions defined on that group. Any changes made to any of the locations will be propagated to all the other locations within the channel.

The following steps include configuring multi-directional replication with three Oracle locations in the HVR user interface.

1. Create three Oracle locations app1, app2, and app3. Follow the procedure described on the page Creating Location for each of the locations.

2. Define a channel for the replication: right-click Channel Definitions and select New Channel and enter the name of the channel chn. Click OK.

   1. Navigate to the left sidebar and click CHANNELS.
   2. On the Channels page, click Create Channel at the top right.
   3. On the Create New Channel page, under Select Channel Type, click Multidirectional.
      
   4. Under Select Locations, select locations app1, app2, and app3. Click Confirm Locations. 
      
   5. Click Save Channel and Continue.
   6. Specify the channel name and, optionally, the description of the channel.
      
   7. Click Select Tables to add tables to the channel.
      
   8. In the table selection dialog, select the required tables and click Save. For more information on different options and filters for selecting tables, see section Adding Tables to a Channel.
      

3. Confirm table selection.
   

4. Click Complete Channel Creation. This will activate replication, lunch the refresh, and start capture and integrate jobs in the channel.

   • To manually configure custom activation components, click Replication Activation Options. This will open the Replication Activation Options dialog, in which you can set up the activation parameter as required. For detailed information about each activation component, see section Components for Activating Replication.
   • To define additional actions for the channel, unselect the Activate replication option. See section Additional Configuration for Multidirectional Channel.
   • To suspend the start of capture and integrate jobs, unselect the Start Replication Jobs.

   You can activate the replication, run the refresh, and start the replication jobs manually later.

   

Additional Configuration for Multidirectional Channel

• Parameter OnErrorSaveFailed of action Integrate allows HVR to continue replication when errors occur. The error message including the row causing the failure is stored in the fail table tbl_f and can be investigated afterwards (see command hvrretryfailed). The errors will also be written to the log file.

• There can be collisions in a multidirectional replication environment. For example, users in different databases may update the same row at the same time, or a row may be updated in one database and deleted in another database. If collisions happen, then the end result may be that your databases get out of sync. HVR provides a sophisticated collision detection capability (action CollisionDetect) that will ensure that the most recent change to a row always wins and systems remain in sync. In the CollisionDetect dialog select option TimestampColumn and select the timestamp column in the replicated tables for collision detection. A timestamp column should be manually added beforehand to each replicated table in the multi-directional channel. Consider using action CollisionDetect only on tables with a reliable timestamp column that accurately indicates when the data was last updated.

  In some multi-directional replication environments, the collisions may be prevented at the application level (using customers' own application partitioning), thus avoiding the need to use action CollisionDetect.