MIMIX relies on data recorded by the IBM i functions of journaling, remote journaling, and object auditing. Each of these functions record information in a journal. Variations in the replication process are optimized according to characteristics of the information provided by each of these functions.
Journaling is the process of recording information about changes to user-identified objects, including those made by a system or user function, for a limited number of object types. Events are logged in a user journal. Optionally, logged events in a user journal can be on a remote system using remote journaling, whereby the journal and journal receiver exist on a remote system or on a different logical partition.
Object auditing is the process by which the system creates audit records for specified types of access to objects. Object auditing logs events in a specialized system journal (the security audit journal, QAUDJRN).
When an event occurs to an object or database file for which journaling is enabled, or when a security-relevant event occurs, the system logs identifying information about the event as a journal entry, a record in a journal receiver. The journal receiver is associated with a journal and contains the log of all activity for objects defined to the journal or all objects for which an audit trail is kept.
Journaling must be active before MIMIX can perform replication. MIMIX uses the recorded journal entries to replicate activity to a designated system. Data group entries and other data group configuration settings determine whether MIMIX replicates activity for objects and whether replication is performed based on entries logged to the system journal or to a user journal. For some configurations, MIMIX uses entries from both journals.
Journal entries deposited into the system journal (on behalf of an audited object) contain only an indication of a change to an object. Some of these types of entries contain enough information needed by MIMIX to apply the change directly to the replicated object on the target system, however many types of these entries require MIMIX to gather additional information about the object from the source system in order to apply the change directly to the replicated object on the target system.
Journal entries deposited into a user journal (on behalf of a journaled file, data area, data queue, or IFS object) contain images of the data which was changed. This information is needed by MIMIX in order to apply the change directly to the replicated object on the target system.
When replication is started, the start request (STRDG command) identifies a sequence number within a journal receiver at which MIMIX processing begins. In data groups configured with remote journaling, the specified sequence number and receiver name is the starting point for MIMIX processing from the remote journal. The IBM i remote journal function controls where it starts sending entries from the source journal receiver to the remote journal receiver.
IBM i requires that journaled objects reside in the same auxiliary storage pool (ASP) as the user journal. The journal receivers can be in a different ASP. If the journal is in a primary independent ASP, the journal receivers must reside in the same primary independent ASP or a secondary independent ASP within the same ASP group.
MIMIX fully supports the IBM i maximum limit of 10,000,000 objects to one user journal. User journaling will not start if the number of objects associated with the journal exceeds the journal maximum. The maximum includes:
-
Objects for which changes are currently being journaled
-
Objects for which journaling was ended while the current receiver is attached
-
Journal receivers that are, or were, associated with the journal while the current journal receiver is attached.
Remote journaling requires unique considerations for journaling and journal receiver management. For additional information, see Journal receiver management.