>> it filled up disk space on the Qlik Server, making the Qlik console unreachable.
As @Steve_Nguyen indicates, Replicate does not typically 'suck up' the whole Redo log but reads and reads until it sees a commited transaction on source and commits that 'chunk'. Now if it can read much faster than it can store on target then Replicate will aggregate more and more, possibly too much - after some time.
Where did the files go and how much and how quickly ? Gigabytes or Terabytes? Hours or minutes? On Windows you may want to use a tool like 'TreeSizeFree' to get a quick resolution?
Where they perhaps Replicate Log files in the log directory suggesting many errors and a high LOGLEVEL which may be fine for DEV but not expected in PROD. Where they in the per-task sorter area? You mention 'tasks' - plural. Are they all reading the same source? Have you considered a LOGSTREAM task to have them share the source REDO reading? Can you resume one task at a time?
- Is there a single or just a few very large transactions doing the migration? Replicate Tasks would have to stage those in the Sorter directory until a 'Commit' is seen. No choice. You may need to redesign the upgrade to commit in smaller increments, or run fewer tasks such that they do not all stage at the same time.
- Is your replicate DATA directory on the 'C:' drive in PROD (or DEV)? It shouldn't be! Move it.
- Did you implement "High Disk Space Utilization Threshold" in Prod? You should! Server --> Resource Control -->
Disk Space
- With Terabytes of changes to be read, and processed, could it be quicker and easier to just reload the targets?
Good luck,
Hein
