[GitHub] wohali closed pull request #349: More information about replication. Fixes #346

[GitBox <gi...@apache.org>]

wohali closed pull request #349: More information about replication. Fixes #346
URL: https://github.com/apache/couchdb-documentation/pull/349
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git a/src/replication/intro.rst b/src/replication/intro.rst
index 98f97b0..a2fd534 100644
--- a/src/replication/intro.rst
+++ b/src/replication/intro.rst
@@ -26,18 +26,43 @@ 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
+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 parameters. Such a replication can be called `persistent`.
+Transient replications were kept for backward compatibility. Both replications can
+have different :ref:`replication states <replicator/states>`.
+
+Triggering, Stopping and Monitoring Replications
+================================================
+
+A persistent replication is controlled through a document in the
 :ref:`_replicator <replicator>` database, where each document describes one
-replication process (see :ref:`replication-settings`).
+replication process (see :ref:`replication-settings`). For setting up a
+transient replication 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 running 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
+finished.
 
-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`.
+A replication can be stopped by deleting the document, or by updating it with
+its `cancel` property set to `true`.
 
 Replication Procedure
 =====================
diff --git a/src/replication/replicator.rst b/src/replication/replicator.rst
index 10139bd..d1cb532 100644
--- a/src/replication/replicator.rst
+++ b/src/replication/replicator.rst
@@ -126,9 +126,12 @@ The replication job will also appear in
           "total_rows": 1
       }
 
-``_scheduler/jobs`` shows more information such as a detailed history of
-state changes. However if replication has completed or has failed to
-start it would not appear here, only in ``_scheduler/docs``.
+``_scheduler/jobs`` shows more information, such as a detailed history of
+state changes. If a persistent replication has not yet started,
+has failed, or is completed, information about its state can only be found
+in ``_scheduler/docs``. Keep in mind that some replication documents could be
+invalid and could not become a replication job. Others might be delayed
+because they are fetching data from a slow source database.
 
 If there is an error, for example if the source database is missing, the
 replication job will crash and retry after a wait period. Each


 

----------------------------------------------------------------
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