MongoDB Recommendations for Event Repository

You must set up MongoDB database processes for hosting the Event Repository.

Planning Your MongoDB System

You must purchase and install MongoDB individually. See the discussion about Event Repository system requirements for information about software versions.

To plan a MongoDB system, be familiar with MongoDB operations, networking, and security best practices. Refer to the MongoDB product documentation for information about planning a MongoDB system.

Plan for hardware acquisition and configuration and network configuration. Perform capacity planning and hardware provisioning for your MongoDB system. Plan for the number of MongoDB database processes needed for your environment based on expected traffic.

Minimum MongoDB Deployment (Non-Sharded)

When MATRIXX is configured for high availability, it can contain two or three MATRIXX Engines in one domain, and they are typically located in separate data centers. See the discussion about geographic redundancy in MATRIXX Architecture for information about MATRIXX Engine high availability.

In MongoDB, a replica set is a group of mongod instances that host the same data set. You will have a replica set to host the MATRIXX event-object data. The number of mongod instances you use for your replica set is based on your network topology and high availability requirements. Event Loaders running on the active engine loads the event objects into the event repository. The primary mongod of your replica set processes the insertion of event records into the event repository from the active engine. If a primary fails, a secondary mongod in the replica set takes over within a few seconds to become the new primary.

The minimum MongoDB configuration for hosting the Event Repository is three mongod instances for each set of MATRIXX Engines configured for HA (two or three engines). Specifically:

  • One mongod instance (mongod primary) in the data center with the active engine.
  • One mongod instance (mongod secondary) in the data center with the standby engine.
  • One mongod instance (arbiter) running as a non-data-bearing arbiter in a third location. It is preferred that the arbiter be in a third location, but this is not required.

Figure 1 shows a minimum MongoDB configuration. The arrow pointing from the primary to the secondary indicates that the primary in the replica set replicates the data (send data updates) to the secondary mongod instance.

Figure 1. Minimum MongoDB Deployment
Minimum MongoDB Deployment Diagram

Recommended MongoDB Deployment (Non-Sharded)

The recommended MongoDB deployment for hosting the Event Repository is five mongodb instances for each MATRIXX Engine active-standby HA pair, with two mongod instances running in each data center. In this way, if there is any communication lag between the data centers of the primary and secondary engines, if the primary mongod fails, there is a secondary in the same data center to take over. The recommended MongoDB configuration would be a replica set with five mongod members as follows:

  • Two mongod instances (mongod primary and mongod secondary) in the data center with the active engine.
  • Two mongod instances (two mongod secondary instances) in the data center with the standby engine.
  • One mongod instance running in a third data center location as a secondary mongod instance. If your high availability requirements do not require this secondary instance, it can be run as an arbiter.

Figure 2 shows a recommended MongoDB configuration. The primary mongod in the replica set replicates the data (send data updates) to all secondary mongod instances.

Figure 2. Recommended MongoDB Deployment
Recommended MongoDB Deployment Diagram

Example MongoDB Deployment (Sharded Cluster)

A sharded MongoDB deployment might include:

  • Two or more shards.

    Each shard is a replica set that holds a subset of your data.

  • One config server replica set with three config-server members. The config server replica set contain the configuration information of the entire sharded cluster.
    Note: A replica set must have a minimum of three members.
  • Any number of mongos instances needed for connecting clients.

Figure 3 shows an example MongoDB sharded deployment with two shards. The primary in each shard replica set replicates the data (send data updates) to the secondaries in its replica set.

Figure 3. Example MongoDB Sharded Deployment
Example MongoDB Sharded Deployment Diagram

Recommendations for MongoDB Installation

Important: To plan and install your MongoDB system, you must understand MongoDB-operations best practices and MongoDB networking and security best practices. Refer to MongoDB product documentation for information about installing, provisioning, and managing a MongoDB system.

MongoDB is to be installed on every host server where the MongoDB processes and tools are to run.

After you install the required release of MongoDB Enterprise, it might be useful to pin the package to prevent MongoDB updates from being inadvertently installed on your running MongoDB system.

For a sharded MongoDB deployment, when installing the mongos software, set up a mongos instance for each MATRIXX client application that connects to your MongoDB sharded cluster.

For recommendations on where to install the OS, or where to place the MongoDB index files and data files, see the hardware section in the discussion about Event Repository system requirements.

Recommendations for MongoDB Configuration

A mongod process is configured using the MongoDB configuration file (typically in /etc/init.d/mongod.conf). A mongod.conf configuration file template is provided in the discussion about MongoDB configuration file templates. The template shows basic recommended settings for the initial setup of the Event Repository.

For recommendations on where to place the MongoDB index files and data files, see the hardware section in the discussion about Event Repository system requirements.

The journaling of operations on the MongoDB server is not recommended. If you enable journaling, do not store the journal files on the same SSDs where you store MongoDB index files.

Recommendations for MongoDB Start-up

Start the mongod process as a service. A script that periodically checks whether a mongod instance is running, and restarts the instance when it is not running, is recommended.

Note: The MATRIXX Engine Event Loader system cannot start up until it can connect to the MongoDB server. The lack of connection is reported in logs.

Recommendations for a Sharded MongoDB Deployment

With a sharded MongoDB deployment, you use mongos query routers. Query routers are the routing and load balancing processes that act as interfaces between your MATRIXX client applications (Event Loader services, Event Repository administration scripts, GL processing utilities) and your MongoDB sharded cluster. Install one mongos instance for each MongoDB client application.

In a MongoDB sharded cluster, run the mongos on the same host server on which Event Loader runs.

A mongos process is configured using the MongoDB configuration file. To view a mongos.conf configuration file template, see the discussion about MongoDB configuration file templates. The template shows basic recommended settings for the initial setup of the Event Repository.