Welcome to Knowledge Base!

KB at your finger tips

This is one stop global knowledge base where you can learn about all the products, solutions and support features.

Categories
All

Database-MongoDB

Provision Servers for Automation — MongoDB Cloud Manager

Provision Servers for Automation¶

On this page

  • Overview
  • Procedure
  • Next Steps

Overview¶

Cloud Manager can automate operations for the MongoDB processes running on your hosts. Cloud Manager can both discover existing processes and deploy new ones.

Cloud Manager Automation relies on an Automation Agent, which must be installed on every server that runs a monitored MongoDB deployment. The Automation Agents periodically poll Cloud Manager to determine the goal configuration, deploy changes as needed, and report deployment status back to Cloud Manager.

Procedure¶

Install the MongoDB Agent on each host that you want Cloud Manager to manage. The following procedure applies to all operating systems.

Instructions for a specific operating system can be read on Install MongoDB Agent .

On Linux hosts, if you installed MongoDB with a package manager, use the same package manager to install the MongoDB Agent. If you installed MongoDB without a package manager, use an archive to install the MongoDB Agent.

Next Steps¶

Once you have installed the MongoDB Agent to all your hosts, you can deploy your first replica set , cluster , or standalone .

Projects — MongoDB Cloud Manager

Projects¶

On this page

  • Working with Multiple Environments
  • Create One Project
  • Delete One Project
  • Additional Information

new

Groups are now projects.

In Cloud Manager, MongoDB deployments are associated with projects.

You can create multiple projects in an organization. Each project has its own Monitoring, Backup and Automations associated with the project.

Projects within the same organization share the same billing settings.

Working with Multiple Environments¶

For a project, the Monitoring must be able to connect to all hosts it monitors. If you have multiple MongoDB deployments in distinct environments and cannot monitor all deployments with a single agent (for instance, if your environments are separated by firewalls), you will need to add new projects.

You can also use multiple projects and agents if you want to separately monitor different MongoDB deployments that run in the same environment.

Create One Project¶

Important

  • To create a project for an organization, you must be either an Organization Owner or an Organization Project Creator .
  • When you create a project, you are added as an Project Owner of the project.
  • When you create a project, Cloud Manager automatically assigns a set of default alert configurations to the project.
1
2

Select Cloud Manager.¶

  1. Click Cloud Manager.
  2. Click Next .
To learn more about MongoDB Atlas, see https://www.mongodb.com/cloud.
3

Enter a name for the Project

If you selected an MongoDB Atlas project, enter a name for the Organization .

3

Optional: Configure LDAP options.

If managing Cloud Manager users through LDAP , enter values for the following Optional LDAP Configuration fields .

Important

Multiple LDAP Groups Can Map to One Role

Cloud Manager roles can include more than one LDAP group. Type multiple LDAP group names in the relevant role fields separated by two semicolons ( ;; ).

Field Action
LDAP Groups for Project Owner Role Type the LDAP group(s) to which the Project Owners of the Cloud Manager project belong. You can type multiple LDAP groups into this field if they are separated by two semicolons ( ;; ).
LDAP Groups for Automation Admin Role Type the LDAP group(s) to which Cloud Manager project’s Automation Administrators belong. You can type multiple LDAP groups into this field if they are separated by two semicolons ( ;; ).
LDAP Groups for Backup Admin Role Type the LDAP group(s) to which Cloud Manager project’s Backup Administrators belong. You can type multiple LDAP groups into this field if they are separated by two semicolons ( ;; ).
LDAP Groups for Monitoring Admin Role Type the LDAP group(s) to which Cloud Manager project’s Monitoring Administrators belong. You can type multiple LDAP groups into this field if they are separated by two semicolons ( ;; ).
LDAP Groups for User Admin Role Type the LDAP group(s) to which Cloud Manager project’s User Administrators belong. You can type multiple LDAP groups into this field if they are separated by two semicolons ( ;; ).
LDAP Groups for Read Only Role Type the LDAP group(s) to which Cloud Manager project’s Read Only Users belong. You can type multiple LDAP groups into this field if they are separated by two semicolons ( ;; ).
4

Add members to your project.¶

For existing Cloud Manager users, enter their username. Usually, this is the email the person used to register.

For new Cloud Manager users, enter their email address to send an invitation.

5

Specify the access for the members.¶

6

Click the Create Project button to create the project.¶

Delete One Project¶

Important

Deleting a project removes all the project’s artifacts, including all monitoring data. Cloud Manager no longer displays the project in selection lists.

You can delete a project if:

  • You have the Project Owner access for the project.
  • The project has no backups. To terminate your backups prior to removing the project, see Terminate a Deployment’s Backups .
1

View all of your projects.¶

  1. If it is not already displayed, select the organization that contains your desired project from the office icon Organizations menu in the navigation bar.
  2. Click the Leaf icon in the upper left corner of the page. You can also expand the Projects menu in the navigation bar, then click View All Projects .
2

Delete the project.¶

Click the trash icon button for the project you wish to delete to open the Delete Project modal.

3

Confirm that you want to delete this project.¶

  1. Click Delete Project .
  2. Click Delete Project again.
4

Stop the MongoDB Agents.¶

Agent Procedure
Automations Stop the agent’s process on each server.
Monitoring See Stop the Monitoring Agent and Remove Monitoring Agents from Cloud Manager .
Backup See Stop the Backup Agent and Remove the Backup Agent from Cloud Manager .

Additional Information¶

Use the following procedures to modify projects:

  • Edit Project Settings
  • Reopen a Locked Account
  • Remove Project from Automation
Read article

Add Entries to a Whitelist — MongoDB Cloud Manager

Add Entries to a Whitelist¶

Base URL: https://cloud.mongodb.com/api/public/v1.0

Resource¶

POST /users/{USER-ID}/whitelist

Request Path Parameters¶

Parameter Type Description
USER-ID string (Required.) Unique identifier of the current user. To retrieve the ID of the current user, see Get All Users in One Project .

Request Query Parameters¶

The following query parameters are optional:

Name Type Necessity Description Default
pageNum number Optional One-based integer that returns a subsection of results. 1
itemsPerPage number Optional Number of items to return per page, up to a maximum of 500. 100
pretty boolean Optional Flag that indicates whether the response body should be in a prettyprint format. false
envelope boolean Optional

Flag that indicates whether or not to wrap the response in an envelope.

Some API clients cannot access the HTTP response headers or status code. To remediate this, set envelope : true in the query.

For endpoints that return a list of results, the results object is an envelope. Cloud Manager adds the status field to the response body.

false

Request Body Parameters¶

The request body must be an array of whitelist entities, even if there is only one. The only field that you need to specify for each request object is the IP-ADDRESS .

If an IP address is already in the whitelist, it will be ignored.

If you specify a single IP address with the /32 subnet mask, Cloud Manager does not store the /32 , as the /32 does not change the address.

Example

An address of 12.34.56.78 is the same as 12.34.56.78/32 .

Parameter Type Description
ipAddress string (Required.) The IP address or CIDR block that you want to add to the specified user’s whitelist.

Response¶

Response Document¶

The response JSON document includes an array of result objects, an array of link objects and a count of the total number of result objects retrieved.

Name Type Description
results array Array includes one object for each item detailed in the results Embedded Document section.
links array Array includes one or more links to sub-resources and/or related resources. The relations between URL s are explained in the Web Linking Specification .
totalCount number Integer count of the total number of items in the result set. It may be greater than the number of objects in the results array if the entire result set is paginated.

results Embedded Document¶

Each result is one whitelist.

Name Type Description
cidrBlock string A CIDR-notated range of IP addresses.
created date The date this IP address was added to the whitelist.
ipAddress string A whitelisted IP address.
lastUsed date The date of the most recent request that originated from this IP address. Note that this field is only updated when a whitelisted resource is accessed.
lastUsedAddress string The address from which the last call to the API was issued.
count number The total number of requests that originated from this IP address. Note that this field is only updated when a resource that is protected by the whitelist is accessed.
links array Links to related sub-resources. All links arrays in responses contain at least one link called self . The relations between URLs are explained in the Web Linking Specification.

Example Request¶

curl --user '{PUBLIC-KEY}:{PRIVATE-KEY}' --digest \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--include \
--request POST "https://cloud.mongodb.com/api/public/v1.0/users/{USER-ID}/whitelist" --data '
    [
      {
        "ipAddress" : "192.0.1.15",
        "comment" : "IP address for Application Server A"
      },
      {
        "cidrBlock" : "192.0.2.0/24",
        "comment" : "CIDR block for Application Server B - D"
      }
    ]'

Example Response¶

Response Header¶

HTTP/1.1 401 Unauthorized
Content-Type: application/json;charset=ISO-8859-1
Date: {dateInUnixFormat}
WWW-Authenticate: Digest realm="MMS Public API", domain="", nonce="{nonce}", algorithm=MD5, op="auth", stale=false
Content-Length: {requestLengthInBytes}
Connection: keep-alive
HTTP/1.1 201 Created
Vary: Accept-Encoding
Content-Type: application/json
Strict-Transport-Security: max-age=300
Date: {dateInUnixFormat}
Connection: keep-alive
Content-Length: {requestLengthInBytes}
X-MongoDB-Service-Version: gitHash={gitHash}; versionString={ApplicationVersion}

Response Body¶

{
  "totalCount" : 3,
  "results" : [ {
    "cidrBlock" : "12.34.56.78/32",
    "ipAddress" : "12.34.56.78",
    "created" : "2014-04-23T16:17:44Z",
    "lastUsed" : "2016-08-17T19:34:05Z",
    "lastUsedAddress" : "12.34.56.78",
    "count" : 0,
    "links" : []
  }, {
    "cidrBlock" : "76.54.32.10/32",
    "ipAddress" : "76.54.32.10",
    "created" : "2016-08-17T19:34:05Z",
    "count" : 0,
    "links" : []
  }, {
    "cidrBlock" : "2.3.4.5/32",
    "ipAddress" : "2.3.4.5",
    "created" : "2016-08-17T19:34:05Z",
    "count" : 0,
    "links" : []
  } ],
  "links" : []
}
Read article

Get One Project by Name — MongoDB Cloud Manager

Get One Project by Name¶

On this page

  • Resource
  • Request Parameters
    • Request Path Parameters
    • Request Query Parameters
    • Request Body Parameters
  • Response
  • Example Request
    • Example Response

Note

Groups and projects are synonymous terms. Your {PROJECT-ID} is the same as your project id. For existing groups, your group/project id remains the same. This page uses the more familiar term group when referring to descriptions. The endpoint remains as stated in the document.

Base URL: https://cloud.mongodb.com/api/public/v1.0

Resource¶

GET /groups/byName/{GROUP-NAME}

Request Parameters¶

Request Path Parameters¶

Name Type Description
GROUP-NAME string (Required.) The name of the project.

Request Query Parameters¶

The following query parameters are optional:

Name Type Necessity Description Default
pretty boolean Optional Flag indicating whether the response body should be in a prettyprint format. false
envelope boolean Optional

Flag that indicates whether or not to wrap the response in an envelope.

Some API clients cannot access the HTTP response headers or status code. To remediate this, set envelope=true in the query.

For endpoints that return one result, the response body includes:

Name Description
status HTTP response code
envelope Expected response body
false

Request Body Parameters¶

This endpoint doesn’t use HTTP request body parameters.

Response¶

Name Type Description
activeAgentCount integer

Number of active agents sending regular pings to Cloud Manager.

The value is refreshed about every 24 hours and cached. If you start a new agent or stop an existing one, the change can take up to 30 minutes to show up in the activeAgentCount field.

hostCounts object Total number of hosts by type. The embedded fields should be self-explanatory.
id string Unique identifier for the group.
lastActiveAgent string Time Cloud Manager last updated the activeAgentCount total for the project. Cloud Manager refreshes this value every 24 hours and caches it to record the number of active MongoDB Agents.
links object array One or more links to sub-resources and/or related resources. All links arrays in responses include at least one link called self . The relationships between URL s are explained in the Web Linking Specification .
name string Display name for the project.
orgId string Unique identifier for the organization to which the project belongs.
publicApiEnabled boolean Flag indicating that the API is enabled for this project. This is a read-only field that is always true .
replicaSetCount integer Total number of replica sets for this project.
shardCount integer Total number of shards for this project.

Example Request¶

curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \
 --include \
 --request GET "https://cloud.mongodb.com/api/public/v1.0/groups/byName/{GROUP-NAME}?pretty=true"

Important

Some characters are not allowed in URLs. These are called reserved characters. If your {GROUP-NAME} includes reserved characters, like spaces, you must replace them with their percent encoding.

Example

Instead of making this request (via curl):

curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \
 --header "Accept: application/json" \
 --include \
 --request GET "https://cloud.mongodb.com/api/public/v1.0/groups/byName/My%20Project?pretty=true"

Make this request (via curl):

curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \
 --header "Accept: application/json" \
 --include \
 --request GET "https://cloud.mongodb.com/api/public/v1.0/groups/byName/My%20Group?pretty=true"

Example Response¶

Response Header¶

HTTP/1.1 401 Unauthorized
Content-Type: application/json;charset=ISO-8859-1
Date: {dateInUnixFormat}
WWW-Authenticate: Digest realm="MMS Public API", domain="", nonce="{nonce}", algorithm=MD5, op="auth", stale=false
Content-Length: {requestLengthInBytes}
Connection: keep-alive
HTTP/1.1 200 OK
Vary: Accept-Encoding
Content-Type: application/json
Strict-Transport-Security: max-age=300
Date: {dateInUnixFormat}
Connection: keep-alive
Content-Length: {requestLengthInBytes}
X-MongoDB-Service-Version: gitHash={gitHash}; versionString={ApplicationVersion}

Response Body¶

{
  "activeAgentCount": 1,
  "agentApiKey": "{AGENT-API-KEY}",
  "hostCounts": {
    "arbiter": 2,
    "config": 1,
    "primary": 4,
    "secondary": 8,
    "mongos": 2,
    "master": 0,
    "slave": 0
  },
  "id": "{PROJECT-ID}",
  "lastActiveAgent": ISODate("2016-08-05T07:23:34Z"),
  "links" : [],
  "name": "My Project",
  "orgId" : "111111111cccccf38dc78bdf",
  "publicApiEnabled": true,
  "replicaSetCount": 3,
  "shardCount": 2,
}
Read article

Deploy a Cluster through the API — MongoDB Cloud Manager

Deploy a Cluster through the API¶

On this page

  • Prerequisites
  • Examples
  • Variables for Cluster Creation API Resources
  • Prerequisites
  • Procedures
  • Next Steps

This tutorial manipulates the Cloud Manager Administration API’s automation configuration to deploy a sharded cluster that is owned by another user. The tutorial first creates a new project, then a new user as owner of the project, and then a sharded cluster owned by the new user. You can create a script to automate these procedures for use in routine operations.

To perform these steps, you must have sufficient access to Cloud Manager. A user with the Project Owner role has sufficient access.

The procedures install a cluster with two shards . Each shard comprises a three-member replica set . The tutorial installs one mongos and three config servers . Each component of the cluster resides on its own server, requiring a total of 10 hosts.

The tutorial installs the MongoDB Agent on each host.

Prerequisites¶

Provision ten hosts to serve the components of the sharded cluster . For host requirements, see the Production Notes in the MongoDB manual.

Each host must provide its MongoDB Agent with full networking access to the hostnames and ports of the MongoDB Agents on all the other hosts. Each agent runs the command hostname -f to self-identify its hostname and port and report them to Cloud Manager.

Tip

To ensure agents can reach each other, provision the hosts using Automation . This installs the MongoDB Agents with correct network access. Use this tutorial to reinstall the Automations on those machines.

Examples¶

As you work with the API , you can view examples on the GitHub example page.

Variables for Cluster Creation API Resources¶

The API resources use one or more of these variables. Replace these variables with your desired values before calling these API resources.

Name Type Description
PUBLIC-KEY string Your public API Key for your API credentials.
PRIVATE-KEY string Your private API Key for your API credentials.
cloud.mongodb.com string URL of your Cloud Manager instance.
GROUP-ID string Unique identifier of your project from your Project Settings .

Prerequisites¶

  • Configure API Access to enable you to use the API.
  • Complete the MongoDB Agent Prerequisites .

Procedures¶

Create the Group and the User through the API¶

1

Use the API to create a project.¶

Use the Cloud Manager Administration API to send a projects document to create the new project.

curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \
     --header "Content-Type: application/json" \
     --request POST "https://cloud.mongodb.com/api/public/v1.0/groups?pretty=true" \
     --data '
       {
         "name": "{GROUP-NAME}"
       }'

The API returns a document that includes the project’s agentApiKey and id .

2

Record the values of agentApiKey and id in the returned document.¶

Record these values for use in this procedure and in other procedures in this tutorial.

3

Use the API to create a user in the new project.¶

Use the /users endpoint to add a user to the new project.

The body of the request should contain a users JSON document with the user’s information.

Set the user’s roles.roleName to GROUP_OWNER and the user’s roles.groupId set to the new group’s‘ id .

curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \
     --header 'Accept: application/json' \
     --header "Content-Type: application/json" \
     --request POST "https://cloud.mongodb.com/api/public/v1.0/users?pretty=true" \
     --data '
       {
          "username": "<new_user@example.com>",
          "emailAddress": "<new_user@example.com>",
          "firstName": "<First>",
          "lastName": "<Last>",
          "password": "<password>",
          "roles": [{
            "groupId": "{PROJECT-ID}",
            "roleName": "GROUP_OWNER"
          }]
       }'

Install the MongoDB Agent on each Provisioned Host¶

1

Complete the MongoDB Agent installation procedure on each host.¶

To learn how to install the MongoDB Agent, follow the procedure for the appropriate platform .

2

Confirm the initial state of the automation configuration.¶

When the MongoDB Agent first runs, it downloads the mms-cluster-config-backup.json file, which describes the desired state of the automation configuration .

On one of the hosts, navigate to /var/lib/mongodb-mms-automation/ and open mms-cluster-config-backup.json . Confirm that the file’s version field is set to 1 . Cloud Manager automatically increments this field as changes occur.

Deploy the New Cluster¶

To add or update a deployment, retrieve the configuration , make changes as needed, and send the updated configuration though the API to Cloud Manager.

The following procedure deploys an updated automation configuration through the API :

1

Retrieve the automation configuration from Cloud Manager.¶

  1. Use the automationConfig resource to retrieve the configuration. Issue the following command, replacing the placeholders with the Variables for Cluster Creation API Resources.

    curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \
         --request GET "https://cloud.mongodb.com/api/public/v1.0/groups/{PROJECT-ID}/automationConfig?pretty=true" \
         --output currentAutomationConfig.json
    
  2. Validate the downloaded Automation Configuration file.

    Compare the version field of the currentAutomationConfig.json with that of the Automation Configuration backup file, mms-cluster-config-backup.json . The version value is the last element in both JSON documents. You can find this file on any host running the MongoDB Agent at:

    • Linux and macOS: /var/lib/mongodb-mms-automation/mms-cluster-config-backup.json
    • Windows: %SystemDrive%\MMSAutomation\versions\mms-cluster-config-backup.json

    If the version values match, you are working with the current version of the Automation Configuration file.

2

Create the top level of the new automation configuration.¶

Create a document with the following fields. As you build the configuration document, refer the description of an automation configuration for detailed explanations of the settings. For examples, see the MongoDB Labs page.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
{
    "options": {
        "downloadBase": "/var/lib/mongodb-mms-automation",
    },
    "mongoDbVersions": [],
    "monitoringVersions": [],
    "backupVersions": [],
    "processes": [],
    "replicaSets": [],
    "sharding": []
}
4

Add the Monitoring to the automation configuration.¶

In the monitoringVersions.hostname field, enter the hostname of the server where Cloud Manager should install the Monitoring. Use the fully qualified domain name that running hostname -f on the server returns, as in the following:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
"monitoringVersions": [
  {
    "hostname": "<server_x.example.com>",
    "logPath": "/var/log/mongodb-mms-automation/monitoring-agent.log",
    "logRotate": {
      "sizeThresholdMB": 1000,
      "timeThresholdHrs": 24
    }
  }
]

This configuration example also includes the logPath field, which specifies the log location, and logRotate , which specifies the log thresholds.

5

Add the servers to the automation configuration.¶

This sharded cluster has 10 MongoDB instances, as described in the Deploy a Cluster through the API , each running on its own server. Thus, the automation configuration’s processes array will have 10 documents, one for each MongoDB instance.

The following example adds the first document to the processes array. Replace <process_name_1> with any name you choose, and replace <server1.example.com> with the FQDN of the host.

Add 9 documents: one for each MongoDB instance in your sharded cluster.

Specify the args2_6 syntax for the processes.<args> field. See MongoDB Settings that Automation Supports for more information.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
"processes": [
  {
    "version": "4.0.6",
    "name": "<process_name_1>",
    "hostname": "<server1.example.com>",
    "logRotate": {
      "sizeThresholdMB": 1000,
      "timeThresholdHrs": 24
    },
    "authSchemaVersion": 5,
    "featureCompatibilityVersion": "4.0",
    "processType": "mongod",
    "args2_6": {
      "net": {
        "port": 27017
      },
      "storage": {
        "dbPath": "/data/"
      },
      "systemLog": {
        "path": "/data/mongodb.log",
        "destination": "file"
      },
      "replication": {
        "replSetName": "rs1"
      }
    }
  },
]
6

Add the sharded cluster topology to the automation configuration.¶

Add two replica set documents to the replicaSets array. Add three members to each document.

Example

This section adds one replica set member to the first replica set document:

Important

You must include "protocolVersion": 1 in the root document for each replica set.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
"replicaSets": [
  {
    "_id": "rs1",
    "members": [
      {
        "_id": 0,
        "host": "<process_name_1>",
        "priority": 1,
        "votes": 1,
        "slaveDelay": 0,
        "hidden": false,
        "arbiterOnly": false
      }
    ],
    "protocolVersion": 1
  }
]

In the sharding array, add the replica sets to the shards, and add the config server replica set name, as in the following:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
"sharding": [
  {
    "shards": [
      {
        "tags": [],
        "_id": "shard1",
        "rs": "rs1"
      },
      {
        "tags": [],
        "_id": "shard2",
        "rs": "rs2"
      }
    ],
    "name": "sharded_cluster_via_api",
    "configServerReplica": "rs-config",
    "collections": []
  }
]
7

Send the updated automation configuration.¶

Use the automationConfig resource to send the updated automation configuration.

Issue the following command with path to the updated configuration document and replace the placeholders with the Variables for Cluster Creation API Resources.

curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \
     --header "Content-Type: application/json"
     --request PUT "https://cloud.mongodb.com/api/public/v1.0/groups/{PROJECT-ID}/automationConfig?pretty=true" \
     --data @currentAutomationConfig.json

Upon successful update of the configuration, the API returns the HTTP 200 OK status code to indicate the request has succeeded.

8

Confirm successful update of the automation configuration.¶

Retrieve the automation configuration from Cloud Manager and confirm it contains the changes. To retrieve the configuration, issue the following command, replacing the placeholders with the Variables for Cluster Creation API Resources.

curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \
     --request GET "https://cloud.mongodb.com/api/public/v1.0/groups/{PROJECT-ID}/automationConfig?pretty=true"
9

Verify that the configuration update is deployed.¶

Use the automationStatus resource to verify the configuration update is fully deployed. Issue the following command, replacing the value placeholders given in Variables for Cluster Creation API Resources:

curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \
     --request GET "https://cloud.mongodb.com/api/public/v1.0/groups/{PROJECT-ID}/automationStatus?pretty=true"

The curl command returns a JSON object containing the processes array and the goalVersion key and value. The processes array contains a document for each server that hosts a MongoDB instance. The new configuration is successfully deployed when all lastGoalVersionAchieved fields in the processes array equal the value specified for goalVersion .

Example

In this response, processes[2].lastGoalVersionAchieved is behind goalVersion . This indicates that the MongoDB instance at server3.example.com is running one version behind the goalVersion . Wait several seconds and issue the curl command again.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
{
  "goalVersion": 2,
  "processes": [{
    "hostname": "server1.example.com",
    "lastGoalVersionAchieved": 2,
    "name": "ReplSet_0",
    "plan": []
  }, {
    "hostname": "server2.example.com",
    "lastGoalVersionAchieved": 2,
    "name": "ReplSet_1",
    "plan": []
  }, {
     "hostname": "server3.example.com",
     "lastGoalVersionAchieved": 1,
     "name": "ReplSet_2",
     "plan":[]
  }]
}

To view the new configuration in the Cloud Manager console, click Deployment .

Next Steps¶

To make an additional version of MongoDB available in the cluster, see Update the MongoDB Version of a Deployment .

Read article

Fix Replication Lag — MongoDB Cloud Manager

Fix Replication Lag¶

On this page

  • Alert Conditions
  • Common Triggers
  • Fix the Immediate Problem
  • Implement a Long-Term Solution
  • Monitor Your Progress

At time T , the last write operation applied on the specified secondary of replica set ABC was behind the most recent operation applied on the primary .

Alert Conditions¶

You can configure alert conditions in the project-level alert settings page to trigger alerts.

To learn more about the alert condition, see Replication Lag is .

Common Triggers¶

  • An idle replica set. The reported replication lag is actually just the time since the last write. Replication lag is calculated between the last operation time on the primary and the time of the last operation received by the secondary. If a replica set is only written to once every 10 minutes, the replication lag will be 10 minutes just after the write is made to the primary and just prior to the next write being replicated to the secondary.
  • The secondary is under-provisioned, which means it needs more allocated resources, and cannot keep up with the primary (common if using secondaries for read scaling).
  • There is insufficient bandwidth, or some other networking problem, between the primary and secondary.

Fix the Immediate Problem¶

  • Adjust the settings for this alert to only trigger if the replication lag persists for longer than 2 minutes. This will reduce the chances of a false positive.
  • Resolve networking issues between the primary and secondary.

To learn more, see Troubleshoot Replica Sets in the MongoDB manual.

Implement a Long-Term Solution¶

  • Increase bandwidth between the primary and secondary.
  • Move (or upgrade in place) the secondary to a machine that is identically (or better) provisioned to the current primary.

Monitor Your Progress¶

View the following charts to monitor your progress:

  • Network

    Monitor network metrics to track network performance.

  • Replication Headroom

    Monitor replication headroom to determine whether the secondary might fall off the oplog.

  • Replication Lag

    Monitor replication lag to determine whether the secondary might fall off the oplog.

To learn more, see View Deployment Metrics .

Read article