wohali commented on a change in pull request #349: More information about replication. Fixes #346 URL: https://github.com/apache/couchdb-documentation/pull/349#discussion_r234371222
########## File path: src/replication/intro.rst ########## @@ -26,18 +26,42 @@ 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 ways to set up a replication. The first one that was +introduced into CouchDB leads do a replication that could be called `transient`. +Transient means that there are no documents backing up the replication. So after a +restart of the CouchDB server the replication will disapear. Later, the +:ref:`_replicator <replicator>` database was introduced, which keeps documents +containing your replication parameter. Such a replication can be called `persisent`. +Trancient replications were kept for backward compatibility. Both replications can +have different :ref:`replication states <replicator/states>`. -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 +get a complete state summary. This API is preferred as it will show the state of the +replication document before it becomes a replication job. +For transient replications there is no way to query their state when the job is Review comment: Is there a newline missing here? ---------------------------------------------------------------- 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: [email protected] With regards, Apache Git Services
