发布于 2015-09-14 15:26:21 | 168 次阅读 | 评论: 0 | 来源: 网络整理
The MongoDB Worker Role is currently a preview release. Please provide feedback at mongodb-dev, mongodb-user, or IRC #mongodb.
The MongoDB Worker Role project allows you to deploy and run a MongoDB replica set on Windows Azure. Replica set members are run as Azure worker role instances. MongoDB data files are stored in an Azure page blob mounted as a cloud drive. One can use any MongoDB driver to connect to the MongoDB server instance. The MongoDB .Net driver is included as part of the package.
The MongoDB Azure Worker Role is delivered as a Visual Studio 2010 solution with associated source files. You can access the package at GitHub:
<https://github.com/mongodb/mongo-azure/>
It is recommended using the latest tagged version.
Alternatively, you can clone the repository run the following commands from a git bash shell:
cd <parentdirectory>
git config --global core.autocrlf true
git clone git@github.com:mongodb/mongo-azure.git
cd mongo-azure
git config core.autocrlf true
You must set the global setting for core.autocrlf to true before cloning the repository. After you clone the repository, we recommend you set the local setting for core.autocrlf to true (as shown above) so that future changes to the global setting for core.autocrlf do not affect this repository. If you then want to change your global setting for core.autocrlf to false run:
git config --global core.autocrlf false
Once you have unzipped the package or cloned the repository, you will see the following directories:
We assume you’re running Windows x64 and Visual Studio. If not, install those first; Visual Studio 2010 or Visual Web Developer 2010 should work.
The setup script does the following:
注解
The setup script downloads the 64-bit version of MongoDB by default. If you are developing with 32-bit Windows, you must download the latest 32-bit MongoDB binaries and place them in libMongoDBBinaries yourself. Do this after running solutionsetup.cmd so it won’t overwrite your work.
The prerequisites can be found in the Github readme.
Once these are installed, you can open either solution MongoDB.WindowsAzure.sln for just the replica set and the monitoring application; MongoDB.WindowsAzure.Sample.sln for the replica set, monitoring application and a sample IIS app, MvcMovie, to test it.
The following instructions are for running the sample application.
To start, you can test out your setup locally on your development machine. The default configuration has 3 replica set members running on ports 27017, 27018 and 27019 with a replica set name of ‘rs’.
In Visual Studio, run the solution using F5 or Debug->Start Debugging. This will start up the replica set, the monitoring application and the MvcMovie sample application (if you are in the sample solution).
You can verify this by using the monitoring application or MvcMovie sample application in the browser or by running mongo.exe against the running instances.
Once you have the application running locally, you can deploy the sample app solution to Windows Azure. You cannot execute locally (on the compute emulator) with data stored in Blob store. This is due to the use of Windows Azure Drive which requires both compute and storage are in the same location.
The MongoDB Worker Role runs mongod.exe with the following options:
--dbpath --port --logpath --journal --nohttpinterface --logappend --replSet
MongoDB creates the following containers and blobs on Azure storage:
Can I run mongo.exe to connect?
Role instances do not start on deploy to Azure
Occasional socket exception using the .Net driver on Azure
This is usually due to the fact that the Azure load balancer has terminated an inactive connection. This can be overcome by setting the max idle connection time on the driver.
MongoDefaults.MaxConnectionIdleTime = TimeSpan.FromMinutes(1);
My MongoDB instances are running fine on the worker roles. The included manager app shows the instances are working fine but my client app cannot connect.
Ensure that the Instance Maintainer exe is deployed as part of the client role. You also need to change the Service Definition for the client role to have the InstanceMaintainer started on instance start.
Refer to images below:
Instance Maintainer deployed as part of role:
Instance Maintainer start defined in service definition: