This chapter introduces CouchDB’s world class replication system. Replication synchronizes two copies of the same database, allowing users to have low latency access data no matter where they are. These databases can live on the same server or on two different servers, CouchDB doesn’t make a distinction. If you change one copy of the database, replication will send these changes to the other copy.
Replication is a one-off operation: You send an HTTP request to CouchDB that includes a source and a target database and CouchDB will send the changes from the source to the target. That is all.
POST HTTP/1.1
{"source":"database","target":"http://example.org/database"}
If you want to send changes from the target to the source database (do bi-directional replication), you just make the same HTTP requests, only with source and target database swapped. That is all.
POST HTTP/1.1
{"source":"http://example.org/database","target":"database"}
A remote database is identified by the same URL you use to talk to it. CouchDB replication works over HTTP using the same mechanisms that are available to you.
|
If you are coming from MySQL, you might be used to continuous replication. You can set this up with CouchDB as well. We’ll get to that in Chapter 16 “Automatic Replication”.
|
When you ask CouchDB to replicate a database to another one, it will go and compare the two databases to find out which documents on the source differ from the target and then submit a batch of the changed documents to the target until all changes are transferred. Changes include new documents, changed documents and deleted documents.
Databases in CouchDB have a sequence number that gets incremented every time the database is changed. CouchDB remembers what changes came with which sequence number. That way, CouchDB can answer questions like “What changed in database A between sequence number 212 and now” by returning a list of new and changed documents. Finding the differences between databases with this is an efficient operation. It also adds to the robustness of replication.
|
|
CouchDB views use the same mechanism to make sure views are up to date. You can use this to build your own solutions as well.
|
Replication usually happens between two instances of CouchDB that live on different servers, potentially hundreds or thousands of miles apart. Problems are bound to happen. Servers crash, network connections break off, things go wrong. When a replication process is interrupted and then restarted, CouchDB continues where it left off.
You can run replication from your Web browser using Futon, CouchDB’s built-in administration interface. Start CouchDB and open your browser at http://127.0.0.1:5984/_utils/. On the right hand side you will see a list of things to visit in Futon, click on "replication".
Futon will show you an interface to start replication. You can specify a source and a target by either picking a database from the list of local databases or you can fill in the URL of a remote database.
Click on the Replicate button, wait a bit and have a look at the lower half of the screen where CouchDB gives you some statistics about the replication run or, ir an error occurred, an explanatory message.
Congratulations, you ran your first replication.
Replication is the foundation on which the following chapters build on. Make sure you understood this chapter. If you don’t feel comfortable yet, just read it again and play around with the replication interface in Futon. The next chapter explains how you can use replication to scale read requests.