SQL Replication has been a part of RavenDB for quite some time, showing up for the first time in the 1.0 build as the Index Replication Bundle. This turned out to be a very useful feature, and in 3.0 we had a dedicated developer for this for several weeks, banging it into new and interesting shapes.

We started out with a proper design for how you want to use it. And I’m just going to take you through the process for a bit, then talk about the backend changes.

We start by defining a named connection string (note that you can actually test this immediately):

And then we define the actual replication behavior:

Note that we have the Tools control in the top? Clicking it and selecting Simulate will give you:

So you can actually see the commands that we are going to execute to replicate a specific document. That is going to save a lot of head scratching about “why isn’t this replicating properly”.

You can even run this simulation against your source db, to check for errors such as constraint violations, etc.

The SQL Replication bundle now support forcing query recompilation, which avoid bad query plans caching in SQL Server:

And for the prudent DBA, we have done a lot to give you additional information. In particular, you can look at the metrics and see what is going on.

And:

In this case, I actually don’t have a relational database on this machine to test this, but I’m sure that you can figure it out.

The nice thing about it, we’ll report separate metrics per table, so your DBA can see if a particular table is causing a slow down.

Overall, we streamlined everything and tried to give you as much information upfront as possible, as well as tracking the entire process. You’ll find it much easier to work with and troubleshoot if needed.

This actually ties very well with our next topic, the operations changes in RavenDB to make it easier to manager. But that will be in the a future post.