DOCSP-45263-adding-reverse-tutorial

source/reference.txt

@@ -58,6 +58,7 @@ Reference
    Authentication Using Workload Identity Federation </reference/authentication>
    oplog Sizing </reference/oplog-sizing>
    Finalize Cutover Process </reference/cutover-process>
+   Reverse Sync Direction </reverse-sync>
    Limitations </reference/limitations>
    Logging </reference/logging>
    User Permissions </reference/permissions>

source/reference/api/reverse.txt

@@ -33,6 +33,9 @@ that occurred on ``cluster1`` after ``mongosync`` reached
 ``canWrite=true``.  To check the ``canWrite`` status during
 sync, use the :ref:`/progress <c2c-api-progress>` endpoint.
 
+For more information and a tutorial on using the ``reverse`` endpoint,
+see :ref:`c2c-reverse-process`. 
+
 Requirements
 ------------
 
@@ -162,6 +165,5 @@ Endpoint Protection
 Limitations
 ~~~~~~~~~~~
 
-The ``reverse`` endpoint does not support :ref:`filtered sync <c2c-filtered-sync>`.
-
-
+The ``reverse`` endpoint does not support :ref:`filtered sync
+<c2c-filtered-sync>`.

source/reference/cutover-process.txt

@@ -32,7 +32,7 @@ Steps
 .. procedure::
    :style: normal
 
-   .. step:: Verify the status of the ``mongosync`` process.
+   .. step:: Verify the status of mongosync.
 
       Call the :ref:`progress <c2c-api-progress>` endpoint to determine
       the status of ``mongosync`` before starting the cutover process.
@@ -64,29 +64,29 @@ Steps
 
    .. step:: Stop any write operations to the synced collections on the source.
 
-      - If you started ``mongosync`` with ``enableUserWriteBlocking``
+      - If you start ``mongosync`` with ``enableUserWriteBlocking``
         set to ``true``, ``mongosync`` blocks all write operations on
         the entire source cluster during the commit (step 4) for you.
       - If you didn't start ``mongosync`` with
-        ``enableUserWriteBlocking``, ensure that writes are disabled.
+        ``enableUserWriteBlocking``, ensure that you disable writes.
         For example, run the :dbcommand:`setUserWriteBlockMode` command on the
         source cluster:
 
         .. code-block:: javascript
 
            db.adminCommand( {
-              setUserWriteBlockMode: 1,
-              global: true 
+               setUserWriteBlockMode: 1,
+               global: true 
            } )
 
       - If ``mongosync`` uses filtered sync, it's not necessary to
-        disable writes to the entire source cluster. But you must ensure
-        that write operations are stopped for the collections included
-        by the filter.
+        disable writes to the entire source cluster. However, you must ensure
+        that you stop write operations for the collections that the
+        filter includes.
 
    .. step:: Send a :ref:`commit <c2c-api-commit>` request to ``mongosync``.
 
-      If you started multiple ``mongosync`` instances for your
+      If you start multiple ``mongosync`` instances for your
       migration, you must issue a commit request for each ``mongosync``
       instance.
 
@@ -109,6 +109,8 @@ Steps
          to ensure that the ``mongosync`` state is ``COMMITTING`` or
          ``COMMITTED``.
 
+      Once you complete this step, ``mongosync`` blocks writes on the source cluster.
+
    .. step:: Wait until you can perform writes on the destination cluster.
 
       Call the ``progress`` endpoint to determine if ``canWrite`` is
@@ -168,7 +170,7 @@ Steps
             :language: json
 
             "COMMITTED"
-
+   
 Behavior
 --------
 

source/reverse-sync.txt

@@ -0,0 +1,63 @@
+.. _c2c-reverse-process:
+
+======================
+Reverse Sync Direction
+======================
+
+.. default-domain:: mongodb
+
+.. contents:: On this page
+   :local:
+   :backlinks: none
+   :class: singlecol
+   :depth: 1
+
+To reverse the direction of a sync operation, use the following
+procedure to :ref:`commit your sync <c2c-cutover-process>` and call the
+``reverse`` endpoint. 
+
+Reversing sync allows you to keep clusters in continuous sync after you
+commit. After you commit a sync, you can't resume continuous sync between
+two clusters since ``mongosync`` can only sync into empty destination
+clusters. If you need to use the same two clusters after cutover, you
+can call the ``reverse`` endpoint to keep the clusters in sync.
+
+Before You Begin
+----------------
+
+Before you can reverse your sync direction, you must configure
+``mongosync`` and use the :ref:`c2c-api-start` endpoint to set the
+following parameters:
+
+- ``reversible`` to ``true``
+- ``enableUserWriteBlocking`` to ``true``.
+
+For more information on limitations and requirements of reversing sync,
+see :ref:`c2c-api-reverse`. 
+
+Steps
+-----
+
+Use these steps to reverse the direction of your sync:
+
+.. procedure::
+   :style: normal
+
+   .. step:: Finalize your sync.
+
+      Follow the :ref:`c2c-cutover-process` tutorial to enable write
+      blocking and finalize your data migration. 
+
+      :gold:`IMPORTANT:` ``mongosync`` does not support
+      :ref:`c2c-filtered-sync` during the reverse sync process. 
+
+   .. step:: Call the ``reverse`` endpoint.
+
+      Call the ``reverse`` endpoint to reverse the direction of your sync 
+      operation. Your original source cluster becomes your new destination cluster 
+      and your original destination cluster becomes your new source cluster. 
+
+      ``mongosync`` replicates all writes that you performed on your new
+      source cluster after you unblocked writes (during step 4 of the
+      :ref:`c2c-cutover-process`) to the
+      new destination cluster. 

source/topologies/multiple-mongosyncs.txt

@@ -284,6 +284,11 @@ Data Verification
 Reverse the Synchronization Direction
 -------------------------------------
 
+.. note::
+
+   For an in-depth tutorial on reversing your synchronization direction,
+   see :ref:`c2c-reverse-process`. 
+
 To reverse synchronization so that the original destination cluster
 acts as the source cluster: