MATRIXX Transaction Logs

All database transactions are synchronously replicated across the processing cluster, logged to disk for durability, copied to shared storage for replication, and streamed to downstream engines for high availability purposes.

All database transaction events are streamed from the active publishing server to all MATRIXX Engine servers on all MATRIXX Engines. The streams contain the exact details of all updates made to the database and the processed event, so every server has sequential records of every processed transaction event that resulted in an update to the in-memory databases. The publishing servers use the streamed transaction events for audit trails, MATRIXX Event File (MEF) and Streamed Event File (SEF) generation, and event post-processing. The committed transactions can be replayed immediately by any of the standby processing servers in your MATRIXX environment, keeping them nearly synchronized with the active processing servers.

Out-of-the-box, MATRIXX periodically confirms that the databases on each engine blade and the databases in the active and standby engines contain the same transactions, within a configurable margin of error. For more information, see the discussion about confirming that servers and engines are synchronized.

Figure 1 illustrates transaction logs in MATRIXX Engine. MATRIXX Engine ensures database consistency using transaction logs and transaction log files.

Figure 1. MATRIXX Transaction Logs
MATRIXX Transaction Logs
As shown in Figure 1:
  1. The Charging Server on the active processing server of the active engine records a transaction record of every message it processes and forwards them to the transaction server.
  2. The MATRIXX Engine Transaction Server collects the transaction records into transaction logs and updates the local IMDB (${MTX_TXN_LOG_DIR}) and the in-memory databases (IMDBs) of the other processing servers and the publishing server to keep them synchronized.
    Note: The shadow logs from other processing servers in ${MTX_TXN_LOG_DIR}/staging/temp are not pictured.
  3. The active publishing server then converts the transaction logs in its IMDB into transaction log files in shared memory (${MTX_SHARED_DIR} by default). Immediately after the active publishing server confirms that the transactions in a Global Transaction Counter (GTC) range have been replayed on all servers, it deletes the transaction logs from the local SSD.
  4. At MATRIXX Engine start-up, the engine uses the updated publishing server IMDB (and the latest checkpointing file) to rebuild the IMDBs of the other processing and publishing servers. The publishing server then streams the same transaction events to all servers on all standby MATRIXX Engines sequentially (Not pictured).
  5. The checkpointing server uses the transaction log files from its IMDB to create checkpoint files that are stored in SAN.
  6. At MATRIXX Engine start-up, the engine combines the latest checkpoint file and the latest transaction log files to rebuild the IMDBs to their preceding state.
Note: The Transaction Server and logging create_config.info configuration questions apply to both transaction logs and transaction log files.
To sum, at start-up, MATRIXX Engine combines:
  • The latest checkpoint file from the checkpointing server.
  • The latest log files from the publishing server that have not yet been added to a checkpointing file.
and uses them to rebuild the other engine IMDBs to their original state (or nearly their original state) when the engine was shut down. Also at start-up, MATRIXX confirms that the transactions have no gaps. For details, see the discussion about the transaction log recovery procedure using recover_transaction_logs.py.

If any of the servers notice missing GTCs in a range of transaction events, they can request that those missing transactions be resent. This keeps all MATRIXX servers nearly synchronized with the active engine.

For details about replaying transactions from these logs, see the discussion about Analyze Transaction Replay performance in MATRIXX Administration.

For more information about configuring transaction logging, see the discussion about publishing server transaction and logging configuration in MATRIXX Configuration.