Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
I am working with a customer who is exploring Qlik Replicate to move data from Sybase to MS SQL. They already have a replication in place from Sybase to Sybase through an internal SAP platform. The main ask from the customer is to enable replication from Sybase to MS SQL without interrupting the exisiting Sybase to Sybase replication.
But as I can see, it is mentioned as part of General prereq that:
My understanding is, disabling the RepAgent will interrupt the exisiting replication. Pls correct my understanding. Request the community to suggest any workaround if available. Thanks!
Hello @akaradhya ,
Thanks for reaching out to Qlik Community!
I’m not sure whether the existing replication is set up for High Availability and Disaster Recovery (HADR). You can confirm this by running the following SQL:
select hadr_mode(),hadr_state()
If HADR is enabled, the RepAgent cannot be disabled on either the primary or companion servers, as doing so would interrupt the current replication. This would conflict with Qlik Replicate, since the RepAgent should remain inactive to allow Attunity to manage ASE DBCC (old) log transfer and truncation.
Personally, I see a few options:
Run a Full Load Only task (with Change Processing turned off) at scheduled intervals. This option won’t interfere with the source systems but is not suitable for real-time or near-real-time replication.
Add triggers on the source tables. This option may require changes to the source databases and could introduce some overhead.
Hope this helps.
John.
Hi @john_wang. There is no HADR setup at the customer location. Does this mean that, RepAgent doesn't need to be disabled and the new replication can take place?
Hello @akaradhya ,
Thank you for the update. If the RepAgent runs on the primary node and not on the slave node, perhaps the slave node could serve as the Qlik Replicate source database.
Anyway, the RepAgent must be disabled if the node is Qlik Replicate source database.
Regards,
John.