A new preview release of the MongoDB controller for Azure is available. This release includes support for replica sets, and over the coming months, we’ll be adding support for MongoDB’s sharding facilities. We’ll also be working to more tightly integrate MongoDB with the features of Azure platform.
This post was originally authored by Sridhar Nanjundeswaran with Robert Stam, and Nosh Petigara on the MongoDB Blog.
Each member of a replica set is hosted by an instance of an Azure worker role, so the size of the replica set is determined by the number of instances configured for the the replica set worker roles. Each replica set worker role creates a child process to run the mongod server process.
The controller defines an Azure worker role which represents a MongoDB cluster. Currently the cluster consists of a single MongoDB replica set. Each role instance participates as a member of the replica set. On deployment the controller configures the replica set and initiates it. Role instances handle restarts, including assuming identity for a replica set member and replacing old instances. The worker role also integrates with Azure Diagnostics to capture trace and performance counter information.
The MongoDB Azure wrapper release is currently delivered as a Visual Studio 2010 solution with associated source files, and we’ll follow that up in the future with packaging and deployment tools. To get started, take a look at the documentation or browse through the source. We’ve included a small sample application to get you up and running quickly. If you have questions, head over to our user mailing list or file a bug report on our JIRA system.
Microsoft will be presenting at the MongoSV
conference in Santa Clara on December 9th. It will be a great
opportunity to understand the solution in depth, as well as understand
the future direction of this project. We hope to see you there.
Comments from the post answering user questions:
Data safety is attained by using Azure blobs as posted below. As far as high availability you get that through the normal MongoDB replica set mechanism. By having at least 2 instances you will be assured that you will always have an "available cluster" even during the reboots for security patches.
The actual data files are persisted in Azure blob storage. Hence even if an instance dies the data is not lost. When a replacement instance comes up it will remount this blob so it does not have to resync all data.