Raven Studio got some love in RavenDB 2.0. You can download an unstable build from Raven's site to check it out (which I strongly encourage). Among the many changes to the studio is the ability to administer bundles. Now you can enable bundles during the database creation step.
Activating Bundles##
I don't know about you, but I already have a bunch of Raven databases. It would be great if the same bundle management features were made available all of the time. For now, you have to do it manually. In Raven Studio, click on the configuration icon to view the document for your database:
{
"Id": "Hammer",
"Settings": {
"Raven/DataDir": "~\\Databases\\Hammer",
"Raven/ActiveBundles": ""
},
"SecuredSettings": {},
"Disabled": false
}
Notice that there's a property in the settings object called Raven/ActiveBundles. Adding bundle names to this value enables them. The bundle names are delimited with semicolons. Here's a list of the available bundle keys:
- Compression
- Encryption
- DocumentExpiration
- Quotas
- Replication
- Versioning
- Authorization
Since this post is about Replication, we'll activate that bundle for the database.
{
"Id": "Hammer",
"Settings": {
"Raven/DataDir": "~\\Databases\\Hammer",
"Raven/ActiveBundles": "Replication"
},
"SecuredSettings": {},
"Disabled": false
}
Fair warning: tampering with the database document is a risk. Raven Studio even makes a point to warn you that changing system documents can cause irreversible damage. Please exercise caution.
Configuring Replication##
After you save the changes to the document, you should see a section on the left for Replication configurations.
One important thing to remember with Replication is that it won't work unless all servers are aware of it. That means going to each Raven server that will participate in replicating the Hammer database, and adding Replication to the list of active bundles. Once each server has Replication turned on, all behavior comes from how you configure it.
In the UI, you can click the Add Replication button to add a destination.
You'll have to add one for each destination. Also note that there are authentication options as well, for when you start locking down your Raven servers.
This configuration is pretty convenient, because you didn't have to dig too deep into documentation to get things running. Let's not forget what really happened under the covers. A new document was created with the ID Raven/Replication/Destinations which contains a collection of destination servers and their respective settings.
Replication Failures##
If replication isn't working, you'll be able to tell fairly quickly:
A document will be created to represent a destination that is unable to be replicated to. In this case the ID of the document is Raven/Replication/Destinations/localhost4003databasesHaHa, which contains a stripped down version of the destination Url. The failures are because no database exists on localhost:4003 named HaHa.
In the above screenshot you can see a non-zero failure count. This value will increase quickly as you refresh the grid. Once the failures stop, this document is removed. It's fair to say that early on, you're most likely to see failures because of an invalid configuration.
Summary##
This is a great improvement for configuring replication. Previously, it involved copying a bundle dll to your Raven server to install it, and then manually adding documents to set it all up. While it's not a complicated process, it's not as convenient as entering data into a few text boxes. This is also true for the setup experience of the other core bundles.