Skip to Main Content
HCL Domino Ideas Portal

Welcome to the #dominoforever Product Ideas Forum! The place where you can submit product ideas and enhancement request. We encourage you to participate by voting on, commenting on, and creating new ideas. All new ideas will be evaluated by HCL Product Management & Engineering teams, and the next steps will be communicated. While not all submitted ideas will be executed upon, community feedback will play a key role in influencing which ideas are and when they will be implemented.

For more information and upcoming events around #dominoforever, please visit our Destination Domino Page

Status No Plans to Implement
Workspace Domino
Categories Administration
Created by Guest
Created on May 3, 2021

Feasibility for parallel replication of DBs by multiple replica threads to one destination server through connection document.

When the connection document is set to replicate multiple DBs (around hundreds of Dbs) with one destination server, only one replica thread(even though multiple replica tasks running) will perform replication of all databases one after another.
There are some scenarios when a large amount of data is added in a DB then the replica task takes more time (a couple of hours) to finish the replication of the target database and the remaining databases will be in the waiting queue of the replicator thread.

It would be a great help if multiple replica threads continue to perform replication of multiple databases on one connection document even though the destination server is same.
So that parallel replication of databases can be performed by multiple replicator threads set on the server.


  • Attach files
  • Admin
    Thomas Hampel
    Reply
    |
    Jan 23, 2022

    The limiting factor is network bandwidth/latency, running multiple threads will not (or just minimally) improve the throughput.

  • Guest
    Reply
    |
    Jul 12, 2021

    be careful what you wish :-) This might easily clog your network connection, e.g. to branch offices or result in too much IO activity for the target server.


    Basically, the idea is not bad. It should be possible to set the maximum number of concurrent replications AND somehow categorize the databases by size.

    If you have a mix of some large databases and a couple of smaller ones, parallel replication would not have much effect. If the limit is set to 2 and two of the large databases replicate for hours, the smaller ones still had to wait for hours.

    There should be a way to have (depending on replicator count) one part replicate the large ones and others can replicate the smaller ones in parallel, starting with the smallest.

  • Guest
    Reply
    |
    May 3, 2021

    Currently Replicator task work like , when you enable two replicators, and the server only needs to replicate with one other server, then only one replicator is used. The other task remains idle.