How do I decide between more journals and fewer?
One decision that many shops face when implementing a logical replication solution is how to figure out how many journals they should be using. Many times this decision is already made for them as the application itself has defined the journaling structure. If however you get to decide, here are some pros and cons of more journals.
A separate apply is started per group on the backup server per data journal. When you look at the WRKACTJOB SBS(XDMCLUSTER) on the backup display you see multiple jobs per group. The HADTUP task is the Match-Merge apply process that combines audit level changes and data level changes per journal per group. A separate journal is strategic to separating very active files potentially in their own apply process. A group that is suffering from apply latency can often improve apply performance by separating load into separate journals (and therefore separate apply processes).
Easier to manage if each application has its own journal, and you need to replay journal entries for an application.
More journals to manage, so deleting of receivers will be more effort, although this can be automated through DMWRKJRN.
If you ever have to manually set the position for a replication group, you have to determine the position for each journal and set them, so more journals = more steps to manually set position. Having said that, iCluster does a pretty good job of documenting the ending position when it ends and support is always ready to assist if this is necessary.
Slightly more difficult to monitor in the standard WRKHASMON or WRKHATMON as groups can span across multiple pages in the extreme use of journals, but the Position To field can help.
Slightly more resources required on the backup server as a separate apply thread is started per data journal and if local journaling is being used, a few more resources on the primary node for reading these receivers.
Consolidation is a good idea to simplify configuration. Partitioning load into separate journals can help performance.
[box type=”info”]Learn more about iCluster high availability[/box]