|
|
Sometimes Connx data files or queue files are corrupted and get deleted. In those cases, the target DB loses synchronization from the source Adabas.
The only currently available solution is to do an Initial State for Adabas files that were touched before, which for our larger files can take days, and for all our files can take months.
We already have the Adabas PLOG that we can analyze to get the PKs (usually ISNs) of rows that were changed recently, so if we only had a tool that would allow us to supply a file ID and a list of PKs to "retransmit", we could sleep well at night even knowing that Connx might lose its queue or data files again.
The meaning of "retransmit" here is to cause Connx to enqueue replication commands for those ISNs with a flag that tells CNXREP “always override what’s currently in the target database” (so if a deleted row already doesn’t exist, that’s not an error and there's no need to do anything, and if a created row already exists, update it or delete and then create it).
Of all the Aha! requests I submitted today, this one is by far the most important to us.
| Use Case | Replication |
We have a feature on the CONNX roadmap with a working name of "Restart Replication from point in time". It is still in the planning phase and need more research to be able to deliver the best solution that will work for all customers. In summary the intent is the same, restart replication from a point in time where the replication status is known.
Can we please have a discussion about this one? It's very important to us, it addresses a major pain that already resulted in days of production downtime.