You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@couchdb.apache.org by GitBox <gi...@apache.org> on 2018/10/31 14:43:27 UTC

[GitHub] nickva commented on issue #346: _replicate vs _replication API endpoints

nickva commented on issue #346: _replicate vs _replication API endpoints
URL: https://github.com/apache/couchdb-documentation/issues/346#issuecomment-434713923
 
 
   **Creating Replications**
   
   There are two ways to create replications:
   
    1) POST-ing to the `/_replicate` HTTP endpoint. Let's call these `transient`.
   
    2) Creating a document in the `_replicator` database. Any database which ends in the `/_replicator` will work as a replicator database. Let's call these `persistent`.
   
   Each are slightly different. For the transient ones there is no document backing the replication job. If the server crashes the job will just disappear. When jobs finish there is no way to query their state. This method of replicating was implemented initially.
   
   `Persistent` ones are backed by a document in a _replicator db. They will persist across server restarts and it is possible to inspect their state after they finished.
   
   The reason there are two is because `transient` ones where implemented first and were kept for backwards compatibility and are actually useful in some cases when programmatically creating replication jobs.
   
   **Monitoring Replications**
   
   1) `Transient` replications can be monitored via the `/_active_tasks` endpoint or the `/_scheduler/jobs` endpoint.  It might take a a few minutes between the time a replication is created and it appears as a replication job in these endpoints.
   
   http://docs.couchdb.org/en/latest/api/server/common.html#scheduler-jobs
   
   2) `Permanent` replications can be monitored via the `/_scheduler/docs` endpoint as well as the `/_scheduler/jobs` and `/_active_tasks`. The `/_scheduler/docs` is preferred as it will show the state of the replication *document* before it becomes a replication *job*. Some documents could be invalid and could not become a replication job. Others might be delayed because they are fetching say the filter code from a slow source database.
   
   http://docs.couchdb.org/en/latest/api/server/common.html#get--_scheduler-docs-replicator_db
   
   **Replication States**
   
   Replication documents become replication jobs and then replication jobs do all the replication work. There are a number of states a replication goes through so this chart might be helpful: 
   
   http://docs.couchdb.org/en/latest/replication/replicator.html#replication-states
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services