couchdb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Couchdb Wiki] Trivial Update of "Replication" by ChrisDurtschi
Date Fri, 17 Sep 2010 20:30:31 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Couchdb Wiki" for change notification.

The "Replication" page has been changed by ChrisDurtschi.
The comment on this change is: Fixed _id of design document filter example.
http://wiki.apache.org/couchdb/Replication?action=diff&rev1=24&rev2=25

--------------------------------------------------

  <<TableOfContents()>>
  
  == Overview ==
- 
  The replication is an incremental one way process involving two databases (a source and
a destination).
  
  The aim of the replication is that at the end of the process, all active documents on the
source database are also in the destination database and all documents that were deleted in
the source databases are also deleted (if exists) on the destination database.
@@ -14, +13 @@

  Changes on the master will not automatically replicate to the slaves. See “Continuous
Replication” below.
  
  === Run Replication ===
- 
  Replication is triggered by sending a POST request to the `_replicate` URL with a JSON object
in the body that includes a `source` and a `target` member.
- 
  
  {{{
  POST /_replicate HTTP/1.1
  
  {"source":"example-database","target":"http://example.org/example-database"}
  }}}
- 
  `source` and `target` can both point at local databases, remote databases and any combination
of these.
  
  If your local CouchDB instance is secured by an admin account, you need to use the full
URL format
@@ -33, +29 @@

  
  {"source":"http://example.org/example-database","target":"http://admin:password@127.0.0.1:5984/example-database"}
  }}}
- 
  The target database has to exist and is not implicitly created. Add `create_target:true`
to the JSON object to create the target database (remote or local) prior to replication. The
names of the source and target databases do not have to be the same.
- 
  
  Specifying a local `source` database and a remote `target` database is called ''push replication''
and a remote `source` and local `target` is called ''pull replication''. As of CouchDB 0.9,
pull replication is a lot more efficient and resistant to errors, and it is suggested that
you use pull replication in most cases, especially if your documents are large or you have
large attachments.
  
  === Continuous replication ===
- 
  To make replication continuous, add "continuous":true parameter to JSON, for example:
  
  {{{
@@ -48, +41 @@

  
  {"source":"http://example.org/example-database","target":"http://admin:password@127.0.0.1:5984/example-database",
"continuous":true}
  }}}
- 
  At this time, CouchDB doesn’t remember continuous replications over a server restart.
For more info visit http://books.couchdb.org/relax/reference/replication - CouchDB: The Definitive
Guide, chapter Replication.
  
  === Cancelling a continuous replication task ===
- 
  To cancel a continuous replication task, add "cancel":true parameter to JSON, for example:
  
  {{{
@@ -60, +51 @@

  
  {"source":"http://example.org/example-database","target":"http://admin:password@127.0.0.1:5984/example-database",
"continuous":true, "cancel":true}
  }}}
- 
  === Filtered Replication ===
- 
  Sometimes you don't want to transfer all documents from source to target. You can include
one or more filter functions in your design document and then tell the replicator to use them.
  
  A filter function takes two arguments (the document to be replicated and the the replication
request) and returns true or false. If the result is true, then the document is replicated.
@@ -76, +65 @@

    }
  }
  }}}
- 
  Filters live under the top-level "filters" key;
  
  {{{
    {
-     "_id":"myddoc",
+     "_id":"_design/myddoc",
      "filters": {
        "myfilter": "function goes here"
      }
    }
  }}}
- 
  Invoke them as follows;
  
  {{{
  {"source":"http://example.org/example-database","target":"http://admin:password@127.0.0.1:5984/example-database",
"filter":"myddoc/myfilter"}
  }}}
- 
  You can even pass arguments to them;
  
  {{{
  {"source":"http://example.org/example-database","target":"http://admin:password@127.0.0.1:5984/example-database",
"filter":"myddoc/myfilter", "query_params": {"key":"value"}}
  }}}
- 
  === Replicating through a proxy ===
- 
  Pass a "proxy" argument in the replication data to have replication go through an HTTP proxy:
  
  {{{
@@ -109, +93 @@

  
  {"source":"example-database","target":"http://example.org/example-database", "proxy":"http://localhost:8888"}
  }}}
- 
  Note that HTTPS proxies are in theory supported but do not work in 1.0.1. This is because
1.0.1 ships with [[http://github.com/cmullaparthi/ibrowse|ibrowse]] version 1.5.5. The CouchDB
version in trunk (from where 1.1 will be based) ships with ibrowse version 1.6.2. This later
ibrowse contains fixes for HTTPS proxies.
  
- See also: 
+ See also:
+ 
   * [[Replication_and_conflicts|Replication and conflicts]]
   * [[How_to_design_for_replication|How to design for replication]]
  

Mime
View raw message