Andrew Davidson

4 results

How to Evaluate MongoDB 3.4 Using Your Existing Deployment in MongoDB Atlas

MongoDB 3.4 was just released with support for graph processing, multi-language collations, read-only views, faceted navigation, powerful new aggregation operators, numerous performance improvements, and more. MongoDB 3.4 is available in the MongoDB Atlas database service today, so you can quickly and easily deploy new clusters and try it out. But what’s the best way to evaluate MongoDB 3.4 against an existing production workload you have running in MongoDB Atlas? As with any software upgrade, you should first test your application. MongoDB Atlas automates spinning up new production-ready MongoDB clusters, manages backups and restores, and automates on-demand upgrades of MongoDB from 3.2 to 3.4 at any time. By combining these capabilities, you can very easily: Spin up a test environment from a backup Upgrade the test environment from MongoDB 3.2 to MongoDB 3.4 Confirm that your testing and performance suite pass on MongoDB 3.4 Specifically, in this tutorial we’re going to: Start with a production MongoDB Atlas cluster (“Cluster0”) running MongoDB 3.2 with the Atlas backup service enabled. Spin up a new MongoDB Atlas test cluster, initially on MongoDB 3.2, (“cluster34upgrade”) with sufficient storage to restore the production cluster’s backup. Restore the most recent backup snapshot from the production cluster into the test cluster. Upgrade the test cluster from MongoDB 3.2 to MongoDB 3.4 Execute our test suite against the MongoDB 3.4 test cluster. If all goes well, we can upgrade our production cluster to MongoDB 3.4 and terminate our test cluster. This upgrade will be made in-place, and will be completed without application downtime. 1. Start with a MongoDB Atlas cluster (“Cluster0”) running MongoDB 3.2 and with the Atlas backup service enabled. For purposes of this tutorial, we have pre-loaded this cluster and have it under active load. ** 2. Create a new MongoDB Atlas cluster, initially on MongoDB 3.2, (“cluster34upgrade”) with enough storage to restore the production cluster’s backup.** We’ll follow the “Add new cluster” flow and deploy an M20 instance with 40GB of storage, just like our production cluster in this example. Note that for your live production deployments, we do recommend that you run on a MongoDB Atlas M30 or higher. After the cluster deploys, we’ll see the following: 3. Restore the most recent backup snapshot from the production cluster into the test upgrade cluster. We’ll navigate into the “Backup” tab and find the backup for our production cluster. Click into the Options menu (“...”) and select “Restore”. Choose the most recent snapshot. Select “Restore my snapshot” to restore it into our test MongoDB cluster. Select the test upgrade cluster as the destination for the restore. Now the automated restore into the test cluster will be performed. Depending on the size of the data files being restored, this operation could take some time. After the restore finishes, we’ll see the following: 4. Upgrade the test upgrade cluster from MongoDB 3.2 to MongoDB 3.4 Now we can initiate our testing procedures to understand the implications at the application tier during the online upgrade process. To perform the upgrade, we’ll select “Configuration” on the new test cluster which we’ve just restored our backup into: Next, we’ll click “Change version” and select “MongoDB 3.4 with WiredTiger” After selecting MongoDB 3.4, we’ll see the important notice that downgrading from MongoDB 3.4 to 3.2 will not be possible. This is one of the reasons why performing a test cluster upgrade is highly recommended. After deploying we’ll see the blue bar during the upgrade: And quickly we’ll have an upgraded cluster running on MongoDB 3.4: 5. Execute our test suite against the MongoDB 3.4 test upgrade cluster. We will go ahead and confirm connectivity of all of the clients that utilize our cluster and put the new cluster through our entire test and performance suite if it wasn't already running since before initiating the upgrade. We’ll either confirm that we’re ready for MongoDB 3.4, or potentially unearth areas for tuning or necessary driver upgrades, depending on our usage. 6. If our tests pass, we can upgrade our production cluster to MongoDB 3.4 and terminate our test cluster. We’ll click “Configure” on our production cluster Because MongoDB Atlas is built on replica sets, the upgrade process performs a rolling restart of the cluster. As a result, the production application remains available and online. And we can terminate our test cluster if we no longer want to maintain it for testing. Next steps If you’re an existing MongoDB Atlas user on MongoDB 3.2, we encourage you to review compatibility changes in MongoDB 3.4 and the full release notes . You can then follow the process outlined above to restore a backup to a new cluster and upgrade it to MongoDB 3.4 . If you’re new to MongoDB Atlas, you can easily deploy your first MongoDB 3.4 cluster : Just click the "Build a new cluster" button. Then select MongoDB 3.4 in the build cluster form.

December 5, 2016

Introducing VPC Peering for MongoDB Atlas

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. VPC Peering in MongoDB Atlas is a significant ease of use and security improvement: Your application servers (and development environments) can directly connect to MongoDB Atlas while remaining isolated from public networks. Automatically scale your application tier without having to manage your database firewall rules. Peer multiple VPCs in the same region from your AWS account(s) to each MongoDB Atlas group. Security groups from your peered VPC can even be referenced in MongoDB Atlas clusters. Tutorial Let’s walk through what using this functionality feels like. Prerequisites: Create an AWS account Create a VPC Enable “DNS hostnames” on the VPC (optional). This will make it possible to immediately resolve the hostnames in the peered MongoDB Atlas clusters VPC to their private IP addresses (otherwise propagation can take up to one hour). Launch instances that you can SSH into Download MongoDB shell software onto those instances to confirm connectivity Create a MongoDB Atlas account Deploy a cluster in the same region as your AWS VPC Step by Step Guide Register for a MongoDB Atlas account. Deploy cluster (US-East region is shown here) While the database cluster is deploying, navigate to the “Security” tab’s “Peering” section Add a New Peering Connection and include the information about your existing VPC (helpful “Show me how” instructions can be found throughout this process) 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. I created a VPC with a CIDR block “10.0.0.0/16” for testing, like so: Enable “DNS hostnames” on the VPC and record the VPC ID for use in the peering form: Before using the VPC for any EC2 instances, it is necessary to create a new subnet for the VPC, in this case I used the full CIDR of the VPC: Create an EC2 instance using the new VPC and subnet: Fill in the peering request form as shown below (AWS account detail omitted) and include the entire VPC CIDR (10.0.0.0/16); you could optionally include a subset here. Notes: In this example, I am leaving the default option, “Add this CIDR block to my IP whitelist”, selected so that I will be able to immediately connect (but as we’ll see later, I could instead use a security group). Also, because I have already created a MongoDB Atlas cluster, the MongoDB Atlas region and CIDR block cannot be adjusted (if I were in a new MongoDB Atlas group that did not have a cluster yet, I could specify those). At this point, assuming you have correctly filled in the peering request details, you should see “Waiting for Approval”. The UI shown below contains a helpful “How do I approve the connection?” section with two steps: i. Accept the peering request in my AWS account and ii. Add the route table entry for the Atlas CIDR Block shown in the top right so that my VPC routes to the MongoDB Atlas VPC In the AWS Console, under the VPC Dashboard, in the “Peering Connections” section, choose “Accept Request”. In the AWS Console under the “Route Table” for your VPC, choose “Add another rule”, paste in the MongoDB Atlas CIDR block, and associate it with the VPC peering connection. a. b. c. d. e. f. Note that if you don't see a 0.0.0.0/0 route associated with an internet gateway then you should add one if you want to SSH directly into your VPC’s instances from your laptop – this may necessitate creating a new internet gateway. After accepting the Peering Connection in our VPC, MongoDB Atlas will display the Peering Connection as “Available” (this may take up to 10 minutes to show) Now let’s demonstrate connectivity in this tutorial by navigating to our cluster in MongoDB Atlas and clicking “Connect” to follow instructions. a. b. We can confirm that the CIDR block associated with our Peered VPC has already been added to our IP address whitelist c. d. We’ll download and extract the MongoDB shell for the operating system of the instance in our VPC, and use the ‘mongo’ shell instructions shown below e. Success! We’ve connected successfully without having any public IP addresses open to our MongoDB Atlas cluster! Now let’s remove the CIDR block (IP addresses) from our IP Address Whitelist, and demonstrate that we can instead reference a Security Group from our peered VPC a. We’ll navigate to “Security” tab’s “IP Whitelist” section b. After clicking “Delete” on the Peer VPC’s CIDR Block (10.0.0.0/16 in this case) we’ll see c. Let’s add an inbound rule to our EC2 instance’s Security Group such that connectivity on ports 27000-28000 can be made within the Security Group itself d. Now we’ll click “Add IP Address” but specifically enter the security group ID associated with the instance in our VPC e. Now we can confirm connectivity again (with no explicit IP Addresses in our white list) — Awesome! #### Next steps [Register for MongoDB Atlas](https://www.mongodb.com/cloud/atlas?jmp=blog) and deploy your first cluster today!

November 3, 2016

Parse shutdown: How to seamlessly continue operations with AWS and MongoDB Cloud Manager

Editor's note: Existing hosted Parse users can migrate their back-end using Parse's Database Migration tool directly to MongoDB Atlas. See how in this tutorial . Parse was a bold offering in the burgeoning space of Backend-as-a-Service, and we’re sorry to see them wind down. MongoDB was founded to make it easy for application developers to build great products for their users, so we are 100% behind projects that serve that mission on another level; and we are proud that Parse built their backend service on top of MongoDB. Fortunately, Parse has provided their users with a viable and straightforward migration path. Along with their announcement, they released Parse Server, an open source replacement for their hosted backend. To use this solution, a team needs to provision a private MongoDB database, migrate their Parse data to their MongoDB instance, deploy the Parse Server into a hosting environment of their choosing, and update their client to issue API calls to their new Parse Server. MongoDB Cloud Manager’s tight integration with AWS and Azure makes it easy to set up a MongoDB deployment, and AWS’s Elastic Beanstalk makes deploying Parse Server relatively easy. Together with the data migration tool that Parse is providing, the transition can be as seamless and painless as possible. To that end, we have put together a comprehensive guide to migrating a Parse backend to AWS with Cloud Manager and Elastic Beanstalk. A guide to doing the same with Azure is in development and will be posted soon. Using either solution will maximize the portability and stability of your new infrastructure. The guides are aimed at mobile developers without assuming any prior experience with MongoDB, Node.js, or AWS. They provide watertight, high-level checklists, with guidance for what effort you can expect to expend at each stage, as well as detailed, step-by-step directions for each. In addition, they are great jumping-off points to the specific MongoDB documentation relevant to those migrating from Parse, such as how to manage indexes and set up monitoring. Migrate from Parse to MongoDB and AWS Learn more. Join us for a live presentation on the steps required to migrate from the Parse platform to your own deployment of MongoDB on Amazon Web Services.

February 3, 2016