DOCSP-41105

Author: sonderdonk-mdb

source/reference/about-mongosync.txt

@@ -5,16 +5,15 @@ About ``mongosync``
 ====================
 
 The ``mongosync`` binary is the primary process used in {+c2c-product-name+}. 
-``mongosync`` migrates data from one cluster to another and keeps the 
-clusters in continuous sync. You can use ``mongosync`` to create dedicated 
-analytics, development, or testing clusters that mirror your production 
-environment. 
+``mongosync`` migrates data from a source cluster to a destination cluster and 
+keeps the clusters in continuous sync. You can use ``mongosync`` to create 
+dedicated analytics, development, or testing clusters that mirror your 
+production environment. 
 
-``mongosync`` keeps track of its current actions through states. ``mongosync`` 
-enters different states depending on the requests it receives. The current 
-``mongosync`` state determines which API operations you can run. 
-For more information on ``mongosync`` states, see 
-:ref:`mongosync States <c2c-states>`.
+``mongosync`` keeps track of its current actions through 
+:ref:`states <c2c-states>`. ``mongosync`` enters different states depending on 
+the requests it receives. The current ``mongosync`` state determines which API 
+operations you can run. 
 
 How ``mongosync`` Works
 -----------------------
@@ -27,17 +26,17 @@ clusters before it can start to sync data. For more information, see
 :ref:`c2c-connecting`.
 
 When ``mongosync`` connects to the source and destination clusters, the 
-synchronization process is in the :ref:`IDLE <c2c-state-idle>` state.  
+synchronization process enters the :ref:`IDLE <c2c-state-idle>` state.  
 
 During Sync 
 ~~~~~~~~~~~
 
-The :ref:`start <c2c-api-start>` endpoint begins the 
-:ref:`RUNNING <c2c-state-running>` state. 
-
-During the sync, ``mongosync`` syncs data from the source cluster to the 
-destination cluster. If you make subsequent writes to the source cluster, 
-``mongosync`` applies the operations to the destination cluster.  
+During the :ref:`RUNNING <c2c-state-running>` state, ``mongosync`` syncs data 
+from the source cluster to the destination cluster through the 
+:ref:`collection copy <c2c-collection-copy>` process. If you make subsequent 
+writes to the source cluster, ``mongosync`` applies the operations to the 
+destination cluster through the :ref:`change event application <c2c-cea>` 
+process.
 
 For every collection on the source, ``mongosync`` creates a corresponding 
 collection on the destination. 
@@ -47,50 +46,54 @@ the ``RUNNING`` state and changes these back to their source
 cluster characteristics during the ``COMMIT`` state. For more information, see
 :ref:`Commit Alters <c2c-commit-alters>`.
 
+The :ref:`start <c2c-api-start>` endpoint begins the ``RUNNING`` state. 
+
+.. _c2c-collection-copy:
+
 Collection Copy
 '''''''''''''''
 
-Collection copy is the initial full data transfer that copies each collection 
-from the source cluster to the destination cluster. ``mongosync`` performs 
-collection copy by splitting each source collection into partitions and copying
-all the partitions to their corresponding destination collections.
+The collection copy process is the initial full data transfer that copies each 
+collection from the source cluster to the destination cluster. ``mongosync`` 
+performs collection copy by splitting each source collection into partitions 
+and copying all the partitions to their corresponding destination collections.
+
+.. _c2c-cea:
 
 Change Event Application
 ''''''''''''''''''''''''
 
 The change event application (CEA) process continuously updates 
 the destination cluster when you make changes to the source cluster. If there 
-are multiple ``mongosync`` instances, all the ``mongosync`` instances finish 
+are multiple ``mongosync`` instances, all instances finish 
 collection copy before starting the CEA process.
 
 During CEA, ``mongosync`` receives :ref:`change stream <changeStreams>` events 
 from the source cluster, converts these events into writes, and applies these 
-writes on the destination cluster. CEA ensures that :ref:`CRUD <crud>` and 
-:ref:`DDL <c2c-mongosync-ddl>` events from the source cluster are accurately
-applied to the destination cluster.
+writes on the destination cluster. 
 
 Pausing Sync
 ~~~~~~~~~~~~
 
+During the ``PAUSED`` state, the sync process is paused.
+
 The :ref:`pause <c2c-api-pause>` endpoint begins the 
 :ref:`PAUSED <c2c-state-paused>` state.
 
-During the ``PAUSED`` state, the sync process is paused.
-
 The :ref:`resume <c2c-api-resume>` endpoint resumes a paused synchronization 
 session and returns ``mongosync`` to the ``RUNNING`` state. 
 
 Finalizing Sync
 ~~~~~~~~~~~~~~~
 
-The :ref:`commit <c2c-api-commit>` endpoint begins the 
-:ref:`COMMITTING <c2c-state-committing>` state.
-
 During the ``COMMITTING`` state, ``mongosync`` finalizes the sync between the 
 source cluster and the destination cluster by stopping continuous sync 
 between them. It also restores collection characteristics that ``mongosync`` 
 temporarily alters during synchronization. 
 
+The :ref:`commit <c2c-api-commit>` endpoint begins the 
+:ref:`COMMITTING <c2c-state-committing>` state.
+
 Once you call the ``commit`` endpoint, ``mongosync`` halts any writes on the 
 source cluster and retrieves the timestamp of the most recent operation in the 
 source cluster. 
@@ -100,22 +103,22 @@ processing events up until the commit timestamp. Then, ``mongosync`` corrects
 indexes and resolves document conflicts. If write blocking is enabled, 
 ``mongosync`` turns write operations back on. 
 
-``mongosync`` updates its state to :ref:`COMMITTED <c2c-state-committed>` once 
-the ``COMMITTING`` state is over. The ``COMMITTED`` state indicates the 
-:ref:`cutover process <c2c-cutover-process>` is finished, and you can direct 
-writes to the destination cluster.
+When the above process is completed, ``mongosync`` enters the 
+:ref:`COMMITTED <c2c-state-committed>` state. The ``COMMITTED`` state indicates 
+that the :ref:`cutover process <c2c-cutover-process>` is finished, and you can 
+direct writes to the destination cluster.
 
 Reversing Sync
 ~~~~~~~~~~~~~~
 
-The :ref:`reverse <c2c-api-reverse>` endpoint starts the 
-:ref:`REVERSING <c2c-state-reversing>` state. To use the ``reverse`` endpoint, 
-``mongosync`` must be in the ``COMMITTED`` state. 
-
 During the ``REVERSING`` state, ``mongosync`` copies data from the 
 destination cluster to the source cluster. Then, ``mongosync`` swaps the source 
 and destination clusters and resumes applying change events.
 
+The :ref:`reverse <c2c-api-reverse>` endpoint starts the 
+:ref:`REVERSING <c2c-state-reversing>` state. To use the ``reverse`` endpoint, 
+``mongosync`` must be in the ``COMMITTED`` state. 
+
 If the reverse sync is successful, ``mongosync`` enters the ``RUNNING`` state. 
 The synchronization continues in the reverse direction from the original 
 sync job.