Search code examples
firebirdsymmetricds

Data Pass Through in SymmetricDS

I'm feeling a little stupid, and my searches for answers haven't yielded anyone else having this problem.

Imagine that I have NodeHQ, Node1 and Node2. I have created triggers to synchronize TableA between the 3 like so:

Node1 <---> NodeHQ <---> Node2

Node1 and Node2 have different subsets of data from each other. NodeHQ has administrative information from both nodes (subsets of both). Each of the 3 nodes is in a different NODE_GROUP.

Right now, with the triggers and routers I have setup, Inserting/Updating/Deleting a record at NodeHQ works at Node1 and Node2. However, if I make a change at Node1 or Node2, it only makes it to NodeHQ. It never passes through to the other.

So far I've tried:

  • Setting SYNC_ON_INCOMING_BATCH to 1 for the triggers involved, no change
  • Creating separate SYM_TRIGGER for each NODE_GROUP, no change
  • Using transforms to alter the record innocuously, no change
  • Deleting and then Inserting all of the rules, no change
  • Using Symadmin sync-triggers -f to force trigger recreation, no change

I've read the user guides up and down on this, and they are relatively unspecific about this. http://www.symmetricds.org/doc/3.6/user-guide/html/advanced.html#bi-direction-sync

Right now, all of the nodes have SYNC_ENABLED=1. All of the SYM_TRIGGERs are set for SYNC_ON_INCOMING_BATCH=1. My SYM_ROUTERs are all set to SYNC=1, and are using ROUTER_TYPE='default'. I'll be honest, I've tried a lot of other small things, but nothing seems to make it pass on data to the next NODE_GROUP. I'm running out of ideas.

Their own documentation indicates that SYNC_ON_INCOMING_BATCH makes it so that trigger passes data onto other nodes at each place it arrives. So far though, my changes to that have yielded nothing. What's left to try? Or what do you think I should do?

I am using Firebird 2.52 and SQL Dialect 1.

Solution

  • So in running version 3.7.19 of SymmetricDS in debug, I discovered the triggers weren't being regenerated properly in most circumstances that I was changing SYM tables. Whenever I changed the rules, the logs indicated it was remaking relating triggers.

    The solution: Running symadmin sync-triggers -f on every engine. This forces every single trigger to be regenerated, and it seems to have fixed this. I'll definitely track this down to help the developers nip it in the bud.