flimzy commented on a change in pull request #349: More information about replication. Fixes #346 URL: https://github.com/apache/couchdb-documentation/pull/349#discussion_r232981662
########## File path: src/replication/intro.rst ########## @@ -26,18 +26,46 @@ 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 on the destination database (if they even existed). -Triggering Replication -====================== -Replication is controlled through documents in the -:ref:`_replicator <replicator>` database, where each document describes one -replication process (see :ref:`replication-settings`). +Transient and Persistant Replication +==================================== + +There are two different kinds of setting up a replication. The first one that was +introduced into CouchDB leads do a replication that could be called `trancient`. +Trancient means that there are no documents backing up the replication. So after a +restart of the CouchDB server the replication will disapear. Later in time the +:ref:`_replicator <replicator>` database was introduced which keeps documents +containing your replication parameter. Such a replication can be called `persisent`. +Trancient and persistent replications can have different +:ref:`replication states <replicator/states>`. + +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. -A replication is triggered by storing a replication document in the replicator -database. Its status can be inspected through the active tasks API (see -:ref:`api/server/active_tasks` and :ref:`replication-status`). A replication can -be stopped by deleting the document, or by updating it with its `cancel` -property set to `true`. +Triggering, Stopping and Monitoring Replications +================================================ + +A Replication which is persistent is controlled through a document in the +:ref:`_replicator <replicator>` database, where each document describes one +replication process (see :ref:`replication-settings`). For setting up a +replication that is transient the api endpoint +:ref:`/_replicate <api/server/replicate>` can be used. A replication is triggered +by sending a JSON object either to the ``_replicate`` endpoint or storing it as a +document into the ``_replicator`` database. + +If a replication is currently performed its status can be inspected through the +active tasks API (see :ref:`api/server/active_tasks`, :ref:`replication-status` +and :ref:`api/server/_scheduler/jobs` ). + +For document based replications :ref:`api/server/_scheduler/docs` can be used to Review comment: Grammatical improvements: ```suggestion For document based-replications, :ref:`api/server/_scheduler/docs` can be used to ``` ---------------------------------------------------------------- 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: us...@infra.apache.org With regards, Apache Git Services