MIMIX Replicator for AS/400
MIMIX Replicator consists of two products, MIMIX DB2 Replicator for AS/400 and MIMIX Object Replicator for AS/400. These two products provide real-time replication of DB2/400 data and all other non-database objects including application objects, system objects, configuration objects, document library objects and integrated file system objects. MIMIX DB2 Replicator and Object Replicator share product libraries, configuration elements, message logs, menus, data groups and data libraries which greatly simplify implementation and ongoing management of the availability management environment. While these products can be used separately, the tight integration of these components enables centralized management, automatic broadcast of configurations and switchover for your AS/400 environment.
MIMIX Replicator processes operate on both the production and backup systems to optimize use of computing resources with the lowest overhead rates, while achieving high volume replication.
Core processes of MIMIX Replicator include:
SEND
Captures changes to database and system-objects in real time, and sends them to one or more backup systems. MIMIX DB2 Replicator uses journaling to recognize database modifications and supports replication of data areas. MIMIX Object Replicator uses the security audit journal to recognize object modification events and also supports replication of data queues. Both data and object changes are moved off of the primary system as quickly as possible to ensure the highest levels of data and application currency.
- Filtering ensures that only the changes that absolutely need to be replicated are replicated. Filtering can be performed either on the sending system or the receiving system which allows companies to optimize their CPU and communications resources, auxiliary storage use and performance on the clustered systems.
- Performance stamps recorded during the Send process and followed throughout the replication cycle are used to identify performance bottlenecks and communication capacity shortfalls. Timestamping is important for any recovery actions that might need to be either automatically or manually invoked.
- Event-driven Cooperative Processing for new or changed physical files allows MIMIX Object Replicator to automatically enroll database files into MIMIX DB2 Replicator for data replication, while MIMIX Object Replicator manages the existence and attributes of the file.
RECEIVE Collects transactions and object changes from the Send process, and stores and manages them on the backup system for processing by the Apply process.
- Staging allows information to be pushed off the sending system as quickly as possible, while allowing independent processing on the secondary system. This assures both information currency and operational flexibility on the backup system.
- Variable-length logspace entries make the most efficient use of available CPU and DASD resources.
- Automatic journal and log management minimizes auxiliary storage usage.
APPLY Reads all transactions and updates of secondary system(s) on either a real-time or scheduled basis.
- Data group file entry manages file name aliases, defines files down to the member level, and locks files during the Apply process for maximum configuration flexibility and to prevent them from becoming unsynchronized.
- Logspaces provide a powerful storage and manipulation mechanism that allows for easy management, usability and flexibility, achieves greater performance and reduces DASD, while protecting against data loss in the event of a production system outage.
- Replication history kept on both the production and backup systems provides accurate information on the object replication process even after a system failure, and ensures smooth switchover and restore processes.
- Objects in Error view provides error information and allows delete and retry options for ongoing object integrity. A command interface also allows automation of error resolution.
- Automatic retry is used when objects are not available for replication. If an object being replicated is in use by another application, the replication process will automatically delay the request and try again later before failing the request. Both short and long retry intervals are configurable making it possible for the replication process to proceed without operator intervention thus reducing operational costs.