“Log Stream Staging TASK” and ‘Replication TASK’ stop order

[iti-attunity-sup]

We are currently configuring a log stream staging TASK and a replication TASK that uses that log stream as a source.

We plan to reboot the OS every month and would like to stop the tasks beforehand,
Are there any recommendations or cautions as to which task should be stopped first?

Best Regards

Hironori

[Dana_Baldwin · Accepted solution]

Hi @iti-attunity-sup 

The start order might be more relevant than the stop order, especially if the child/replication task is current - but honestly it shouldn't cause an issue either way when resuming the tasks. If starting from a timestamp, you would always start the parent / staging task first & use a timestamp a minute or so later on the child / replication task to ensure it picks up the new timeline.

Still, just following logic, I would stop the child/replication task first, then the parent/staging task, and resume them in the opposite order - first parent / stating task, then child / replication task. This ensures that new changes are available for the child / replication to read and prevent task warnings that it has reached the end of the timeline.

I hope this helps!

Thanks,

Dana

[VXS1031]

Agreed, Its the best practice to stop the Child first and then Parent to avoid the warnings. Resuming in reverse order Parent first and the child next.

[MoeE]

Hi Dana,

Just confirming that the timeline in both tasks should stay the same if you simply do a stop and resume of either the logstream task or the downstream task?

What's the logic behind stopping the downstream tasks first as opposed to stopping the logstream task first? Isn't there advantages to stopping the logstream task first? Such as in the scenario where you need to do maintenance on the QR server, you stop the logstream task first so that the downstream task can finish applying all changes to the target, then you stop the downstream tasks. The purpose of this is to allow the downstream task to apply all stored changes before stopping them, and if the logstream task continues to run, then it will keep applying changes. 

The task warnings that it has reached the end of the timeline shouldn't have negative effects (such as data loss) as long as we're doing stops and resumes of each task correct?

Regards,

Mohammed

[Dana_Baldwin]

Hi @MoeE 

Yes, a simple stop and resume of staging and replication tasks keeps the current timeline of the log stream files.

In your example where you prefer all changes read by the staging task applied by the replication tasks prior to stopping them, yes that is a correct process.

Honestly when stopping the tasks I can't imagine a disadvantage to stopping either the staging or replication tasks first. Any changes the staging task reads will remain in the log stream files until they are resumed (provided of course that the tasks are not stopped long enough for the log stream retention settings to expire). I think the reason I considered it logical to stop the child tasks first was simply to reach the state of all tasks stopped faster, I wasn't considering that you may want to minimize the pending changes stored in the log stream files when you stop the tasks.

I hope this helps!

Thanks,

Dana

[Dana_Baldwin]

@MoeE P.S. You are correct. The warning that a replication/child task has reached the end of the timeline does not indicate there is data loss, just that all the pending changes the staging/parent task has written to the log stream files has been processed. If that's an unexpected condition, please check the health of the staging/parent task.

[MoeE]

Hi Dana,

Yep, this makes sense. Thanks for the clarification    🙂

Regards,

Mohammed