MongoDB in the Cloud with Atlas

MongoDB Atlas provides an easy way to host and manage your data in the cloud. MongoDB Atlas provides all of the features of MongoDB,without the operational heavy lifting required for any new application. MongoDB Atlas is available on-demand through a pay-as-you-go model and billed on an hourly basis, letting you focus on what you do best.MongoAtlas2

MongoDB Atlas provides:
• Security features to protect access to your data
• Built in replication for always-on availability, tolerating complete data center failure
• Backups and point in time recovery to protect against data corruption
• Fine-grained monitoring to let you know when to scale. Additional instances can be provisioned with the push of a button
• Automated patching and one-click upgrades for new major versions of the database, enabling you to take advantage of the latest and greatest MongoDB features.

Create an Atlas Account

Navigate to Atlas to create your Atlas account

You can register for an account on the MongoDB Atlas landing page.

img1.jpg

Once you register, Atlas automatically creates a default organization and project where you can deploy your first cluster. You can add additional organizations and projects later.

img2.JPG

Once you log in, Atlas prompts you to build your first cluster:

  • For Cloud Provider & Region, select your preferred Cloud Provider.

Atlas supports  clusters on Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure.

img3

  • For Cluster Tier, select M10 (Instance type as per requirement)

img4.JPG

Each cluster tier comes with a default set of resources. Clusters of size M10 and larger provide the ability to customize your storage capacity.

When disk usage reaches 90%, automatically increase storage by an amount necessary to achieve 70% utilization. To enable this feature, check the box marked Auto-expand storage when disk usage reaches 90%.

IOPS (AWS only)

Atlas clusters on AWS of size M30 and greater allow you to customize the maximum IOPS rate of your cluster. To provision the IOPS rate of your cluster, check the box marked Provision IOPS and either specify the exact IOPS rate in the text box, or move the slide bar until the text box displays your preferred IOPS rate.

  • Select any Additional Settings

Select the required MongoDB version from the Select a version dropdown. Atlas always deploys the cluster with the latest stable release of the specified version.

Atlas supports creating M10+ paid tier clusters with the following MongoDB versions:

  • MongoDB 3.4
  • MongoDB 3.6
  • MongoDB 4.0

To enable backups for the Atlas cluster, toggle Turn on Backup (M10 and up) to Yes. If enabled, Atlas takes snapshots of your databases at regular intervals and retains them according to your project’s retention policy.Select backup option as Continuous Backups

Atlas takes incremental snapshots of data in your cluster and allows you to restore from stored snapshots or from a selected point in time within the last 24 hours. You can also query a continuous backup snapshot.

To deploy sharded cluster : To deploy your cluster as a sharded cluster, toggle Shard your cluster (M30 and up).

img5

Atlas encrypts all cluster storage and snapshot volumes, ensuring the security of all cluster data at rest (Encryption at Rest). Atlas Project Owners can configure an additional layer of encryption on their data at rest using the MongoDB Encrypted Storage Engine and their Atlas-compatible Encryption at Rest provider.

To enable Atlas Encryption at Rest for this cluster, toggle Encryption At Rest with WiredTiger Encrypted Storage Engine (M10 and up) to Yes.

img6

  • Configure Additional Configuration Options

Set Oplog Size

Modify the oplog size of the cluster. For sharded cluster deployments, this modifies the oplog size of each shard in the cluster.

Require Indexes for All Queries : Enable or disable the execution of queries that require a collection scan to return results.

img7

  • Enter the Cluster Name
This is the cluster name as it appears in Atlas. You cannot change the cluster name once Atlas deploys the cluster.
img8

 

Click Create Cluster to deploy the cluster.

Once you deploy your cluster, it can take up to 10 minutes for your cluster to provision and become ready to use

img10.JPG

Atlas uses TLS/SSL to encrypt the connections to your databases.

img11.jpg

Configure Whitelist Entries

Atlas only allows client connections to the cluster from entries in the project’s whitelist. Each entry is either a single IP address or a CIDR-notated range of addresses.

For AWS clusters with one or more VPC Peering connections to the same AWS region, you can specify a Security Group associated with a peered VPC.

img12.jpg

  1. In the Security section of the left navigation, click Network Access. The IP Whitelist tab displays.
  2. Click plus icon Add IP Address.

img13

Enter an IP address, CIDR block, or Security Group ID

Enter the desired IP address or CIDR-notated range of addresses

img14.jpg

Set whitelist as temporary : Check the Save as temporary whitelist option to specify a length of time that the IP address will be whitelisted, after which Atlas will remove the address from the whitelist.

Configure MongoDB Users

Create MongoDB users to provide clients access to the clusters in your project. A MongoDB user’s access is determined by the roles assigned to the user. When you create a MongoDB user, the user is added to all clusters in your Atlas project.

MongoDB users are separate from Atlas users. MongoDB users have access to MongoDB databases, while Atlas users have access to the Atlas application itself. Atlas supports creating temporary MongoDB users that automatically expire within a user-configurable 7-day period.

  1. In the Security section of the left navigation, click Database Access. The MongoDB Users tab displays.
  2. Click plus icon Add New User.

img15.jpg

Create a Mongo Atlas Admin user for database administration

img16.jpg

img18.jpg

Click  Edit for the user you want to modify. You can modify the privileges assigned to the user and the user’s password. For temporary users, you can also modify the time period the user exists or make the user a permanent user, provided the user’s expiration date has not already passed.

Add Custom MongoDB Roles

You can create custom MongoDB roles in Atlas when the built-in Atlas database user privileges cannot describe your desired set of privileges.

  1. In the Security section of the left navigation, click Database Access. The MongoDB Roles tab displays.
  2. Click plus icon Add New Custom Role.

img19.jpg

img20.jpg

img21.jpg

Connect to a Cluster

If you use a whitelist on your firewall for network ports, open ports 27015 to 27017 to TCP and UDP traffic on Atlas hosts. This grants your applications access to databases stored on Atlas.

To access a cluster, you must connect from an IP address on the Atlas project’s IP whitelist. Also you must create a MongoDB User with access to the desired database(s) on your Atlas cluster.

  • Open the Connect dialog.

Go to the Clusters view. Click the Connect button for the cluster to which you wish to connect.In the Choose a connection method step, Atlas provides instructions for each listed connection method. Click your preferred connection method and follow the instructions given.

img22

img23.jpg

Copy the connection string and run in your command line

img24.jpg

  • Check the cluster status 
MongoDB Enterprise Cluster1-shard-0:PRIMARY> rs.status()
{
"set" : "Cluster1-shard-0",
"date" : ISODate("2019-06-23T11:53:59.831Z"),
"myState" : 1,
"term" : NumberLong(1),
"syncingTo" : "",
"syncSourceHost" : "",
"syncSourceId" : -1,
"heartbeatIntervalMillis" : NumberLong(2000),
"optimes" : {
"lastCommittedOpTime" : {
"ts" : Timestamp(1561290835, 1),
"t" : NumberLong(1)
},
"readConcernMajorityOpTime" : {
"ts" : Timestamp(1561290835, 1),
"t" : NumberLong(1)
},
"appliedOpTime" : {
"ts" : Timestamp(1561290835, 1),
"t" : NumberLong(1)
},
"durableOpTime" : {
"ts" : Timestamp(1561290835, 1),
"t" : NumberLong(1)
}
},
"members" : [
{
"_id" : 0,
"name" : "cluster1-shard-00-00-0vzv2.mongodb.net:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 2137,
"optime" : {
"ts" : Timestamp(1561290835, 1),
"t" : NumberLong(1)
},
"optimeDate" : ISODate("2019-06-23T11:53:55Z"),
"syncingTo" : "",
"syncSourceHost" : "",
"syncSourceId" : -1,
"infoMessage" : "",
"electionTime" : Timestamp(1561288714, 1),
"electionDate" : ISODate("2019-06-23T11:18:34Z"),
"configVersion" : 1,
"self" : true,
"lastHeartbeatMessage" : ""
},
{
"_id" : 1,
"name" : "cluster1-shard-00-01-0vzv2.mongodb.net:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 2135,
"optime" : {
"ts" : Timestamp(1561290835, 1),
"t" : NumberLong(1)
},
"optimeDurable" : {
"ts" : Timestamp(1561290835, 1),
"t" : NumberLong(1)
},
"optimeDate" : ISODate("2019-06-23T11:53:55Z"),
"optimeDurableDate" : ISODate("2019-06-23T11:53:55Z"),
"lastHeartbeat" : ISODate("2019-06-23T11:53:57.900Z"),
"lastHeartbeatRecv" : ISODate("2019-06-23T11:53:58.559Z"),
"pingMs" : NumberLong(0),
"lastHeartbeatMessage" : "",
"syncingTo" : "cluster1-shard-00-00-0vzv2.mongodb.net:27017",
"syncSourceHost" : "cluster1-shard-00-00-0vzv2.mongodb.net:27017",
"syncSourceId" : 0,
"infoMessage" : "",
"configVersion" : 1
},
{
"_id" : 2,
"name" : "cluster1-shard-00-02-0vzv2.mongodb.net:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 2135,
"optime" : {
"ts" : Timestamp(1561290835, 1),
"t" : NumberLong(1)
},
"optimeDurable" : {
"ts" : Timestamp(1561290835, 1),
"t" : NumberLong(1)
},
"optimeDate" : ISODate("2019-06-23T11:53:55Z"),
"optimeDurableDate" : ISODate("2019-06-23T11:53:55Z"),
"lastHeartbeat" : ISODate("2019-06-23T11:53:58.206Z"),
"lastHeartbeatRecv" : ISODate("2019-06-23T11:53:59.779Z"),
"pingMs" : NumberLong(0),
"lastHeartbeatMessage" : "",
"syncingTo" : "cluster1-shard-00-00-0vzv2.mongodb.net:27017",
"syncSourceHost" : "cluster1-shard-00-00-0vzv2.mongodb.net:27017",
"syncSourceId" : 0,
"infoMessage" : "",
"configVersion" : 1
}
],
"ok" : 1,
"operationTime" : Timestamp(1561290835, 1),
"$clusterTime" : {
"clusterTime" : Timestamp(1561290835, 1),
"signature" : {
"hash" : BinData(0,"ciN8v9Yw1hPlZS/iija7TU+NwBM="),
"keyId" : NumberLong("6705683970538864641")
}
}
}
MongoDB Enterprise Cluster1-shard-0:PRIMARY>

Connect with MongoDB Compass

  • In the Choose a connection method step, select Connect with MongoDB Compass.

Compass automatically detects the URI connection string in the system clipboard and asks for permission to auto-fill the connection form with the appropriate information. Click Yes.

  • Fill in the Password field with the password for the user from the connection string. For security purposes, the connection string does not include the password.

To connect with a different MongoDB user, update the Username and Password fields with the username and password of a different MongoDB user.

img26.jpg

img27.jpg

  • Capture mongodb cluster performance under performance tab

img28.jpg

Test Failover

You can use the following procedure to test the failure of a primary replica set member in your Atlas cluster and observe how your application responds to a replica set failover:

  1. Click Clusters.

  2. For the cluster you wish to perform failover testing, click on the  button.

  3. Click Test Failover.

  4. Atlas displays a Test Failover modal with the steps Atlas will take to simulate a failover event. Click Restart Primary to begin the test.

  5. Atlas notifies you in the Test Failover modal the results of your failover process.

img29.jpg

img30.jpg

img31.jpg

Import Data into Cluster

Live Migrate Your Replica Set to Atlas

The MongoDB Atlas Live Migration Service helps you migrate MongoDB databases to our fully managed cloud database, MongoDB Atlas, quickly and securely. It works by connecting to your existing MongoDB database and synchronizing it with a cluster running in Atlas all while your application continues to function normally. Once the data between the two clusters has been synchronized, you can simply update the database connection string in your application to cut over to your cluster in Atlas.

  • Your data is currently in a MongoDB database in AWS environment
  • Your current MongoDB database is running MongoDB 2.6 +
  • Atlas supports the latest versions of MongoDB: 3.4, 3.6, and 4.0. If you’re running MongoDB version 2.6 or greater, the Atlas Live Migration Service can move your data directly into a newer database version.
  • Your current deployment is a MongoDB replica set. : If your deployment is currently a standalone instance, please convert it to a replica set first.
  • Authentication is enabled on your source deployment
  • The database user from your source cluster on AWS that you will use to perform the migration has the required MongoDB roles.
use admin
db.getUser("admin")
{
  "_id" : "admin.admin",
  "user" : "admin",
  "db" : "admin",
  "roles" : [
    {
      "role" : "backup",
      "db" : "admin"
    },
    {
      "role" : "clusterMonitor",
      "db" : "admin"
    }
  ]
}
  • Launch your target replica set in MongoDB Atlas
  • Open Atlas Live Migration Service

On the Overview page of your new target cluster, click the ellipsis (…) button and select Migrate Data to this Cluster.

img32.jpg

  • Click I’m ready to migrate

img33

  • Whitelist the Atlas Live Migration Service on your AWS source cluster

At the top of the Migrate Data to Cluster modal, Atlas displays the IP address ranges that must be accessible from your source cluster. The address ranges displayed depend on the location of your target cluster and can change, so verify that you enter the address ranges as displayed in the modal.

AWS EC2 servers are protected from unauthorized network access using Security Groups. To whitelist new IP address ranges, either create a new Security Group, or modify your existing Security Group to permit inbound network access from the displayed IP address ranges.

Here is an example security group that grants access to Atlas Live Migration Service.

img34.jpg

Edit the Security Group  associated  with the EC2 instances running your source cluster and add the IP ranges specified by Atlas and click Save

img35.JPG

  • Validate your AWS credentials with Atlas Live Migration Service

On the Migrate Data to Cluster model, enter the hostname and port number of the primary node in your source AWS source cluster that Atlas will use to perform the data migration.

  • Enter the MongoDB username and password from the AWS source cluster in Username/Password.
  • If SSL is enabled on the source cluster, toggle the Is SSL enabled to Yes and upload the CA file that your source AWS cluster uses.
  • Click Validate

img37

  • Click Start Migration

A countdown timer in a progress bar indicates how much time remains before your target cluster is ready to migrate data from your source cluster. Wait until the countdown timer and the Start Cutover button are green before proceeding to the next step.

img36.jpeg

  • Click Start Cutover

Your AWS cluster and your Atlas cluster are now in sync. Atlas will maintain this synchronized state for 72 hours. If you need more time, syncing can be extended for another 24 hours.

Once you’re ready to begin, click the “START CUTOVER” button and follow the instructions. You will stop writes to your source cluster; this will enable the final writes to your source cluster to be applied to your new Atlas cluster. Once the cluster is caught up, you can end the syncing and restart your application servers pointing to the new cluster using your MongoDB Atlas connection string and database credentials.

Migrate with mongomirror

mongomirror is a utility for migrating data from an existing MongoDB replica set to a MongoDB Atlas replica set. mongomirror does not require you to shut down your existing replica set or applications.

https://docs.atlas.mongodb.com/import/mongomirror/

mongorestore Method 

To ensure a completely up-to-date migration, schedule a maintenance window where you can stop all writes to your source cluster. Any write operations issued to the source cluster after the mongodump portion of the procedure completes are not migrated to the target cluster.The total amount of downtime required depends on factors such as the size of data being migrated and the network connection between your source cluster and Atlas.

Ensure that the host where you are running mongodump and mongorestore is in the project IP whitelist.

mongodump --host 'sourceRS/source-host1:27017,source-host2:27017,source-host3:27017' \
  --archive --ssl \
  -username 'mySourceUser' -password 'sourcePassword' --authenticationDatabase admin \
| \
mongorestore --host myAtlasRS/atlas-host1:27017,atlas-host2:27017,atlas-host3:27017 \
  --archive --ssl \
  -username myAtlasAdminUser -password 'atlasPassword' --authenticationDatabase admin \
  --nsExclude 'admin.system.*'

Load File with mongoimport

The following example imports data from the file /somedir/myFileToImport.json into collection myData in the testdb database.

mongoimport --uri "mongodb://root:<PASSWORD>@atlas-host1:27017,atlas-host2:27017,atlas-host3:27017/<DATABASE>?ssl=true&replicaSet=myAtlasRS&authSource=admin" --collection myData --drop --file /somedir/myFileToImport.json

Set up a Network Peering Connection with AWS

You can configure the Atlas CIDR for a Network Peering connection if you have not yet added any clusters or network peering connections to an Atlas project.

MongoDB Atlas now allows you to directly peer virtual private clouds (VPCs) in your AWS accounts with the MongoDB Atlas VPC created for your MongoDB clusters. Easily create an extended, private network connecting your application servers and backend databases.

  • From the Clusters view, click the Security tab, then Peering.
  1. In the Security section of the left navigation, click Network Access.
  2. Click the Peering tab.

img38.jpg

  • Click New Peering Connection.
  • Select your cloud provider in the Peering Connection modal, then click Next.

img39.jpg

  • Enter the desired CIDR next to Atlas CIDR.
  • For AWS, the Atlas CIDR must be at least /24 and at most /21

img40

img41.jpg

  • Click Initiate Peering.

Note that the default VPC used for EC2 instances uses a CIDR block that overlaps with that used by MongoDB Atlas and so cannot be peered – a new one must be created.

img42.jpg

  • Wait for approval of peering connection request

The owner of the peer VPC must approve the VPC peering connection request. Ensure that the owner approves the request.

img43.jpg

  • Navigate to AWS VPC Service and from left VPC Dashboard choose Peering connections

img44.jpg

  • Click on actions and select Accept  Request

img45.jpg

 

img46.jpg

  • Add Atlas’ CIDR block to route tables
  • Navigate to route table in VPC Service and select on private subnet

img48

  • Add the Atlas VPC’s CIDR block to the Destination column.
  • Add the AWS Peering Connection ID to the Target column.This value is prefixed with pcx-.

img49.jpg

After accepting mongo Atlas request for peering connection, we will be able to see peering status as available in mongo Atlas console.

img50.jpg

From EC2 Dashboard select instance where you want to connect Mongo Atlas Database, then navigate to security group of EC2 Instance of mongoDB server and application server  and make an entry in Whitelist entry in Mongo Atlas Console.

img51.jpg

img52.jpg

Once set up, you can edit or terminate VPC peering connection from the Peering table.You must add your VPC CIDR block address (or subset) or the Security Group associated with the peer VPC to the whitelist before your new VPC peer can connect to your Atlas cluster.

Modify a Cluster

For the cluster you want to modify, click the ellipses  icon, then select Edit Configuration.Alternatively, if you are already viewing the specific cluster, click the Configuration button.

img53

 

img54.jpg

Upgrade the MongoDB Version of the Cluster

Select Additional Settings to view the currently configured MongoDB version for the cluster.

Atlas always upgrades the cluster to the latest stable release of the specified version via a rolling process to maintain cluster availability.

You cannot downgrade the cluster to an earlier MongoDB version.

Select the new MongoDB version from the Select a version dropdown and click apply changes.

Atlas supports the following upgrade paths:

  • MongoDB 3.4 -> MongoDB 3.6
  • MongoDB 3.6 -> MongoDB 4.0

img55

img56.jpg

Monitoring and Alerts

  • View Metrics for an Atlas Replica Set

To view the metrics for a specific Atlas cluster in a project, click the Metrics button for that cluster. Alternatively, click on the name of the cluster to open the cluster overview, then click the Metrics tab.

img57.jpg

  • Atlas provides the following controls for the Metric view.

img58.jpg

  • View Alerts

To view all open alerts, click Alerts in the Project section of the left navigation.

img59.jpg

To acknowledge an alert, click Alerts in the Project section of the left navigation, locate the alert, and click Acknowledge.

Configure Alert Settings

  • Click Alerts in the Project section of the left navigation.
  • Choose whether to create a new alert setting or clone an existing one
  • To create a new alert without cloning an existing setting:
    1. Click Add.
    2. Select New Alert.

To clone an existing alert setting:

  1. Click the Alert Settings tab.
  2. Locate the alert setting you want to clone.
  3. Click ellipsis  icon then Clone in that alert setting’s row.

img60.jpg

img61.jpg

  • Disable an Alert

img62.jpg

You can use a third-party application to view and analyze performance metrics that Atlas collects about your cluster.

At this time, you can either build a monitoring integration using the Atlas API or integrate Atlas with Datadog

Performance Advisor

The Performance Advisor monitors queries that MongoDB considers slow and suggests new indexes to improve query performance. The Performance Advisor recognizes a query as slow if it takes longer than 100 milliseconds to execute. For the selected host and time period, the Performance Advisor evaluates up to the 20,000 most recent slow queries found in the logs.

img63.jpg

Real-Time Performance Panel

The Real-Time Performance Panel (RTPP) monitors and displays current network traffic, database operations on the machines hosting MongoDB in your clusters, and hardware statistics about the hosts. Use RTPP to visually identify relevant database operations, evaluate query execution times and the ratio of documents scanned to documents returned, monitor network load and thoughput, and discover potential replication lag on secondary members of replica sets.

img64.jpg

Fully Managed Backup Service

Continuous Backups

Atlas continuous backups take incremental backups of data in your cluster, ensuring your backups are typically just a few seconds behind the operational system. Atlas continuous backups allow you to restore from stored snapshots or from a selected point in time within the last 24 hours. You can also query a continuous backup snapshot.

img65.jpg

Atlas has the following snapshot schedule, which determines the frequency and the retention of the snapshots

img66.JPG

By default, Atlas takes base snapshots every 6 hours.

To change a deployment’s snapshot schedule, including the retention policy, go to Backup. For the cluster whose snapshot schedule you wish to modify, click the ellipsis and select Edit Snapshot Schedule menu option.

img67.jpg

Cloud Provider Snapshots

Atlas Cloud Provider Snapshots provide localized backup storage using the native snapshot functionality of the cluster’s cloud service provider.

Atlas encrypts all snapshot volumes, ensuring the security of cluster data at rest (Encryption at Rest). For projects and clusters using Encryption at Rest Using Your Key Management, Atlas applies an additional layer of encryption to your snapshot storage volumes using the Key Management Service (KMS) provider configured for the cluster.

Query a Continuous Backup Snapshot

Atlas supports querying a continuous backup snapshot. This functionality allows you to query specific continuous backup snapshot.

img68.jpg

For the cluster whose backup you want to query, click the ellipsis button under Options column and select Query.

  • Select the snapshot to query and click Next.
  • Start the process to query a snapshot. If prompted for your password, enter your password to verify.
  • Select Backup Tunnel as the connection method to the queryable snapshot.
  • Select your Platform and download.
  • Uncompress the downloaded file.
  • Open a terminal or command prompt and go to the uncompressed <tunnel> directory. Run the executable to start the tunnel.

img69.jpg

Open a terminal or command prompt and go to the uncompressed <tunnel> directory. Run the executable to start the tunnel.

The default port for the tunnel is 27017. To change the port, use the –local flag, as in the following example:

./<tunnel executable> --local localhost:27020

Restore a Cluster from a Continuous Backup Snapshot or Point in Time

Atlas lets you restore data from a scheduled continuous backup snapshot or from a selected point between snapshots. For replica sets, you can restore from selected points in time within the last 24 hours. For sharded clusters you can restore from checkpoints between snapshots within the last 24 hours.

  • The restore process requires downtime for the target cluster
  • The MongoDB versions must also be compatible. For instance, you cannot restore from a snapshot of a 4.0 cluster to a 3.6 or earlier cluster.
  • You must ensure that the Atlas cluster does not receive client requests during restoration.
  • Ensure that the source Atlas cluster cannot receive client requests while you restore data.
  • Choose the cluster to restore
  • Hover over the Active status of the cluster and click Restore or Download

img70.jpg

  • Choose the point from which you want to restore your backup

Restoration Type 

Snapshot Allows you to choose one stored snapshot
Point In Time

Creates a custom snapshot that includes all operations up to but not including the selected time. By default, the Oplog Store stores 24 hours of data.

Oplog Timestamp(Replica Sets Only)

Creates a custom snapshot that includes all operations up to and including the entered Oplog timestamp.

Finding latest oplog entry

db.getSiblingDB('local').oplog.rs.find().sort({$natural:-1}).limit(1).pretty()

img71.jpg

img72.jpg

  • Click Choose Cluster to Restore to

img73.jpg

img74.jpg

  • Click confirm and continue

Downloading logs with MongoDB Atlas 

Select the replicaset cluster and navigate to ellipsis button and click on Download logs

img75.jpg

Select the server and select the time frame where logs are required and click download

img76

Set up Database Auditing

Auditing allows administrators to track system activity for deployments with multiple users. Atlas administrators can select the actions that they want to audit, as well as the MongoDB users, Atlas roles, and LDAP groups whose actions they want audited.

  • In the Security section of the left navigation, click Advanced
  • Toggle the button next to Database Auditing to On
  • Select the MongoDB users, Atlas roles, and LDAP groups whose actions you want to audit in Select users and roles.
  • Select the event actions that you want to audit in Select actions to audit.
  • Click Save

To retrieve the audit logs in Atlas, see MongoDB Logs.

img77.jpg

Configure Two-Factor Authentication

Two-factor authentication provides a second layer of security for your Atlas account. If you enable 2FA for your account and after you enter your username and password, you are prompted for a six-digit time-sensitive verification code.

  • Go to your Atlas Account Settings.
  • Enable Two-Factor Authentication
  • Configure Voice/SMS Authentication

img78.jpg

img79.jpg

Atlas can generate single-use recovery codes for use where all other methods of accessing the account fail. When you generate new recovery codes, you invalidate previously generated ones.

MongoDB Charts 

Charts provides the simplest and fastest way to create visualizations of your data stored in MongoDB, but up until now you could only view those charts if you had access to the Charts application. That works great for small teams, but not so much in cases where you have a larger audience or if you wanted to show your charts in a specific context like in an internal business application.

Everything changes now that we’ve added Embedding to MongoDB Charts on Atlas. Once you’ve created a chart using the Charts application, you’re free to share it with anyone you want by embedding it into any web site.

chart

Charts then helpfully provides an <IFRAME> snippet with the chart’s URL, which you can copy and paste into your website. Since the embedding is unauthenticated, anyone can find the <IFRAME> code in the page source, copy it and embed the chart wherever they want (try it!).

MongoDB Atlas Data Lake 

MongoDB Atlas Data Lake is a new member of the MongoDB Atlas family which has just been announced at MongoDB World and is available in public beta. It brings the technology that has made MongoDB the most popular document database in the world and applies it to the great data lakes of the cloud. As companies have accumulated more and more data in cloud storage like Amazon S3, so the need to process that data effectively has risen.

With MongoDB Atlas Data Lake, you use the MongoDB Query Language, which is built for rich, complex structures and work with data stored in JSON, BSON, CSV, TSV, Avro, and Parquet formats. Data is analyzed on demand with no infrastructure setup and no time-consuming transformations, pre-processing or metadata management. There’s no schema to pre-define, allowing you to work with your data faster.

As an on-demand service available in MongoDB’s Atlas cloud data platform, there’s no deployment process. All you need to begin your data exploration is to provide access to your S3 storage buckets. Users will configure Atlas Data Lake from the same UI as MongoDB Atlas operational clusters though a simple wizard to configure permissions, give read-only access to their S3 buckets, map S3 directories to databases and collections and get them ready to run queries. Atlas Data Lake will also provide stats on queries executed, data scanned and returned as well as average execution time.

By leveraging the MongoDB Query Language, you can apply one skill set to your data lake and your transactional databases. It isn’t just the query language that works with Data Lake. The service is compatible with MongoDB drivers, the MongoDB Shell, MongoDB Compass and MongoDB BI Connector. That means applications written in JavaScript, Perl, Python, C, C++, Java, Ruby, Go, Scala, R and many other languages can access Data Lake using drivers MongoDB users are deploying every day. Data scientists will be able to use tools such as R Studio with our R driver or Jupyter Notebooks with our Python driver for statistics, machine learning and data lake analytics.

Behind the scenes, the MongoDB Atlas Data Lake currently deploys multiple compute nodes to analyze each S3 bucket and process queries against that storage bucket’s data. These nodes work in parallel and in the bucket’s region for fast processing and to minimize data transfer and the associated cost. When done, each node returns its results to a central node that sorts, filters and aggregates the separate results into a final result as needed. For the Data Lake user, this process is entirely transparent and allows them to get on with their work extracting the value and insight from that data. It also means that there are no limits to concurrent queries being applied to the data. Future enhancements to the compute node architecture will also be transparent to the user.

datalake-litoozk4n1.png

MongoDB Stitch

MongoDB Stitch is a serverless platform that enables developers to quickly build applications without having to set up server infrastructure. Stitch is built on top of MongoDB Atlas, automatically integrating the connection to your database. You can connect to Stitch through the Stitch Client SDKs, which are available for many of the platforms that you develop for including JavaScript, iOS, and Android.

Stitch simplifies the process of authenticating and managing your application’s users. The built-in authentication providers allow users to log in with an email/password, an API Key, or an external OAuth service. If the built-in providers don’t cover your use case, you can integrate your own custom provider.

Stitch can automatically execute trigger functions in response to user authentication events or changes in your MongoDB database. You can also create incoming webhooks to allow external services to interact with your application remotely.

Reference 

https://www.mongodb.com/collateral/mongodb-atlas-best-practices

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Powered by WordPress.com.

Up ↑

%d bloggers like this: