Glossary¶

agent

One of several lightweight programs that run within your network to monitor, manage, and back up your MongoDB databases. See Automation Agent, Monitoring Agent and Backup Agent.

Ops Manager Application

The main Ops Manager component. The Ops Manager Application provides the user interface for managing MongoDB deployments and provides endpoints for Ops Manager agents to transmit data. See Ops Manager Application.

Ops Manager Application Database

The dedicated MongoDB database that stores metadata for the Ops Manager installation and the managed MongoDB deployments. See Ops Manager Application Database.

automation

The assisted management of MongoDB processes through the Ops Manager interface. Automation Agents installed on your MongoDB servers allow you to deploy, configure, and update MongoDB processes directly from Ops Manager. See Automation.

Automation Agent

A lightweight component that automates common management tasks. The Automation Agent runs on every server that will have a mongod or mongos. See Automation Agent.

backing instance

A dedicated MongoDB standalone or replica set that stores data for either the Ops Manager Application or Backup Daemon. The instance should not store other data. See Deploy Backing MongoDB Replica Sets.

Backup Agent

A lightweight component that runs within your data center and backs up MongoDB processes via the MongoDB wire protocol. No direct file system access is needed. See Backup Agent.

Backup Blockstore Database

The database that stores your snapshots. The database is also referred to simply as the “blockstore.” The blockstore uses a storage format that parses a snapshot into smaller chunks that allow Ops Manager to manage snapshot changes incrementally. You can administer blockstores from the Blockstores Page. The blockstore is one type of Backup Database.

Backup Daemon

The Ops Manager component that creates and manages backups by maintaining head databases and snapshots. See Backup Daemon.

Backup Database

The set of databases where Ops Manager stores snapshots of backed-up deployments and stores temporary backup data. The databases usually run on a dedicated MongoDB replica set used only for these databases. The set of databases includes the Backup Blockstore Database, Oplog Store Database, and Sync Store Database. See Backup Database and Backup Flows.

backup job

A process run by the Backup Daemon to apply the most recent changes to its backup of a replica set. The daemon stores backups locally as head databases. A sharded cluster will have a different head database for each shard. You can re-assign backup jobs among Backup Daemons. See Jobs Page.

Backup HTTP Service

The interface through which the Backup Agent sends data for backup and retrieves configuration information. See Backup HTTP Service.

blockstore

See Backup Blockstore Database.

checkpoint

A point in time between snapshots to which you can restore a sharded cluster. Ops Manager must stop the balancer each time it creates a checkpoint. Ops Manager does not require checkpoints, and they are disabled by default. See Checkpoints.

cluster

In Ops Manager, “cluster” can refer to either a replica set or sharded cluster.

custom snapshot

A backup of the state of your MongoDB deployment at a point in time between stored snapshots. Ops Manager builds a custom snapshot by applying oplog data to a stored snapshot. For more information, see Restore Types.

deployment

“Deployment” usually refers to all the MongoDB processes that run within an Ops Manager group. “Deployment” can also refer to a specific set of MongoDB processes, such as a specific sharded cluster or replica set.

excluded namespace

A database or collection that Ops Manager will not back up, as designated by its namespace. See namespaces-filter.

groom

A job that removes unused blocks on a blockstore and that can move blocks from one blockstore to another. You can view and manage grooms from Grooms Page and Groom Priority.

group

A distinct set of MongoDB processes and Ops Manager users. See Manage Groups.

head

See head database.

head database

The copy of a backed-up deployment stored on the Backup Daemon’s server. The daemon maintains a head database for each shard or replica set it backs up. The daemon creates periodic snapshots of head databases for historical backups. See Data Backup and Backup Daemon.

Ops Manager HTTP Service

The interface through which the Monitoring Agent communicates with Ops Manager. See Ops Manager HTTP Service.

initial sync

The MongoDB operation that replicates data from an existing replica set member to a new member. Ops Manager uses initial sync when creating a new head database. See Initial Sync. See also Replica Set Data Synchronization in the MongoDB manual.

job

See backup job.

monitoring

The real-time reporting, visualization, and alerting of the state of your MongoDB processes. See Monitoring.

Monitoring Agent

A lightweight component that runs within your data center and monitors your MongoDB processes via the MongoDB wire protocol. No direct file system access is needed. See Monitoring Agent.

namespace

The combination of the database name and collection name:

[database-name].[collection-name]

oplog slice

A compressed batch of entries for the tailed oplog of a backed-up shard or replica set. The Backup Agent creates an oplog slice and sends it to the Backup HTTP Service, which stores it in the the Oplog Store Database. The Backup Daemon retrieves the slice and applies it to the associated head database. See Oplog Stores Page.

Oplog Store Database

The database where Ops Manager stores oplog slices before applying them to a deployment’s backup. The Oplog Store Database is one of three Backup Databases. For administration, see Oplog Stores Page.

ping

A data transmission sent by the Monitoring Agent to Ops Manager to confirm that the agent and its MongoDB processes are running and reachable. Ops Manager deactivates monitoring for a MongoDB process if too much time passes between successful pings, as described in Reactivate Monitoring for a Process.

point-in-time restore

A database restoration that captures the state of your data at a moment in-between snapshots. Point-in-time restores take longer to perform than snapshot restores. See Restore Types.

process

An instance of MongoDB running on a given host and port. The MongoDB database process is mongod. MongoDB also uses the mongos process to route operations in the sharded clusters. For more information on MongoDB processes, see MongoDB Package Components in the MongoDB manual.

role

The access given to an Ops Manager or MongoDB user. For Ops Manager users, see Ops Manager Roles. For MongoDB users, see Built-in Roles in the MongoDB manual.

server

A physical or virtual machine that hosts one or more MongoDB processes.

snapshot

A backup of your data captured at a specific interval and stored in the Backup Blockstore Database. Ops Manager creates snapshots from the backups kept on the head databases. The Snapshot Frequency and Retention Policy determines the interval for taking snapshots and how long to store them. See also custom snapshot.

snapshot frequency and retention policy

The schedule for how often to take snapshots and how long to store them. See Snapshot Frequency and Retention Policy.

sync slice

A batched and compressed portion of a MongoDB deployment’s documents. The Backup Agent creates sync slices and sends them to Ops Manager for creation of a deployment’s backup. Once the backup exists, Ops Manager deletes the slices. See Sync Stores Page.

Sync Store Database

The database where Ops Manager stores a temporary backup of your deployment during an initial sync. Ops Manager stores the backup as a series of sync slices. The Sync Store Database is one of three Backup Databases. See Sync Stores Page.

version manifest

The list of all released MongoDB versions. Ops Manager uses this list if running in local mode. See Version Manifest.

← Supported MongoDB Options for Automation Release Notes →