I'm trying to get setup using SymmetricDS 3.12.8. I'm having trouble with initial loads and reverse initial loads.
Trying to keep things relatively simple, I have two servers, a parent and a child. I have a handful of tables that I want to sync both on initial load as well as a reverse initial load. I've installed the necessary triggers (via inserts into sym_trigger) and their associated sym_trigger_router entries. on sym_trigger_router, I've inserted records with router_ids specifying both directions as well as a non-negative initial load order.
Additionally, I've set auto.reload and auto.reload.reverse to true in my symmetric.properties file in the following permutations bc the documentation was a little unclear: I.e. I've set both properties for both nodes, for only the parent and for only the child the same outcome.
My understanding is that by default, the reverse load is supposed to happen first. what appears to happen though, is that a record from the parent is synced to the child, which is then recorded as a change and synced back to the parent, causing a primary key conflict. while the record I wanted to sync from child to master, isn't synced. does this sound like a problem with my configuration, initial and reverse reloads, both, or none of the above?
What other info can I provide? this has been driving me mad.
Thanks!
Justin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A record sent from parent to child will get captured, but it won't route it back to parent by default. It knows the record came from parent, so it won't route it back there unless you turn on settings like ping back.
It does look like the initial load and reverse load originally happened one at a time. There is even a parameter called initial.load.reverse.first to determine which one goes first. It looks like now that both loads happen at the same time, which may have been an unintentional change.
Instead of using parameters, you can control the loads using the sym_table_reload_request and track the status in sym_table_reload_status.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm trying to get setup using SymmetricDS 3.12.8. I'm having trouble with initial loads and reverse initial loads.
Trying to keep things relatively simple, I have two servers, a parent and a child. I have a handful of tables that I want to sync both on initial load as well as a reverse initial load. I've installed the necessary triggers (via inserts into sym_trigger) and their associated sym_trigger_router entries. on sym_trigger_router, I've inserted records with router_ids specifying both directions as well as a non-negative initial load order.
Additionally, I've set auto.reload and auto.reload.reverse to true in my symmetric.properties file in the following permutations bc the documentation was a little unclear: I.e. I've set both properties for both nodes, for only the parent and for only the child the same outcome.
My understanding is that by default, the reverse load is supposed to happen first. what appears to happen though, is that a record from the parent is synced to the child, which is then recorded as a change and synced back to the parent, causing a primary key conflict. while the record I wanted to sync from child to master, isn't synced. does this sound like a problem with my configuration, initial and reverse reloads, both, or none of the above?
What other info can I provide? this has been driving me mad.
Thanks!
Justin
A record sent from parent to child will get captured, but it won't route it back to parent by default. It knows the record came from parent, so it won't route it back there unless you turn on settings like ping back.
It does look like the initial load and reverse load originally happened one at a time. There is even a parameter called initial.load.reverse.first to determine which one goes first. It looks like now that both loads happen at the same time, which may have been an unintentional change.
Instead of using parameters, you can control the loads using the sym_table_reload_request and track the status in sym_table_reload_status.